From Fedora Project Wiki

(adding some text that we are not replacing the wiki)
(→‎Must have: Clarified how the CMS must attach to FAS.)
Line 52: Line 52:
* Proactive, security minded developer community that is ...
* 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 via the json interface
* RSS
* RSS
* L10n that doesn't break the translator workflow
* L10n that doesn't break the translator workflow

Revision as of 16:32, 22 January 2009

Scope requirements for a potential usage of a CMS underneath specific content delivery sites; owner quaid. This is not a replacement for the wiki; it is a supplement that would manage less than 10% of content on fedoraproject.org.

Background

The CMS does not replace the wiki.

The purpose of the CMS is to cover the smaller portion (~10%) of Fedora content that needs better management. A CMS should cover the more restricted areas of content, such as the front page of fedoraproject.org or the formal documentation website.

The other 90% of content is managed collaboratively in locations such as the wiki and fedorahosted.org. The purposes and methods of a wiki and a CMS are often orthogonal, regardless of similarity in tool design. For this reason, do not make the mistake of thinking that one could replace the other in a meaningful way.

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

Target (sub-)domains and paths

Time frame/schedule

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

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 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
  • 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

  • None yet

Team requirements for deployment and maintenance

The threads looking for a team are found here:

We are looking for a team of people who want to deploy and maintain a new CMS for the Docs Project. It may become the CMS that runs all of fedoraproject.org that is not a wiki.

Which CMS? There's the fun part. The project team picks their favorite. Best is if they are already passionate about a particular CMS solution.

Scope of work

  • Deploy the installation to Fedora Infrastructure
  • Maintain it as part of the Infrastructure and Websites teams
  • Have experience with the CMS to be able to expand it to meet Fedora's needs, preferably as part of the upstream
  • Be willing to package whatever is needed for Doc's CMS instance that isn't already in Fedora
  • Work as part of a team of three or more fellow Fedorans
    • No more than one of the teammates should already be busy with work in Fedora Infrastructure. The goal is to increase the pool of people, not divide it further.

Skills needed

  • Web systems administration
  • Design (graphics, CSS)
  • Coding (PHP, Python, Java, etc.) in the particular CMS solution
  • Some understanding of content management.