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?

> 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.

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!

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.

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.