CMS Decision

[Greg DeKoenigsberg]

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 at n-man.com
> 
> www.n-man.com
> -- 
> Rate my assistance!  http://rate.affero.net/nman64/
> 
> 
>