From Fedora Project Wiki

(Add a note stating that DocBook support would be a good thing to have in a CMS)
(renaming sections to include verb, then rewording lists to support that verb)
Line 21: Line 21:
 
== Solution requirements ==
 
== Solution requirements ==
  
=== Must ===
+
=== Must have ===
  
 
* Good security record
 
* Good security record
* Proactive security mindedness of developer community
+
* Proactive, security minded developer community that is ...
 
* Highly responsive, especially to security issues
 
* Highly responsive, especially to security issues
 
* Flexible enough auth system to attach to FAS
 
* Flexible enough auth system to attach to FAS
 
* RSS
 
* RSS
* l10n that doesn't break the translator workflow
+
* L10n that doesn't break the translator workflow
 
** Output for Transifex (PO/POT)
 
** Output for Transifex (PO/POT)
 
* Content workflow (write <=> edit => publish)
 
* Content workflow (write <=> edit => publish)
Line 40: Line 40:
 
* 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
  
=== Should ===
+
=== Should have ===
* Do OpenID
+
 
* Have a good WYSIWYG editor
+
* OpenID
* Be easy to organize content by taxonomy, structured and ad hoc
+
* Good WYSIWYG editor
 +
* Easy to organize content by taxonomy, structured and ad hoc
 
* Support for draft->review->$foo->publish workflows
 
* Support for draft->review->$foo->publish workflows
* Be able to ship the content for l10n only at certain stages
+
* Workflow to ship the content for l10n only at certain stages
* Have the workflow go back to a certain stage if a mistake/error is found in the source-language content by the translator
+
* 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
 
* Translators have a 'review' step in the workflow for translated content before it is published, so that they can see translations in context
* Be written on modern technology with a vibrant community and likelihood of being popular beyond the next twelve months.
+
* Modern technology with a vibrant community and likelihood of being popular beyond the next twelve months
* Have good federation tools to make it easy to find disparate content through one UI
+
* Good federation tools to make it easy to find disparate content through one UI
* Not try to be all things but for the things we need, do it right
+
* One set of things it is great at, not be all things for all people
  
 
=== Other good qualities ===
 
=== Other good qualities ===

Revision as of 04:14, 23 August 2008

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, vet solutions -- mid Sep.
  2. Bring up docs.fp.o -- early Oct.
  3. Tweak through F10 release
  4. After F10, migrate www. to tweaked solution

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

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