CMS Decision

Tue Dec 6 04:30:08 UTC 2005

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 at 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 at n-man.com

www.n-man.com
-- 
Rate my assistance!  http://rate.affero.net/nman64/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/websites/attachments/20051205/1680c812/attachment.sig>