After my post, Why and where Fedora needs a CMS solution, which included a follow-up discussion on fedora-websites-list, there were questions and gentle dissent. I think those stemmed mainly from it not being clear what the intended scope is for a CMS solution. There were also calls for one or another specific CMS solution, which we’ll get to in due time.
One concern expressed in comments to my post were two interrelated ideas: that contributors were going to be forced to use a CMS instead of whatever solution they prefer (i.e., a wiki), and that this would end-up splitting content into different areas, which is confusing for everyone.
The scope of the CMS solution that I am looking for is to cover two specific websites: www.fedoraproject.org and docs.fedoraproject.org. The ‘www..’ site hosts content that is relatively static, usually only changes between releases, and is part of a management and translation process. The ‘docs…’ site hosts full-length documentation that has been drafted, edited, translated, and organized into topics and by version/release. The wiki continues to be a community documentation site, focusing on content of the smaller and easier to digest size and scope that works best in a wiki format, with two audiences: contributors and end-users, in that order.
In addition, there are some specific content topics that have lived on the wiki as their canonical home, which has required them to have an access control list (ACL) defining who can edit. My goal is to get that content’s canonical home moved to the CMS within the www container.
People who work on that more controlled content as writers and editors do not need to switch from the wiki as their preferred authoring tool. It is the formal publishing location that we need to change to be within the CMS. Then we can use the CMS’s native access control tools. This process matches what we do for the release notes, where the community writes and edits content in the release notes beats, but the final publication locations (docs.fedoraproject.org and the fedora-release-notes package) are not wide-open for at-will changes by anyone in the community.
This follows a policy that Fedora Documentation has long used, which Fedora Websites began to follow a few releases ago. For multiple reasons, certain types of content cannot have the wiki as their canonical reference point. One case is where the content integrity is highly important to the very existence of the project, such as legal matters and packaging directions. Content is so powerful in this area that the changing of even one word can put the entire project in jeopardy.
Anther case is when the translations and the original must be in tight synchronization, which is not trivial in a free moving wiki environment. The case that started it all off for the Websites and Infrastructure team was the fundamental slowness of any dynamic content system when the pages are being hammered for information after a release.
(Note to self: the CMS solution must be able to make specific pages or content areas static, serving them from built web components and not out of the database.)
After the Fedora Websites meeting we just had, there is now a specific task I am working against, and a rough timeline. Please continue to leave comments here, on fedora-websites-list, or directly to me via email.
In my understanding, the main reason to move the http://www.fp.o pages away from the wiki and to make them static was performance: around a release, when the traffic increase a lot, it hammered the entire website (including the wiki).
So putting back a CMS will not create the same problem again? Or the idea is to use the CMS only behind the scene to edit the content and staticize the pages before publishing them?
@Nicu: That is solvable by using caching mechanisms so that the CMS doesn’t need to use multiple database queries to build up the page.
Something else: will we use this for FWN stuff too (news.fp.o)?
@Couf: Good question, I’d forgotten that FWN was looking in to a CMS solution.
We’ve mainly discussed using WordPress MU for FWN. That would leave the workflow as a manual process.
FWN would be welcome to use any CMS solution, but it’s not on my direct must-do list.
Perhaps, Enano CMS could be tailored to the needs of the Fedora Project. It has wiki, security settings, and static modes that can be activated per-page, per-section, or throughout the whole thing. Possibly the Fedora Project theme could be converted to an Enano CMS theme so that all of it matches together. The Enano CMS 1.1.x series is improved by leaps and bounds over the 1.0.x series.
There is a fine-grained ACL system, a high security user authentication system, and a lot of expandability. Fedora’s User system that connects koji, bodhi, and other systems together could be integrated into the Enano CMS system with a plugin module.