KDE Wiki Meeting Report

Two days of KDE Wiki Meeting are over. Danimo, Frank, Lydia, Dominik, Milian, Thorsten and me met in Berlin with the goal to get some more structure into the KDE Wikis and provide a plan for the future, where to put content. I'm happy to say that we accomplished this mission.

While we have TechBase for high quality technical documentation for a while, and the corresponding UserBase for end-user information since last year's Akademy, we were still missing a proper place for community content, especially for content which is mostly community internal, of more transient
nature, or just not finished yet. The idea to create a dedicated Wiki for this community content was floating around since a while, and now we created it at community.kde.org.

To make it clear which content belongs where, we created a mission statement, which gives clear guidance about which Wiki serves which purpose. You'll find it at wiki.kde.org in a few days. The basic idea is that userbase.kde.org provides end-user information, techbase.kde.org contains high-quality technical content for third party developers, distributors, and system administrators, while community.kde.org acts as a collaboration space for the community.

Actually community.kde.org already existed. It contained the charter of the community working group. But to keep things short and to the point we decided against creating another base, but go with the logical and short community.kde.org domain. The charter of the CWG will find a new home on the KDE e.V. web site.

With the creation of community.kde.org we can also shut down at least two places where community content ended up due to lack of a proper home. We'll shut down the old Wiki, which was available under wiki.kde.org, but whose content wasn't that well maintained, and which didn't fit too well in KDE's infrastructure because of technical reasons. We'll also move all the pages which piled up under the Projects directory on techbase, but in almost all cases didn't really belong there and also didn't match the quality requirements of being polished content targeted at technical people who aren't necessarily familiar with the community. Most of these pages find a proper home on community.kde.org, though.

In addition to the general cleanup and structuring we also worked on some improvements of the existing Mediawiki installation. Danimo replaced the OpenID login UI by a much more usable version, Milian finally managed to get rid of the annoying horizontal scrollbars inside the page on code samples, and we also discussed some more improvements, like the intensified use of templates and the introduction of a way to rate and classify documents on the Wiki to indicate their quality and make it more obvious what needs more work.

As a side track, we had an interesting discussion with some Tiki developers. They have an amazingly powerful and feature rich system, which would
be able to solve some of the problems, we still have with our Wikis, such as translation infrastructure. For now we decided for the sake of consistency and simplicity to stay with the current Mediawiki installation, but maybe Tiki is an option in the future.

Working on the Wikis was fun and satisfying because we got some concrete results, which will simplify maintaining KDE web content in the future. But besides all the work we also didn't forget to relax with a great dinner at a Chinese restaurant at Berlin-Adlershof, enjoying a great buffet, including cheese cake for dessert.

Thanks go to the KDE e.V. and Qt Software for supporting the meeting.


Three wikis is TERRIBLE, even worse than two wikis. You're just training people to ignore wiki navigation and use Google, because you're making them guess where to look and breaking wiki search (searching three wikis for possible answers is ludicrous). And you're also spreading contributors thinly (userbase.kde.org has a low contribution rate). And you're also breaking MediaWiki's powerful intra-wiki link handling (red for non-existing pages, easy REDIRECTs, "what links here", etc.) which all falls apart when you spread content across wikis. Three times the fail for no benefit.

Here's a specific example. Should the details of installing KDE-Windows that I and others edited remain on techbase along with the rest of the KDE-Windows stuff, or sit sad and lonely on userbase? I don't know, and others won't either. If I move it the links break, search breaks, and an important piece of KDE-Windows lore that applies to both developers and users is gone from the existing category. Suckage all round.

"To make it clear which content belongs where,"

  • [[Category:for developers]], [[Category:for users]], [[Category:Community]] in one wiki. Done.
  • Better yet, use a template for each target audience that categorizes and also displays distinctive colors and imagery for each one.
  • In that one wiki, create portal pages for each target audience.

I'd like to be more positive talking to a stranger, but I don't see any bright side to more than one wiki for KDE information.

By skierpage at Wed, 07/01/2009 - 05:51

You brought up some good arguments for putting everything in one Wiki, but there are also good arguments for splitting it up. The different quality requirements for example lead to pollution of the Wikis which set higher standards. You can see this today with all the stuff under the Projects directory on techbase. This makes the Wiki search pretty pointless, because it finds all kind of stuff, but not what is meant for the target audience of this Wiki.

Let's give this some time. We'll clearly communicate which content belongs where. So ideally everything just falls into place. If this doesn't work out, we can revisit the Wiki split, and can still merge it together in one big fat Wiki.

By Cornelius Schumacher at Wed, 07/01/2009 - 22:42