CMS Decision

[Karsten Wade]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/websites/attachments/20051205/4d5e0aa8/attachment.sig>