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