CMS focus and scope

[Karsten Wade]

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