9:14 p.m.
We really need to move forward on selecting a CMS.
It is highly unlikely that we'll see a PHP solution selected. I've
heard many calls for Drupal, but let's not count on it. In particular,
if a PHP solution is chosen, we'll have to be very, very careful in
picking it out, and we'll probably need to disable any more dangerous
functionality. In the case of Drupal and many others, that would
include XML-RPC.
There aren't many Python solutions out there, but we need to scour what
is available very carefully. Many people were or would have been
doubtful of what we could accomplish with MoinMoin, and look at all
we've managed to do. The Fedora Project wiki is at the top of the list
of MoinMoin's list of example wikis[1]. We can accept that there may
need to be work done on whatever solution we select to get it where we
want it. We've got a large pool of talent that will be wiling to help
with that.
I've added this to the Schedule[2], and placed an arbitrary target date
of 2006-01-13 on this item. Let's see if we can get it done any sooner.
I know the guys working on the Fedora Unity project[3] have been working
on a similar problem, and Thomas Chung of FedoraNEWS.ORG has been in the
market recently. I'd love to hear what they've learned. Anyone else
with recent experience or examples of good CMS implementations can chime
in. Some demos are available at http://www.opensourcecms.com/ for
people to check out. Happy hunting!
[1] http://moinmoin.wikiwikiweb.de/MoinMoinWikis
[2] http://fedoraproject.org/wiki/Websites/Schedule
[3] http://fedoraunity.org/
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
10 p.m.
On Fri, 2005-12-02 at 21:14 -0600, Patrick Barnes wrote:
We really need to move forward on selecting a CMS.
Or deciding to just use Moin Moin like a CMS and add features, whichever
is the better solution.
I understand Seth's questioning of what a CMS provides us. It's one
thing to want a big feature set, it's another thing to actually use it.
_If_ we can get an immediate commitment to utilize Fedora resources to
extend our current tools (Moin Moin, XML, XSLT, CSS, CVS), that might be
faster than coming up to speed on a Python-based CMS ... that probably
needs further extension to make it work for us.
It's a self-tail-biting solution, we keep coming up on ourselves from
the rear. If we have enough investment in our current tools, can we
move forward with them faster than with a new tool?
It is highly unlikely that we'll see a PHP solution selected.
I've
heard many calls for Drupal, but let's not count on it. In particular,
if a PHP solution is chosen, we'll have to be very, very careful in
picking it out, and we'll probably need to disable any more dangerous
functionality. In the case of Drupal and many others, that would
include XML-RPC.
The PHP route has far more obstacles, and it doesn't sound as if anyone
is doing anything to resolve them. Or has someone packaged Drupal for
FE?
Regardless, as long as Duke.edu is providing a platform for fp.o, we are
beholden to the will o' Seth on this matter. Can we just make the
decision "No PHP," swallow the bitterness, and move on?
There aren't many Python solutions out there, but we need to
scour what
is available very carefully. Many people were or would have been
doubtful of what we could accomplish with MoinMoin, and look at all
we've managed to do. The Fedora Project wiki is at the top of the list
of MoinMoin's list of example wikis[1]. We can accept that there may
need to be work done on whatever solution we select to get it where we
want it. We've got a large pool of talent that will be wiling to help
with that.
Can we enable that talent to get busy?
Is our Moin Moin source in CVS somewhere? Can we start hacking on it,
or offering patches?
OK, friends, I can support NIH, as long as we are empowered to staff the
project.
If we are going to say, "Python only," let's recruit some Python help to
extend Moin Moin exactly where we need it to go. Recruit, like,
yesterday.
Some demos are available at http://www.opensourcecms.com/
That site is specifically for listing PHP and MySQL-based solutions.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
2:06 p.m.
On Fri, 2 Dec 2005, Karsten Wade wrote:
Regardless, as long as Duke.edu is providing a platform for fp.o, we
are
beholden to the will o' Seth on this matter. Can we just make the
decision "No PHP," swallow the bitterness, and move on?
No, because (a) a PHP solution might be the best one, all things
considered (b) we aren't constrained to hosting it on Seth's machine.
I am trying very hard to make the current Red Hat-hosted Fedora machines
open to all who want to use them - the most difficult thing right now is
finding people who are willing to use the access I've given :).
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
2:18 p.m.
Hi
I am trying very hard to make the current Red Hat-hosted Fedora machines
open to all who want to use them - the most difficult thing right now is
finding people who are willing to use the access I've given :).
What are the tasks that require such access to these systems?. What
skill sets?
regards
Rahul
2:24 p.m.
On Tue, 6 Dec 2005, Rahul Sundaram wrote:
What are the tasks that require such access to these systems?. What
skill sets?
Working on the pending infrastructure projects listed
http://fedoraproject.org/wiki/Fedora
Keeping machines up-to-date. (And a lot of the machines need plain old
reinstallation, with RHEL4 instead of RHEL3.)
Reading logs and e-mails to fix the inevitable hiccups.
etc.
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
2:29 p.m.
Elliot Lee wrote:
On Tue, 6 Dec 2005, Rahul Sundaram wrote:
>What are the tasks that require such access to these systems?. What
>skill sets?
>
>
Working on the pending infrastructure projects listed
http://fedoraproject.org/wiki/Fedora
Keeping machines up-to-date. (And a lot of the machines need plain old
reinstallation, with RHEL4 instead of RHEL3.)
I think I will sign up for that then. How do I go about doing that?
regards
Rahul
2:27 p.m.
Thanks for spurring this effort along, Patrick!
On Fri, 2 Dec 2005, Patrick Barnes wrote:
We really need to move forward on selecting a CMS.
It is highly unlikely that we'll see a PHP solution selected. I've
heard many calls for Drupal, but let's not count on it. In particular,
if a PHP solution is chosen, we'll have to be very, very careful in
picking it out, and we'll probably need to disable any more dangerous
functionality. In the case of Drupal and many others, that would
include XML-RPC.
Agreed.
There aren't many Python solutions out there, but we need to
scour what
is available very carefully. Many people were or would have been
doubtful of what we could accomplish with MoinMoin, and look at all
we've managed to do. The Fedora Project wiki is at the top of the list
of MoinMoin's list of example wikis[1]. We can accept that there may
need to be work done on whatever solution we select to get it where we
want it. We've got a large pool of talent that will be wiling to help
with that.
So I've been looking around for a CMS, on and off, for proably four or
five months. I'll just throw my ideas so far out there as a starting
point:
. Zope. We just have to look at it seriously because it's in
Python. Its main weaknesses are performance and ease of use.
. Drupal. PHP. Very cool in general. Main weakness is the security
concerns. It also lacks a version history of pages, which is
something important to me personally.
. Typo3 is a CMS-type thing in PHP. Its biggest shortcoming when I
tried it was its complexity.
. Midgard is a PHP CMS that I haven't looked into. Someone should
evaluate it, because its features look very attractive overall.
. Turbogears and Django. Two Python web "frameworks" that make it
easier to write web apps, but don't offer an actual CMS
themselves.
. Various Java solutions such as Apache Lenya. Haven't looked into
this space much, even though it's probably where the most
action is.
. What we've got already. The basic idea is perfectly sound, and
everyone knows how to use CVS. This is the baseline that the new
solution needs to improve on, so one good question is "what do we
need that we don't have now?"
I do not consider wikis a viable starting point. They don't seem conducive
to keeping the site organized. Maybe there is one out there that has the
features necessary to do this, but I haven't seen those features in
Moinmoin. :)
http://www.la-grange.net/cms has a list of open source CMS's.
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
2:28 p.m.
On Mon, 5 Dec 2005, Elliot Lee wrote:
. What we've got already. The basic idea is perfectly sound, and
everyone knows how to use CVS. This is the baseline that the new
solution needs to improve on, so one good question is "what do we
need that we don't have now?"
This is the heart of the conversation. There's lots of "cool" stuff in
Drupal, but what do we *need*, really? Here's my wish list:
1. Calendars. We can do this with standalone ics files.
2. Translatability. We should be able to break content out into easy
translation strings.
3. Form processing. Straight CGI, eh?
What else do we *really* need for the static / "authoritative" site?
I'm perfectly fine changing f.r.c to some more Fedora-friendly domain
name, btw.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
2:39 p.m.
We've got a server at "fedora.redhat.com" right now.
It would be pretty simple to just move the box to a domain that is not
"redhat.com" and use it as-is. It's certainly not a CMS, but it's what
we've got, isn't it?
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
On Tue, 6 Dec 2005, Rahul Sundaram wrote:
Hi
>I'm perfectly fine changing f.r.c to some more Fedora-friendly domain
>name, btw.
>
Not sure what that means. Can you expand on that?
regards
Rahul
--
Fedora-websites-list mailing list
Fedora-websites-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-websites-list
2:51 p.m.
Greg DeKoenigsberg wrote:
We've got a server at "fedora.redhat.com" right now.
It would be pretty simple to just move the box to a domain that is not
"redhat.com" and use it as-is. It's certainly not a CMS, but it's what
we've got, isn't it?
So are you suggesting that we move the domain content over or just point
it to fedoraproject.org?. There is a lot of stale content that we need
to remove or update. There are probably other pieces of infrastructure
like the accounts system, paypal?, docs system etc
regards
Rahul
2:51 p.m.
On Tue, 6 Dec 2005, Rahul Sundaram wrote:
So are you suggesting that we move the domain content over or just
point
it to fedoraproject.org?. There is a lot of stale content that we need
to remove or update. There are probably other pieces of infrastructure
like the accounts system, paypal?, docs system etc
I've already removed a lot of the stale content and done substantial
rewriting. Check out HEAD and have a look; that's what Patrick Barnes is
doing now.
There are definitely other pieces of infrastructure, but we have to tackle
the problems as we find them, too. I'm all for contuing the search for
the Grand Unified Theory of Fedora Websites -- but we need some
updated/translated content, and we need to start somewhere, and the
content in f.r.c HEAD is my stab at that starting point.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
3:07 p.m.
On Mon, 5 Dec 2005, Greg DeKoenigsberg wrote:
On Mon, 5 Dec 2005, Elliot Lee wrote:
> . What we've got already. The basic idea is perfectly sound, and
> everyone knows how to use CVS. This is the baseline that the new
> solution needs to improve on, so one good question is "what do we
> need that we don't have now?"
This is the heart of the conversation. There's lots of "cool" stuff in
Drupal, but what do we *need*, really? Here's my wish list:
1. Calendars. We can do this with standalone ics files.
2. Translatability. We should be able to break content out into easy
translation strings.
3. Form processing. Straight CGI, eh?
What else do we *really* need for the static / "authoritative" site?
I would like:
. Dynamic content on the authoritative site. For example,
having upcoming events posted on the home page, and automatically
removed after they have occurred. Another area where automation
could save time is allowing us to have the entire web site
automatically reflect the availability of a new FC release -
currently there are half a dozen pages that we have to update at
release time. The navigation sidebar could also be produced
automatically. In other words, stuff to save us time.
. On-the-web page editing - makes it easier to make changes, and
allows more people to contribute.
. Workflow & versioning - allow more people to contribute.
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
5:46 p.m.
On Wed, 2005-12-07 at 16:07 -0500, Elliot Lee wrote:
I would like:
. Dynamic content on the authoritative site. For example,
having upcoming events posted on the home page, and automatically
removed after they have occurred. Another area where automation
could save time is allowing us to have the entire web site
automatically reflect the availability of a new FC release -
currently there are half a dozen pages that we have to update at
release time. The navigation sidebar could also be produced
automatically. In other words, stuff to save us time.
. On-the-web page editing - makes it easier to make changes, and
allows more people to contribute.
. Workflow & versioning - allow more people to contribute.
+1
Who holds the decision to Just Start Already?
Or do we need more information still? More of a plan?
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
5:47 p.m.
On Wed, 7 Dec 2005, Karsten Wade wrote:
On Wed, 2005-12-07 at 16:07 -0500, Elliot Lee wrote:
> I would like:
> . Dynamic content on the authoritative site. For example,
> having upcoming events posted on the home page, and automatically
> removed after they have occurred. Another area where automation
> could save time is allowing us to have the entire web site
> automatically reflect the availability of a new FC release -
> currently there are half a dozen pages that we have to update at
> release time. The navigation sidebar could also be produced
> automatically. In other words, stuff to save us time.
>
> . On-the-web page editing - makes it easier to make changes, and
> allows more people to contribute.
>
> . Workflow & versioning - allow more people to contribute.
+1
Who holds the decision to Just Start Already?
We *are* just started already. :) We're (a) working towards an agreement
on what's important (b) finding software packages that will give us what's
important.
At least, that's what I've been assuming.
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
6:05 p.m.
On Wed, 2005-12-07 at 18:47 -0500, Elliot Lee wrote:
On Wed, 7 Dec 2005, Karsten Wade wrote:
> Who holds the decision to Just Start Already?
We *are* just started already. :) We're (a) working towards an agreement
on what's important (b) finding software packages that will give us what's
important.
At least, that's what I've been assuming.
Sounds to me like we want everything *and* the kitchen sink. Why not put
something like Zope in place and see how we go from there?
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
9:37 p.m.
Ignacio Vazquez-Abrams wrote:
On Wed, 2005-12-07 at 18:47 -0500, Elliot Lee wrote:
> On Wed, 7 Dec 2005, Karsten Wade wrote:
> > Who holds the decision to Just Start Already?
>
> We *are* just started already. :) We're (a) working towards an agreement
> on what's important (b) finding software packages that will give us what's
> important.
>
> At least, that's what I've been assuming.
Sounds to me like we want everything *and* the kitchen sink. Why not put
something like Zope in place and see how we go from there?
Coincidentally, I had the opportunity to play with setting up Zope +
Plone on a Core 4 system today, and was considering suggesting it.
It seems to me like we could work everything in around that, one way or
another. It's written in Python and available in Extras. It's very
extensible, has a reasonable security track record, and can already do
many of the things we're looking for. It's worth looking into, at least.
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
Rate my assistance! http://rate.affero.net/nman64/
10:46 p.m.
On Wed, 7 Dec 2005, Patrick Barnes wrote:
Coincidentally, I had the opportunity to play with setting up Zope +
Plone on a Core 4 system today, and was considering suggesting it.
It seems to me like we could work everything in around that, one way or
another. It's written in Python and available in Extras. It's very
extensible, has a reasonable security track record, and can already do
many of the things we're looking for. It's worth looking into, at least.
Definitely. However, you probably want to look more into Zope 3.x, rather
than Zope 2.x + Plone.
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
4:16 a.m.
On 12/8/05, Elliot Lee <sopwith(a)redhat.com> wrote:
> Coincidentally, I had the opportunity to play with setting up
Zope +
> Plone on a Core 4 system today, and was considering suggesting it.
> It seems to me like we could work everything in around that, one way or
> another. It's written in Python and available in Extras. It's very
> extensible, has a reasonable security track record, and can already do
> many of the things we're looking for. It's worth looking into, at least.
Definitely. However, you probably want to look more into Zope 3.x, rather
than Zope 2.x + Plone.
Also based on Zope, you could have a look at this:
http://www.cps-project.org/
--
Gianluca
3:08 p.m.
On Wed, 7 Dec 2005, Ignacio Vazquez-Abrams wrote:
On Wed, 2005-12-07 at 18:47 -0500, Elliot Lee wrote:
> On Wed, 7 Dec 2005, Karsten Wade wrote:
> > Who holds the decision to Just Start Already?
>
> We *are* just started already. :) We're (a) working towards an agreement
> on what's important (b) finding software packages that will give us what's
> important.
>
> At least, that's what I've been assuming.
Sounds to me like we want everything *and* the kitchen sink. Why not put
something like Zope in place and see how we go from there?
I did set Zope3 up on my workstation, but it has a steep learning curve
and I didn't get it to the point where I could form an opinion.
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
2:32 p.m.
. Turbogears and Django. Two Python web "frameworks" that
make it
easier to write web apps, but don't offer an actual CMS
themselves.
djangoproject.com already has doc and article submission code up on the
site. I even posted about that. The code is available and it wouldn't
take that much work to use it.
I'm glad to hear that no one is even reading my emails anymore.
I do not consider wikis a viable starting point. They don't seem
conducive
to keeping the site organized. Maybe there is one out there that has the
features necessary to do this, but I haven't seen those features in
Moinmoin. :)
What kind of organization do you desire? How are you hoping to have
things arranged. This is the first time I've heard this complaint
against the wiki so I'm curious now how you are defining organized.
-sv
2:44 p.m.
On Mon, 5 Dec 2005, seth vidal wrote:
> . Turbogears and Django. Two Python web "frameworks"
that make it
> easier to write web apps, but don't offer an actual CMS
> themselves.
djangoproject.com already has doc and article submission code up on the
site. I even posted about that. The code is available and it wouldn't
take that much work to use it.
This sounds a bit unrealistic. It would take a lot of work to go from a
code snippet that's out there to a fully polished CMS...
I'm glad to hear that no one is even reading my emails anymore.
I have a special e-mail filter just for you, dude. (It goes into my
'community people' folder, not to /dev/null :) But there is so much to
remember, all I can do is apologize.
> I do not consider wikis a viable starting point. They don't
seem conducive
> to keeping the site organized. Maybe there is one out there that has the
> features necessary to do this, but I haven't seen those features in
> Moinmoin. :)
What kind of organization do you desire? How are you hoping to have
things arranged.
This is the first time I've heard this complaint against the wiki
so I'm
curious now how you are defining organized.
Wikis don't have a way to build a hierarchy of pages, move branches
around, etc. I realize that MoinMoin does have categories, but I don't
know that they're hierarchical, and AFAIK there's no way to turn them into
a nice little sidebar with an expandable tree. These basic navigation
things may sound stupid, but they're important to web site usability.
drupal's taxonomies are All That(tm when it comes to keeping pages
categorized and organized. Then using a drupal module, you can add a block
on the sidebar that displays your current location in the hierarchy of
that taxonomy, and your potential navigation destinations.
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
2:52 p.m.
On Mon, 2005-12-05 at 15:44 -0500, Elliot Lee wrote:
> djangoproject.com already has doc and article submission code up
on the
> site. I even posted about that. The code is available and it wouldn't
> take that much work to use it.
This sounds a bit unrealistic. It would take a lot of work to go from a
code snippet that's out there to a fully polished CMS...
take a look at the features it offers first. If I can find the time this
week I'll try to set it up so you know what you're talking about first.
> What kind of organization do you desire? How are you hoping to
have
> things arranged.
> This is the first time I've heard this complaint against the wiki so I'm
> curious now how you are defining organized.
Wikis don't have a way to build a hierarchy of pages, move branches
around, etc. I realize that MoinMoin does have categories, but I don't
know that they're hierarchical, and AFAIK there's no way to turn them into
a nice little sidebar with an expandable tree. These basic navigation
things may sound stupid, but they're important to web site usability.
You mean like:
http://fedoraproject.org/wiki/CategoryExtras
and
http://fedoraproject.org/wiki/CategoryCategory
and
http://fedoraproject.org/wiki/CategoryDesktop
like that?
-sv
2:57 p.m.
On Mon, 5 Dec 2005, seth vidal wrote:
> Wikis don't have a way to build a hierarchy of pages, move
branches
> around, etc. I realize that MoinMoin does have categories, but I don't
> know that they're hierarchical, and AFAIK there's no way to turn them into
> a nice little sidebar with an expandable tree. These basic navigation
> things may sound stupid, but they're important to web site usability.
You mean like:
http://fedoraproject.org/wiki/CategoryExtras
and
http://fedoraproject.org/wiki/CategoryCategory
and
http://fedoraproject.org/wiki/CategoryDesktop
like that?
I'm aware of those pages, but they are not hierarchical (putting a '/' in
page names does not add hierarchy support to MoinMoin). They also won't
show up on the sidebar of pages throughout the site.
Best,
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
3:03 p.m.
I'm aware of those pages, but they are not hierarchical (putting
a '/' in
page names does not add hierarchy support to MoinMoin). They also won't
show up on the sidebar of pages throughout the site.
It's a fucking theme, Elliot! It's a theme. That's all the sidebar is
doing.
Nothing fancy. Do you want a list of where you are in the category
hiearchy in a theme? Would that make life better for you?
Ask Hrishi if he'd be willing to add such a thing to our wiki theme and
presto - you can have the categories related on the page.
-sv
2:58 p.m.
On Mon, 5 Dec 2005, seth vidal wrote:
> Wikis don't have a way to build a hierarchy of pages, move
branches
> around, etc. I realize that MoinMoin does have categories, but I don't
> know that they're hierarchical, and AFAIK there's no way to turn them into
> a nice little sidebar with an expandable tree. These basic navigation
> things may sound stupid, but they're important to web site usability.
You mean like:
http://fedoraproject.org/wiki/CategoryExtras
and
http://fedoraproject.org/wiki/CategoryCategory
and
http://fedoraproject.org/wiki/CategoryDesktop
like that?
Actually, Seth, I'd say that your examples conclusively demonstate
Elliot's point. Those pages are scarcely more useful than running a
search through the wiki. And since they're not on a sidebar, a user has
*no way* of figuring out where they are without visiting one of these
pages.
Information architecture is hard -- and more information == more hard.
That's one of the reasons I'm kinda skeptical of the whole "CMS" idea
in
the first place, tbh. For dynamic content, use the wiki. For static
content -- which includes high-level content, a decent current map of the
dynamic content, and very little else -- I'm in favor of plain ol' web
pages, with a handful of people who are tasked with auditing the content
every few months on a set schedule.
The surface content on Ubuntu's site is certainly well-maintained -- but
go a couple of layers deep, and it's the same kind of chaos we face,
Drupal or no Drupal.
My $0.02. I'm just trying to make something out of what we've got now.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
3:11 p.m.
Actually, Seth, I'd say that your examples conclusively
demonstate
Elliot's point. Those pages are scarcely more useful than running a
search through the wiki. And since they're not on a sidebar, a user has
*no way* of figuring out where they are without visiting one of these
pages.
and as I explained - these sidebars are just theme additions. So if you
want to access that data we will need to get the theme changed. But I
bet we don't even know what we want on those sidebars. I bet we end up
with 40 or 50 different variations like those asinine little boxes
slashdot used to have.
The surface content on Ubuntu's site is certainly well-maintained
-- but
go a couple of layers deep, and it's the same kind of chaos we face,
Drupal or no Drupal.
Out of curiosity what is it that is broken about our current
infrastructure?
And out of further curiosity - what was it that kept the
fedora.redhat.com from having php running on it?
-sv
2:33 p.m.
Hi
. What we've got already. The basic idea is perfectly sound, and
everyone knows how to use CVS. This is the baseline that the new
solution needs to improve on, so one good question is "what do we
need that we don't have now?"
As I posted to the list before one of the useful things to have is a web
based task manager. We make heavy use of task lists throughout the wiki.
regards
Rahul
3:58 p.m.
On Mon, 2005-12-05 at 15:27 -0500, Elliot Lee wrote:
So I've been looking around for a CMS, on and off, for proably
four or
five months. I'll just throw my ideas so far out there as a starting
point:
There's also PyLucid. The documentation leaves something to be desired,
but it might do.
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
4:58 p.m.
Okay, I've read over all the posts that have sprung up on this thread
today, and here's how I see it.
Basically, it sounds like everyone is leaning in one of two directions:
a.) Drupal is great except that it runs on PHP.
b.) CVS and good, old-fashioned web skills are a great combination.
Well, I think we all have a pretty good idea of what standard features
of a CMS are. So lets start from there.
* How do we break down everything we need between the wiki and CVS?
We can do calendars using whatever calendar software the user
prefers and iCal files.
We can continue to track tasks on the wiki, but is that process
working well enough for everyone? Do we need an alternative? Would
calendars with to-do lists work better?
We probably need static content for translation. What are the pros
and cons of using the wiki for this? CVS? Wiki with regular exports
and touch-up for CVS?
We want revision control. Both the wiki and CVS can provide this.
We want help tickets. How can we manage this using the wiki, CVS,
and Bugzilla?
If we can answer these with smiles on our faces, there's no real need
for separate CMS software. Can anyone think of other needs to add to
this list?
If we decide we need a CMS solution, what can we do to make a PHP
solution like Drupal as secure as possible? We can disable XML-RPC.
What other features would we need to disable? Would this cripple Drupal
beyond usefulness? What about access; do we want it to be as open as
the wiki, or do we want to tighten it a little to protect it? We might
in particular want to address isolating Drupal (having it on a server by
itself) and trying to add protections for user information, should it be
compromised.
Also, a point that was brought up elsewhere was CVS access to MoinMoin.
Is this something we need or want? Most of MoinMoin would have no need
for CVS access. Only the plugins and themes would really be sensible to
allow CVS access to. We might also want to consider this for any CMS
solution we choose.
Finally, there's the domain consideration. Thus far, we've been talking
about setting up the CMS solution on fedoraproject.org. I think that if
we do choose Drupal or another CMS, we should do exactly that. What if
we use the infrastructure that is in place for fedora.redhat.com? I
think if we choose to go the CVS route that we should try to put it on
fedoraproject.org. We do still want to keep fedora.redhat.com, at least
for Red Hat's own messages about Fedora. Is this something we can do?
My personal opinion so far: I think we can make CVS, MoinMoin, and
Bugzilla work for our needs. I'd like to see CVS on fedoraproject.org.
I think that we should use the same account system to manage access to
fedoraproject.org as we use for fedora.redhat.com, to eliminate having
two sets of web admins. I'd like to move what we have at
fedora.redhat.com in CVS HEAD over to fedoraproject.org and begin
working on it. We can replace the content at fedora.redhat.com with a
very basic bit of information that relays Red Hat's message about Fedora
and explains what the exact relationship is and what Red Hat does for
Fedora. I'm with Seth in that I would like to eliminate as much PHP as
possible. We currently have a little PHP in use for fedora.redhat.com.
It is all very simple and generates static content, but I'd like to see
it eventually replaced with Python anyway. If we are going to use
Drupal, I'd like to see it as isolated as possible and configured by the
most paranoid people we can find. I don't want to rule out finding a
Python CMS solution, and would love to see everyone who can providing
reviews and insights to that end.
Thoughts?
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
Rate my assistance! http://rate.affero.net/nman64/
5:15 p.m.
On Mon, 2005-12-05 at 16:58 -0600, Patrick Barnes wrote:
If we decide we need a CMS solution, what can we do to make a PHP
solution like Drupal as secure as possible? We can disable XML-RPC.
What other features would we need to disable? Would this cripple Drupal
beyond usefulness?
Hell yes.
http://secunia.com/advisories/17824/
--
Ignacio Vazquez-Abrams <ivazquez(a)ivazquez.net>
http://fedora.ivazquez.net/
gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72
5:18 p.m.
On Mon, 2005-12-05 at 16:58 -0600, Patrick Barnes wrote:
Okay, I've read over all the posts that have sprung up on this
thread
today, and here's how I see it.
Basically, it sounds like everyone is leaning in one of two directions:
a.) Drupal is great except that it runs on PHP.
b.) CVS and good, old-fashioned web skills are a great combination.
Well, I think we all have a pretty good idea of what standard features
of a CMS are.
Here is a list of use cases that I started on f-docs-l:
http://www.redhat.com/archives/fedora-docs-list/2005-November/msg00078.html
Not much discussion there ... either I hit all points, or no one cared
much.
So lets start from there.
* How do we break down everything we need between the wiki and CVS?
We can do calendars using whatever calendar software the user
prefers and iCal files.
We can continue to track tasks on the wiki, but is that process
working well enough for everyone? Do we need an alternative? Would
calendars with to-do lists work better?
Very, very, very lightweight calendar, please. I find that they full-
featured groupware-type stuff coming through a WUI ... is, uh ... not my
favorite way to do things. I'd much rather a semi-readable, hand-edited
Wiki.
I'd like to edit via the Web, get email reminders, and perhaps a way to
schedule/interact with the system via properly formatted email messages.
We probably need static content for translation. What are the
pros
and cons of using the wiki for this? CVS? Wiki with regular exports
and touch-up for CVS?
We really need something we can make PO files from, if we want to keep
content easily updated. These can then be checked into CVS and pulled
out by the trans teams.
Remember, they have existing tools, we do not. We must make our tools
use their tools, from the start. We can request an odd-ball, one-off
translation now and again, but not on a regular basis.
We want revision control. Both the wiki and CVS can provide
this.
We want help tickets. How can we manage this using the wiki, CVS,
and Bugzilla?
Not arguing, just curious ... why do we need help tickets? V. bugzilla
as it standa?
If we can answer these with smiles on our faces, there's no
real need
for separate CMS software. Can anyone think of other needs to add to
this list?
If we decide we need a CMS solution, what can we do to make a PHP
solution like Drupal as secure as possible? We can disable XML-RPC.
What other features would we need to disable? Would this cripple Drupal
beyond usefulness? What about access; do we want it to be as open as
the wiki, or do we want to tighten it a little to protect it?
Tighter control. This is graduated content, like code moving from
Extras to Core. It gets a higher level of attention because it serves a
central purpose.
We might
in particular want to address isolating Drupal (having it on a server by
itself) and trying to add protections for user information, should it be
compromised.
Also, a point that was brought up elsewhere was CVS access to MoinMoin.
Is this something we need or want? Most of MoinMoin would have no need
for CVS access. Only the plugins and themes would really be sensible to
allow CVS access to. We might also want to consider this for any CMS
solution we choose.
CVS access to check in/out XML files.
Finally, there's the domain consideration. Thus far, we've
been talking
about setting up the CMS solution on fedoraproject.org. I think that if
we do choose Drupal or another CMS, we should do exactly that. What if
we use the infrastructure that is in place for fedora.redhat.com? I
think if we choose to go the CVS route that we should try to put it on
fedoraproject.org. We do still want to keep fedora.redhat.com, at least
for Red Hat's own messages about Fedora. Is this something we can do?
I'm for making f.r.c a single RHAT-backed, FF-approved marketing message
with five links and a pretty theme.
My personal opinion so far: I think we can make CVS, MoinMoin, and
Bugzilla work for our needs. I'd like to see CVS on fedoraproject.org.
I think that we should use the same account system to manage access to
fedoraproject.org as we use for fedora.redhat.com, to eliminate having
two sets of web admins. I'd like to move what we have at
fedora.redhat.com in CVS HEAD over to fedoraproject.org and begin
working on it. We can replace the content at fedora.redhat.com with a
very basic bit of information that relays Red Hat's message about Fedora
and explains what the exact relationship is and what Red Hat does for
Fedora. I'm with Seth in that I would like to eliminate as much PHP as
possible. We currently have a little PHP in use for fedora.redhat.com.
It is all very simple and generates static content, but I'd like to see
it eventually replaced with Python anyway. If we are going to use
Drupal, I'd like to see it as isolated as possible and configured by the
most paranoid people we can find. I don't want to rule out finding a
Python CMS solution, and would love to see everyone who can providing
reviews and insights to that end.
+1 to this round-up ... until someone comes along and sways me. :)
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
10:30 p.m.
Karsten Wade wrote:
On Mon, 2005-12-05 at 16:58 -0600, Patrick Barnes wrote:
> Okay, I've read over all the posts that have sprung up on this thread
> today, and here's how I see it.
>
> Basically, it sounds like everyone is leaning in one of two directions:
> a.) Drupal is great except that it runs on PHP.
> b.) CVS and good, old-fashioned web skills are a great combination.
>
> Well, I think we all have a pretty good idea of what standard features
> of a CMS are.
Here is a list of use cases that I started on f-docs-l:
http://www.redhat.com/archives/fedora-docs-list/2005-November/msg00078.html
Not much discussion there ... either I hit all points, or no one cared
much.
> So lets start from there.
> * How do we break down everything we need between the wiki and CVS?
> We can do calendars using whatever calendar software the user
> prefers and iCal files.
> We can continue to track tasks on the wiki, but is that process
> working well enough for everyone? Do we need an alternative? Would
> calendars with to-do lists work better?
Very, very, very lightweight calendar, please. I find that they full-
featured groupware-type stuff coming through a WUI ... is, uh ... not my
favorite way to do things. I'd much rather a semi-readable, hand-edited
Wiki.
I'd like to edit via the Web, get email reminders, and perhaps a way to
schedule/interact with the system via properly formatted email messages.
Would you like fries with that? I'm not familiar with Drupal's
capabilities with calendars, but I think we'd otherwise be dealing with
client-side software of your choice with iCal files. The exact
interface and capabilities you'd be dealing with would depend upon the
tool you select. iCal files support scheduled events and to-do lists.
We might be able to set this up to use WebDAV, FTP or some other two-way
protocol, but otherwise would be syncing using CVS. If we choose to
continue using the wiki, then we can try to create plugins to add new
functionality, but I don't see any of those more advanced features
appearing any time soon.
> We probably need static content for translation. What are
the pros
> and cons of using the wiki for this? CVS? Wiki with regular exports
> and touch-up for CVS?
We really need something we can make PO files from, if we want to keep
content easily updated. These can then be checked into CVS and pulled
out by the trans teams.
Remember, they have existing tools, we do not. We must make our tools
use their tools, from the start. We can request an odd-ball, one-off
translation now and again, but not on a regular basis.
That's not a problem. Whether we use raw files or occasional exports
from the wiki, we can support translation. This might be something else
that would benefit from the infrastructure we've been working on for the
FDP.
> We want revision control. Both the wiki and CVS can provide
this.
> We want help tickets. How can we manage this using the wiki, CVS,
> and Bugzilla?
Not arguing, just curious ... why do we need help tickets? V. bugzilla
as it standa?
The first usage case I am aware of is to handle incoming email support
requests. Elliot and I were discussing this for mail directed at
fedora(a)redhat.com.
> If we can answer these with smiles on our faces, there's
no real need
> for separate CMS software. Can anyone think of other needs to add to
> this list?
>
> If we decide we need a CMS solution, what can we do to make a PHP
> solution like Drupal as secure as possible? We can disable XML-RPC.
> What other features would we need to disable? Would this cripple Drupal
> beyond usefulness? What about access; do we want it to be as open as
> the wiki, or do we want to tighten it a little to protect it?
Tighter control. This is graduated content, like code moving from
Extras to Core. It gets a higher level of attention because it serves a
central purpose.
> We might
> in particular want to address isolating Drupal (having it on a server by
> itself) and trying to add protections for user information, should it be
> compromised.
>
> Also, a point that was brought up elsewhere was CVS access to MoinMoin.
> Is this something we need or want? Most of MoinMoin would have no need
> for CVS access. Only the plugins and themes would really be sensible to
> allow CVS access to. We might also want to consider this for any CMS
> solution we choose.
CVS access to check in/out XML files.
I don't see how that relates to MoinMoin's back-end. Other than the
plugins and themes, there's really nothing stored by MoinMoin that is
safe to manipulate directly. The data that it stores for pages is
identical to what you get if you use the 'Show Raw Text' option from the
'More Actions' menu. The rest of the data is a directory hierarchy
providing the page locations and revisions and data about registered
users. Neither of those are things we should be playing with directly.
We can write scripts to interact with MoinMoin through HTTP requests,
just like the current XML checkout script for preparing the release
notes. The same is likely to be true of any CMS solution.
> Finally, there's the domain consideration. Thus far,
we've been talking
> about setting up the CMS solution on fedoraproject.org. I think that if
> we do choose Drupal or another CMS, we should do exactly that. What if
> we use the infrastructure that is in place for fedora.redhat.com? I
> think if we choose to go the CVS route that we should try to put it on
> fedoraproject.org. We do still want to keep fedora.redhat.com, at least
> for Red Hat's own messages about Fedora. Is this something we can do?
I'm for making f.r.c a single RHAT-backed, FF-approved marketing message
with five links and a pretty theme.
A pretty theme that matches 'Kind of Blue' from the wiki, maybe?
> My personal opinion so far: I think we can make CVS, MoinMoin,
and
> Bugzilla work for our needs. I'd like to see CVS on fedoraproject.org.
> I think that we should use the same account system to manage access to
> fedoraproject.org as we use for fedora.redhat.com, to eliminate having
> two sets of web admins. I'd like to move what we have at
> fedora.redhat.com in CVS HEAD over to fedoraproject.org and begin
> working on it. We can replace the content at fedora.redhat.com with a
> very basic bit of information that relays Red Hat's message about Fedora
> and explains what the exact relationship is and what Red Hat does for
> Fedora. I'm with Seth in that I would like to eliminate as much PHP as
> possible. We currently have a little PHP in use for fedora.redhat.com.
> It is all very simple and generates static content, but I'd like to see
> it eventually replaced with Python anyway. If we are going to use
> Drupal, I'd like to see it as isolated as possible and configured by the
> most paranoid people we can find. I don't want to rule out finding a
> Python CMS solution, and would love to see everyone who can providing
> reviews and insights to that end.
+1 to this round-up ... until someone comes along and sways me. :)
- Karsten
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
Rate my assistance! http://rate.affero.net/nman64/
11:06 a.m.
On Mon, 2005-12-05 at 22:30 -0600, Patrick Barnes wrote:
Karsten Wade wrote:
> I'd like to edit via the Web, get email reminders, and perhaps a way to
> schedule/interact with the system via properly formatted email messages.
>
Would you like fries with that?
Well, since you asked, yes. :)
That was just me dreaming. .ics files should work fine.
> > We want revision control. Both the wiki and CVS can
provide this.
> > We want help tickets. How can we manage this using the wiki, CVS,
> > and Bugzilla?
>
> Not arguing, just curious ... why do we need help tickets? V. bugzilla
> as it standa?
>
The first usage case I am aware of is to handle incoming email support
requests. Elliot and I were discussing this for mail directed at
fedora(a)redhat.com.
Yeah, there ya go. I've resisted making bug reports automatically from
messages to e.g. relnotes(a)fp.o. If this went into a ticketing system,
that could be cool. We use Request Tracker in several locations, I'll
find out if ours is seriously hacked up from the upstream. There is a
fair amount of experience with RT amongst FLOSS folks.
> CVS access to check in/out XML files.
>
I don't see how that relates to MoinMoin's back-end.
Not for storing MoinMoin objects, for accessing documentation in
canonical XML.
I have a directive to get this working internally at Red Hat, a wiki
front-end to DocBook XML. What I want to do is get the resources
assigned to this to work on making the functionality MoinMoin. In a few
weeks, when we are starting up that project, I'll where we can go from
there.
> I'm for making f.r.c a single RHAT-backed, FF-approved
marketing message
> with five links and a pretty theme.
>
A pretty theme that matches 'Kind of Blue' from the wiki, maybe?
Yeah, like that.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
8:37 a.m.
On Mon, 5 Dec 2005, Karsten Wade wrote:
Very, very, very lightweight calendar, please. I find that they
full-
featured groupware-type stuff coming through a WUI ... is, uh ... not my
favorite way to do things. I'd much rather a semi-readable, hand-edited
Wiki.
Yep. I see the calendars as simple, authoritative ics files. One for all
the meetings, one for events, one for release schedule for FC. That's it.
I'd like to edit via the Web, get email reminders, and perhaps a
way to
schedule/interact with the system via properly formatted email messages.
We really need something we can make PO files from, if we want to
keep
content easily updated. These can then be checked into CVS and pulled
out by the trans teams.
Remember, they have existing tools, we do not. We must make our tools
use their tools, from the start. We can request an odd-ball, one-off
translation now and again, but not on a regular basis.
So, what can we make PO files from? Is the current f.r.c system in CVS
good enough for this?
I'm for making f.r.c a single RHAT-backed, FF-approved marketing
message
with five links and a pretty theme.
+1, when we get there, and the sooner the better.
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
11:09 a.m.
On Tue, 2005-12-06 at 09:37 -0500, Greg DeKoenigsberg wrote:
On Mon, 5 Dec 2005, Karsten Wade wrote:
> Very, very, very lightweight calendar, please. I find that they full-
> featured groupware-type stuff coming through a WUI ... is, uh ... not my
> favorite way to do things. I'd much rather a semi-readable, hand-edited
> Wiki.
Yep. I see the calendars as simple, authoritative ics files. One for all
the meetings, one for events, one for release schedule for FC. That's it.
Fine enough. :)
> We really need something we can make PO files from, if we want
to keep
> content easily updated. These can then be checked into CVS and pulled
> out by the trans teams.
>
> Remember, they have existing tools, we do not. We must make our tools
> use their tools, from the start. We can request an odd-ball, one-off
> translation now and again, but not on a regular basis.
So, what can we make PO files from? Is the current f.r.c system in CVS
good enough for this?
No. xml2po is what we use for documentation, and the stuff in CVS is
far from that.
That said, if we have a regular $FORMAT the files are in, we could task
someone with writing or modifying a tool to create PO files from
whatever.
That said, it is probably better to do the site in XML, instead.
- Karsten
--
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Content Services Fedora Documentation Project
http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject
12:21 p.m.
On Tue, 6 Dec 2005, Karsten Wade wrote:
That said, it is probably better to do the site in XML, instead.
OK. Let's get started. What do we need to do?
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
7:56 p.m.
On Mon, 5 Dec 2005, Patrick Barnes wrote:
Well, I think we all have a pretty good idea of what standard
features
of a CMS are.
Instead of making that assumption, can we get those features up and listed
on a web page?
-- Elliot
Unanswered questions in The Matrix: What happens if you take both the red
pill AND the blue pill?
8:33 a.m.
Can I have this whole email in "bullet points where Patrick tells us what
to do"? :)
--g
_____________________ ____________________________________________
Greg DeKoenigsberg ] [ the future masters of technology will have
Community Relations ] [ to be lighthearted and intelligent. the
Red Hat ] [ machine easily masters the grim and the
] [ dumb. --mcluhan
On Mon, 5 Dec 2005, Patrick Barnes wrote:
Okay, I've read over all the posts that have sprung up on this
thread
today, and here's how I see it.
Basically, it sounds like everyone is leaning in one of two directions:
a.) Drupal is great except that it runs on PHP.
b.) CVS and good, old-fashioned web skills are a great combination.
Well, I think we all have a pretty good idea of what standard features
of a CMS are. So lets start from there.
* How do we break down everything we need between the wiki and CVS?
We can do calendars using whatever calendar software the user
prefers and iCal files.
We can continue to track tasks on the wiki, but is that process
working well enough for everyone? Do we need an alternative? Would
calendars with to-do lists work better?
We probably need static content for translation. What are the pros
and cons of using the wiki for this? CVS? Wiki with regular exports
and touch-up for CVS?
We want revision control. Both the wiki and CVS can provide this.
We want help tickets. How can we manage this using the wiki, CVS,
and Bugzilla?
If we can answer these with smiles on our faces, there's no real need
for separate CMS software. Can anyone think of other needs to add to
this list?
If we decide we need a CMS solution, what can we do to make a PHP
solution like Drupal as secure as possible? We can disable XML-RPC.
What other features would we need to disable? Would this cripple Drupal
beyond usefulness? What about access; do we want it to be as open as
the wiki, or do we want to tighten it a little to protect it? We might
in particular want to address isolating Drupal (having it on a server by
itself) and trying to add protections for user information, should it be
compromised.
Also, a point that was brought up elsewhere was CVS access to MoinMoin.
Is this something we need or want? Most of MoinMoin would have no need
for CVS access. Only the plugins and themes would really be sensible to
allow CVS access to. We might also want to consider this for any CMS
solution we choose.
Finally, there's the domain consideration. Thus far, we've been talking
about setting up the CMS solution on fedoraproject.org. I think that if
we do choose Drupal or another CMS, we should do exactly that. What if
we use the infrastructure that is in place for fedora.redhat.com? I
think if we choose to go the CVS route that we should try to put it on
fedoraproject.org. We do still want to keep fedora.redhat.com, at least
for Red Hat's own messages about Fedora. Is this something we can do?
My personal opinion so far: I think we can make CVS, MoinMoin, and
Bugzilla work for our needs. I'd like to see CVS on fedoraproject.org.
I think that we should use the same account system to manage access to
fedoraproject.org as we use for fedora.redhat.com, to eliminate having
two sets of web admins. I'd like to move what we have at
fedora.redhat.com in CVS HEAD over to fedoraproject.org and begin
working on it. We can replace the content at fedora.redhat.com with a
very basic bit of information that relays Red Hat's message about Fedora
and explains what the exact relationship is and what Red Hat does for
Fedora. I'm with Seth in that I would like to eliminate as much PHP as
possible. We currently have a little PHP in use for fedora.redhat.com.
It is all very simple and generates static content, but I'd like to see
it eventually replaced with Python anyway. If we are going to use
Drupal, I'd like to see it as isolated as possible and configured by the
most paranoid people we can find. I don't want to rule out finding a
Python CMS solution, and would love to see everyone who can providing
reviews and insights to that end.
Thoughts?
--
Patrick "The N-Man" Barnes
nman64(a)n-man.com
www.n-man.com
--
Rate my assistance! http://rate.affero.net/nman64/
8:51 a.m.
On Mon, 2005-12-05 at 16:58 -0600, Patrick Barnes wrote:
Okay, I've read over all the posts that have sprung up on this
thread
today, and here's how I see it.
Basically, it sounds like everyone is leaning in one of two directions:
a.) Drupal is great except that it runs on PHP.
I don't agree with this statement even a little bit. Drupal is
amazingly complex and deep application. It goes far beyond what we've
explained is our needs and that tends to mean we end up with huge
portions of it that will be questionably-well audited and interfaced by
us. This would be fine if it were a desktop publishing app - but it's a
web-facing application and that makes it dangerous to us.
We can continue to track tasks on the wiki, but is that process
working well enough for everyone? Do we need an alternative? Would
calendars with to-do lists work better?
I've never seen a user class where shared calendars help, at all.
ics files are much more reliable and easier to debug. :)
-sv
6716
days inactive
6725
days old
websites@lists.fedoraproject.org
39 comments
8 participants
participants (8)
-
Elliot Lee -
Gianluca Sforna -
Greg DeKoenigsberg -
Ignacio Vazquez-Abrams -
Karsten Wade -
Patrick W. Barnes -
Rahul Sundaram -
seth vidal