From Fedora Project Wiki
Summary
Hardware Requirements
Features
Must have
! == Meets the requirement.
/ == Partially meets the requirement.
- == Does not meet the requirement.
| Requirement | Status |
|---|---|
| Good security record | |
| Proactive, security minded developer community | |
| Highly responsive, especially to security issues | |
| Flexible enough auth system to attach to FAS via the json interface | |
| 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 | |
| Be a CMS as a core function, not an add-on | |
| Handle making certain pages or content areas static/non-database driven | |
| Must not lock us in. Data should be portable to another CMS. |
Like to have
! == Meets the requirement.
/ == Partially meets the requirement.
- == Does not meet the requirement.
| Requirement | Status |
|---|---|
| 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 | |
| Be a modular design (v. monolithic) | |
| Have an active and large community | |
| Have support for DocBook |