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