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:
- https://fedoraproject.org/en/get-fedora
- https://fedoraproject.org/en/join-fedora
- https://fedoraproject.org/en/get-help
- 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)
- http://docs.fedoraproject.org*
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.
I agree that fedora needs a cms, for single users like me, its more easy to search and visit sites build with a cms, right now i can say that for me its a little difficult to follow the content at fedora sites! Waiting for the news…
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.
If you *really* need to restrict viewing privileges, then you have a good reason to use a CMS, but otherwise, you should take a look at:
http://www.mediawiki.org/wiki/Extension:FlaggedRevs
and:
http://www.mediawiki.org/wiki/Manual:%24wgNamespaceProtection
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.
In reply to Ryan:
It is true that a wiki can be modified with extensions to mimic many of the useful features of a CMS. My concerns about that approach are two-fold:
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.
“Where’s that document, the wiki or the CMS?”
“I’m comfortable with the wiki syntax, why do we need to learn another one”
In the end…I think having the document is more important then how or where it’s documented.
I can’t help but feel like adding a CMS into the mix is a step backwards. I’ll gladly be proved wrong! 🙂
In reply to Leif:
> 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.
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.
> 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 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.
> “Where’s that document, the wiki or the CMS?”
“Where’s that software, the source repository or the yum repo?”
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.
> “I’m comfortable with the wiki syntax, why do we need to learn
> another one”
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.
> In the end … I think having the document is more important then
> 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 can’t help but feel like adding a CMS into the mix is a step
> backwards. I’ll gladly be proved wrong! 🙂
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.
> 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.
Is this the real reason you are suggesting a CMS?
Perhaps, Enano CMS could be tailored to the needs of the Fedora Project. It has wiki, security settings, and static modes that can be activated per-page, per-section, or throughout the whole thing. Possibly the Fedora Project theme could be converted to an Enano CMS theme so that all of it matches together. The Enano CMS 1.1.x series is improved by leaps and bounds over the 1.0.x series