I just posted an update http://iquaid.org/2008/08/19/fedora-cms-focus-and-scope/ ... which I reposted below[1]. Here is the task's project page: https://fedoraproject.org/wiki/CMS_solution_for_Fedora_Project_websites The schedule currently allows a long time (~1 month) for scoping and vetting solutions, then another few weeks for installing a version to test as a replacement for docs.fp.o. Based on that experience and tweaks done during the F10 release process, we can plan for www.fp.o _after_ F10 releases. That way we use our stable systems through the release where it counts the most. In case it is not obvious, the intention of the schedule sync is to provide the full F10 Release Candidate release notes from docs.fp.org via the new CMS. - Karsten [1] from http://iquaid.org/2008/08/19/fedora-cms-focus-and-scope/ Fedora CMS focus and scope 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. -- Karsten Wade, Sr. Developer Community Mgr. Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : AD0E0C41
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-websites-list mailing list Fedora-websites-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-websites-list
