Structure a knowledge base

The MediaWiki software regulates access to documents by default via the namespaces mentioned in Part IV – which ensures, for example, that guidelines can only be edited by authorized persons.

But the concept does not always fit. For example, it is difficult to protect all documents of a department with it. Therefore, many organizations decide to set up the permissions for their MediaWiki the other way around: There, administrators assign the namespaces to teams and workgroups and use the categories to mark the document types.

This approach may also be understandable and feasible, but it has serious drawbacks. Namespaces in MediaWiki are useful to set up a room for a group, for example, but the concept does not scale. As soon as a wiki has many groups, the administration of access rights to the namespaces becomes extremely time-consuming, which not least increases the risk of errors.

Even though the appropriate permission concept always depends on the individual use case, most knowledge bases primarily want to make content available for sharing, not lock it away. This is exactly where flat authorization concepts prove to be more advantageous, especially in the long-term perspective. To gain the necessary authorization protection for a critical team or departmental content, separate (sub-)wikis are a good idea (see figure 1)

Figure 1: Within the central knowledgebase, content can be divided into separate (sub-)wikis, for which different access rules apply

This allows HR staff to work in a separate wiki without having to worry about accidentally releasing logs or other internal application management information to unauthorized users, for example. In the central wiki with the internal knowledge base, you only publish the content that is important for everyone, for example, the employee handbook, vacation regulations, training measures, and so on. The management wiki is also neatly separated from the information that most employees need for their daily work.

The basic structure of the wiki remains the same in the subwiki: Namespaces for document types and the categories for topic groups can be different at team level, but they do not have to be. You should avoid the “topic groups” as long as possible – they add another level of complexity that is not needed in most cases. Keep everything as lean as possible.

Setting up a new wiki must be done centrally and according to defined criteria, otherwise, there is a risk of what knowledge managers call the “Confluence effect”. Atlassian’s Confluence wiki software also relies primarily on so-called “spaces” to organize content. Any user can create Spaces with a few mouse clicks, which makes them very attractive for team work.

However, they quickly prove to be the horror of administrators: they quickly find countless Spaces that quickly become orphaned, and are thus confronted with the opposite of a collaborative knowledge base. The goal of working together on content and structured topics is thwarted by the massive growth of knowledge silos.

BlueSpice farm is different: Here you get the advantages of both worlds. A central marketplace for knowledge and, where necessary, séparées in (sub-)wikis that can be set up without much effort.

Hallo Welt! GmbH is the company behind the open-source enterprise wiki software BlueSpice, which is distributed in more than 160 countries with over 1 million downloads. The Regensburg-based company builds collaborative software for knowledge management and online documentation since 2007.