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.
For content, a CMS fills similar roles that koji and bodhi do for software.
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?
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.
Comments closed — Trackbacks closed RSS 2.0 feed for these comments This entry (permalink) was posted on Wednesday, August 13, 2008, at 3:59 pm by quaid. Filed in Fedora, Wiki.
Some of your points are valid, but I don’t think you are taking a hard enough look at MediaWiki’s available features and plugins.
FlaggedRevs allows you to assign quality status to articles. You could have articles assigned as “Draft”, and “Stable”, or even assign version numbers, so that people know what version of Fedora the documentation is applicable to. It will even let you mark one revision as the one anonymous users will see, so that they won’t see documentation that isn’t ready. This extension is being used on the German Wikipedia.
$wgNamespaceProtection allows you to lock down edit permission to namespaces. You can assign permissions to different namespaces, and only allow users with that specific permission to edit.
I’d send this to the list, but I don’t feel like subscribing just to post one thing.
First, relying upon extensions instead of core features adds risk. We know we’ll need various plugin modules for whatever solution we choose, but if we have to import all the functionality via plugins, it puts us at a much greater infrastructure risk. For example, right now we implement ACLs in MediaWiki using a plugin that is no(t much) longer supported and (apparently) makes our wiki run slower. When we chose that solution, it seemed feasible, and now it is in the way of progress.
Second, I do think that it greatly helps the usability of an application when it is built to follow a certain pattern from the start. Fundamentally, a wiki and a CMS are different. Diametrically opposed, in some cases. One is about being as wide open as possible, the other is about content control. When an application adds functionality that was not part of the core philosophy, it is rarely as clean and useful as a proper implementation. When the functionality is opposed to the philosophy, such as adding ACLs to a wiki, you get risky complexity, suffering users, and a slower application.
So far this is based on my experience trying to shoe-horn content functionality into applications where it was not part of the original design scope. There are going to be exceptions to this experience, naturally, but I think those merely prove the ultimate rule I’m standing behind.
Hmm…I was really hoping you’d sell me on this, I really wanted to be 🙂 However I just feel like every point could also be solved by using a wiki.
To me, a CMS is a great and wonderful thing, if you don’t have a wiki. But having a CMS *and* a wiki seems like it will splinter documentation (which acutally sounds like the purpose). I worry that splintering will lead to complication and frustration in both developers and end users.
In the end…I think having the document is more important then how or where it’s documented.
> by using a wiki.
Sure, matching functionality can be achieved. It’s not hard to jam a feature in a web app and check it off the list. But does it belong there?
Be careful of feelings in this regard. We also need facts, experience, and problem scope that is independent of a fixed solution.
> developers and end users.
In fact, it’s entirely possible the Documentation Project may end up choosing a wiki-only way to author, translate, publish, and print full guides. The case would have be be very compelling and complete to replace the functionality we have with DocBook XML and the publican toolchain.
However, documentation is not the only content we need to manage. The tools that produce the static content on fedoraproject.org are elegant but have a fairly high barrier to entry. The point of a CMS is to lower that barrier while still keeping a framework that is more controllable than a wiki. Then we can add more people to be able to write, edit, and publish content on the main, more static parts of the public face on fedoraproject.org. I am also certain that it is going to help the Docs Project. Current publishing to docs.fedoraproject.org is probably the most archaic website tool still running for Fedora.
We need to make it possible to find documentation wherever it is, man pages in an RPM, pages in MediaWiki, or full-length guides from XML. Federation is more useful than consolidation.
For the purposes I’ve been discussing, the CMS is not for regular contributors. It is a special tool for more static content that needs a higher level of process before publishing.
Also, it’s pretty high on my personal list that we move up to a rich text editor for the CMS. I’m done with wiki syntax; it’s just a harder way to show formatting with zero contextual information. I’ll either tag with DocBook XML or use a rich text editor.
> how or where it’s documented.
Aye, that’s debatable. A document that is poorly written, inaccurate, out of date, or lacking of good practices doesn’t do you a lot of good just because it’s easy to find.
I didn’t make it clear enough that a CMS is not supposed to be a new tool for all contributors to hack around with. I think any project that wants to use it instead of the wiki is welcome to, but they do it at the loss of the wider community of wiki contributors.
FlaggedRevs is being used on the german wikipedia, and $wgNamespaceProtection is a built in feature.
Both add little risk, and will not slow down your site. Anything that has serious performance impacts isn’t considered by wikipedia.
> DocBook XML or use a rich text editor.
Is this the real reason you are suggesting a CMS?