Since I answer these questions regularly, as has been this history of this discussion, I’m hammering it out in one location forevermore.
A wiki is a lovely thing, in its own way and when used properly. It is a community documentation tool, making it very, very easy to collaborate on creating ad hoc or planned out content. It significantly lowers the barriers to documentation and greatly increases the contributors to docs. Yay wikis!
But a wiki is not a CMS, just as wiki formatting is not DocBook or ODF XML. One is a useful, easy collaboration tool. The other is what the big boys wear when they go get muddy in the ball field. The real gear.
What does a CMS do natively that a wiki does not?
- Makes it easy to add someone to a publish chain with minimal training.
- Makes it easy to segment and control access to write, edit, publish, and read content.
- Has a method for expiring content after a period of time or set of conditions has occurred.
- Can accept any document into the work flow, such as ODF, PDF, HTML, and plain text.
- Designed around a principle of work flow and user role. This allows for content to move from writer to editor (and back and forth), then to a publisher. This is a simple way of enforcing the basic formal writing paradigm. You want someone to fact and grammar check your work before it is put forward as complete.
- Are close enough in spirit and function to a blog that many of the same publishing paradigms can be applied, without being locked in to the limitations of a blog engine solution.
What else is good about a CMS?
- Look and feel is made really easy to manage. All the sites we put under the CMS can snap in to a common design template.
- Provides rudimentary to advanced version control. Minimal requirement is to allow roll-back of content. Advanced tools provide full VCS or front for another VCS.
- Pick the right one, and the robust plug-in community will have many things already done for us.
- It could have a sweet WYSIWYG editor, so it improves on the typical wiki experience.
- You can still collaborate on the wiki as an authoring and drafting space, then move the final work as snapshots in to the CMS. This is akin to what we do for the release notes.
- Should improve a team’s workflow at the reduction of a wider field of input.
- This is why we use it for a limited kind of content that is produced by a team and made to be more static, which makes it easier to translate.
- Examples of that are: Legal and licensing content; packaging content; formal documentation such as the Installation Guide and Documentation Guide; target pages written by Marketing for releases; mission statements; and so forth.
Where do we want to use a CMS?
Current examples are:
- http://fedoraproject.org*, non-wiki content:
- http://fedoraproject.org/wiki/Legal (*to move out of the wiki)
- http://fedoraproject.org/wiki/Licensing (to move out of the wiki)
- http://fedoraproject.org/wiki/Packaging/Guidelines* (to move just the guideline pages out of the wiki)
What do we need to look for in a CMS?
I’m going to go hold that discussion on fedora-websites-list, if you are interested. That’s also a good place to raise concerns and suggestions about which pages should move in to a CMS.
When we get together a working list, there will surely be a deliciously collaborative wiki page to go with it, and I’ll publish another post about it.