From Fedora Project Wiki

Line 52: Line 52:
 
* Be a CMS as a core function, not an add-on
 
* 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
 
* 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 ===
 
=== Should have ===

Revision as of 16:02, 10 January 2009

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

Target (sub-)domains and paths

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

Vetted list of CMS solutions to try