Archive:CMS solution for Fedora Project websites

Scope requirements for a potential usage of a CMS underneath specific content delivery sites; owner quaid

Background

For information on the history and reasoning for this effort, read these entries:

• http://iquaid.org/2008/08/13/why-and-where-fedora-needs-a-cms-solution/
• http://iquaid.org/2008/08/19/fedora-cms-focus-and-scope/

Target (sub-)domains and paths

• http://fedoraproject.org*, non-wiki content:
  • https://fedoraproject.org/en/get-fedora
  • https://fedoraproject.org/en/join-fedora
  • https://fedoraproject.org/en/get-help
  • http://fedoraproject.org/wiki/Legal (to move out of the wiki)
  • http://fedoraproject.org/wiki/Licensing (to move out of the wiki)
  • http://fedoraproject.org/wiki/Packaging/Guidelines* (to move just the guideline pages out of the wiki)
• http://docs.fedoraproject.org*

Time frame/schedule

1. Scope need -- mid Sep.
2. List possible solutions -- 19 Dec
3. Vet solutions list -- 21 Dec
4. Run a test replacement for docs.fp.o -- 29 Dec?
5. Hackfest to bring up docs.fp.o -- 07 Jan
6. Finish -- 09 Jan
7. Explore www. replacement -- 28 Jan?

Tasks

• Hammer out scope list
• Vet solutions against scope requirements
• Install publictest instance
• Create a Fedora theme/skin for the app
• Roll to docs.fp.org
• Iterate bug and functionality fixes through F10 release

Solution requirements

Must have

• Good security record
• Proactive, security minded developer community that is ...
• Highly responsive, especially to security issues
• Flexible enough auth system to attach to FAS
• RSS
• L10n that doesn't break the translator workflow
  • Output for Transifex (PO/POT)
• Content workflow (write <=> edit => publish)
• Internal version control with rollback capability
• Content expiration (automatic)
• Multiple roles, e.g. writer, team lead, editor, publisher, managing editor
• Categorize/tag content for easy base organization
• Search that works
• Integrate with FAS
• Be a CMS as a core function, not an add-on
• Handle making certain pages or content areas static/non-database driven, such as for scaling during times of heavy resource demand
• Must not lock us in. Data should be portable to another CMS.

Should have

• OpenID
• Good WYSIWYG editor
• Easy to organize content by taxonomy, structured and ad hoc
• Support for draft->review->$foo->publish workflows
• Workflow to ship the content for l10n only at certain stages
• Workflow go back to a certain stage if a mistake/error is found in the source-language content by the translator
• Translators have a 'review' step in the workflow for translated content before it is published, so that they can see translations in context
• Modern technology with a vibrant community and likelihood of being popular beyond the next twelve months
• Good federation tools to make it easy to find disparate content through one UI
• One set of things it is great at, not be all things for all people

Other good qualities

• Be a modular design (v. monolithic)
• Have an active and large community
• Have support for DocBook

Raw list of CMS solutions that meet enough requirements

• APLAWS - https://fedorahosted.org/aplaws/ (ex Red Hat CCM)
• Drupal - http://drupal.org/
• Joomla - http://joomla.org/
• Midgard - http://www.midgard-project.org/
• Plone - http://plone.org/
• Wordpress - http://www.wordpress.org/
• SilverStripe - http://www.silverstripe.org/
• Ellington - http://ellingtoncms.com/ (*Proprietary, may not be suitable)