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@xxxxxxxxx
www.n-man.com
--
Rate my assistance! http://rate.affero.net/nman64/
Attachment:
signature.asc
Description: OpenPGP digital signature
