From Fedora Project Wiki

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
    • Alternately use OpenID, but must authenticate with useful group information for permissions
  • Provide useful content and system data (recent changes, etc.) as 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

  • Use OpenID for authentication.
  • Good WYSIWYG editor.
  • Easy to organize content by taxonomy, structured (categories) and ad hoc (tags, categories).
  • Support for draft->review->$foo->publish workflows
  • Workflow to ship the content for l10n only at certain stages
    • New functionality that might need to hook to external toolchains or otherwise be able to process XML+PO.
  • Workflow to go back to a certain stage if a mistake/error is found in the source-language content by the translator.
    • New functionality that might need to hook to external toolchains or otherwise be able to process XML+PO.
  • Translators have a 'review' step in the workflow for translated content before it is published, so that they can see translations in context
    • New functionality that might need to hook to external toolchains or otherwise be able to process XML+PO.
    • Long requested feature from translators who are having challenges getting the toolchain to work locally for building documents to review.
  • 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 way to think of this is as a complex search that can find content related to a topic, tag, category, or keywords in more than one location (wiki, main website, Docs site, indexed feed of posts to fedorapeople.org, fedoraforum.org, etc.) It could also be just more content options outside of the CMS itself that the CMS is aware of and can expose in context.
  • 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
    • Source content and import DocBook XML
    • Potentially use external toolchains to process DocBook
    • Ultimate dream? WYSIWYG editor works directly on DocBook XML source in a version control system as just another $text_editor.

Raw list of CMS solutions that meet enough requirements

Vetted list of CMS solutions to try

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.
Retrieved from "https://fedoraproject.org/w/index.php?title=Archive:CMS_solution_for_Fedora_Project_websites&oldid=373934"