Create a knowledgebase in an enterprise wiki

= Step 1 - don't even go near the wiki, at least not yet! =

Some fundamentals to be worked out before you even embark on building the first page of your knowledgebase:


 * Some questions to think about and have answers for: Why are you doing it? Who will use it? What types of information will go into it? How does it fit with other tools you use within your team? Now admittedly you can work some of this out as you go along, but it doesn't hurt to think about it up front, because you can guarantee these are the types of questions others in your team will ask you almost immediately.
 * Who are the moderators/administrators/gardners/shepherds/(insert your own term) for your knowledgebase? Any successful coming together of people, be it in a meeting room or online, requires at least one person to facilitate. That means to set the agenda/direction, keep things on track, create a safe and welcoming environment for people to encourage them to contribute. It's critical that you have that resource identified for your knowledgebase, be it one person or a small group. The workload isn't heavy, but it does require persistence and discipline. We'll see later exactly what is involved.
 * When you've identified your facilitators start to think about what your first entries in the knowledgebase are going to be. Get a small team together to identify the starting topic pages that you will link to from your main page. All you need at this point are some broad thoughts - everything will evolve naturally once you get going in the wiki.
 * What's your one catch-all category? Categorization of pages is one way of making your knowledgebase easy to navigate plus categories enable your facilitators (see above) to keep tabs on the various pages that have been created. Create at least one initial category (what I call the ‘uber -category’) as the catch-all for all of the initial pages that you create. It makes sense to just make this initial category match the name of your knowledgebase, so for instance the uber category in the Project Collaborate knowledgebase is, you guessed it, Project Collaborate. There may be some other obvious categories to be starting with and if so, great, but it really helps to start with a minimum of categories up front – the content of the pages you go on to create should be the driver for the categories you actually need.

What makes a good wiki moderator/administrator/gardner/shepherd/(insert your own term)?
Here's the Wiki Patterns definition of a wiki gardner, which is pretty much what we're talking about here:


 * A WikiGardener is one who spends time attending to the quality, flow, and overall polish of content on a wiki.

The people best suited to this task tend to identify themselves, through their contributions to the wiki - be alive to that possibility and where people like this surface recruit and bring them into the fold but at the same time appreciate that anybody can contribute to this role, whether they are officially recognized by you or not.

Here are some other pointers about the type of people to target for this role:


 * Some knowledge of the subject matter being captured in the knowledgebase.
 * Good at structuring and organizing things.
 * Community-minded - in a lot of respects this role is all about providing to the community - making things neat and tidy and convenient for users of the knowledgebase.

=Step 2 - Start Building Your Knowledgebase=

Your first page
Any wiki knowledgebase starts with the first page. Let's consider this first page to be the 'portal' to your knowledgebase, this is the page you'll send people to. Your 'home' page so to speak.

What's in a name?
The great thing with most enterprise wikis is that it doesn't really matter what name you give to a page because if you change your mind later on and move it if you want. What this means is that if you change the name of your page in the wiki it never results in broken links - the wiki will tidy all of that up for you in the background, so even if you give out a URL one day but then change the name of the page the next it doesn't matter, the original URL will still function!

Now here's another cool feature of that particular function. Say we call our first page 'Simon's Movie Knowledgebase'. Some people naturally use film in place of movie, so we can cater for them, just in case they mistakenly type in Simon's Film Knowledgebase. We do this using a redirect. We create a redirect so that if anybody references or types in 'Simon's Film Knowledgebase' they will automatically be sent to the 'Simon's Movie Knowledgebase' page instead. This is a very powerful feature and worth taking advantage of. Even though you might have a wordy title for your page, you can also use a redirect to create a much simpler form, that makes it quicker and easier for users to access your page. E.g. we could create a page called 'Movies DB' that is a redirect to the longer 'Simon's Movie Knowledgebase'. It's the latter that we want people to access, but we figured most people would be happier just typing in the shorter name.

Advertising the 'name'
Assuming your target audience know about your enterprise wiki in the first place you can provide them with really easy to remember paths to your knowledgebase content - you leave them with a keyword or words. Here's one way how we do it on Project Collaborate. When we reference our knowledgebase in presentations we include the keyword or words they need to type (into the wiki) to view it. Below is our standard 'Wiki keyword ad' layout that we use within our presentations.



Creating your first (uber) category
Creating your category is simple. Just add it into your first page. View Help:Categories to see how to do this. When you reference a category for the first time the link to the category will show as red. The category will still function if you click on that link, but your wiki will prompt you to specify some text to describe what that category is all about - it will display the usual content edit window to allow you do this. For the time being provide some descriptive text about what this category is for and, importantly, specify a link to the main page within this category, i.e. the first page you created. Now make sure you add subsequent pages into this category - it's a good way of keeping tabs on what you've created.

=Step 3 - Building Structure and Consistency into your Knowledgebase= You can get a long way simply building plain pages and use of a few categories. However there is a time in the life of all knowledgebases when you really need to move things up a gear, and start getting into using some of the more sophisticated features of Pfizerpedia.

What are the signs that you need to move it up a gear?
Here are some signs:
 * Your initial category(s) are becoming jam-packed with pages.
 * Your main page(s) have become very long and it's proving hard to find things.
 * You have additional pages being created that are not connected into the rest of the knowledgebase.

Sub-categorise
Go in and take a look at your initial uber category. Take several steps back - take in the big picture. Looking across all of the pages sitting in that category - what patterns can you see. For instance in the Project Collaborate knowledgebase it was obvious to us that we were creating a lot of pages about OneNote, an application we have a particular interest in, so it was logical that we would create a sub-category called 'OneNote'. The beauty is we can place the 'OneNote' category within our 'Project Collaborate' category, so we can still navigate to all of the OneNote related pages from our uber Project Collaborate category, but they are all neatly cataloged in their own sub-category.

Include common navigation elements on every page
It's helpful to get some consistency across your pages in terms of some form of 'branding' and navigation. The Project Collaborate approach to his has been to define a wiki template that we include on every page. Wiki templates are bits of content that you create in a page, and then you reference that page from many other pages. The beauty is that you only have one place to go and update but that change automatically cascades down to all the pages that reference you template. So we create a header/menu bar as a template, and then reference that template on all our pages.

See the following examples of header templates:
 * See the Template:Project Collaborate Knowledgebase Header
 * Now see it in situ on the Project Collaborate page

If you examine the Project Collaborate header it actually has links to some of sub-categories, which we use as a convient means of providing navigation across our growing content.

Please feel free to view the template header, click on edit, copy our mark-up, and then go and create your own header template for your knowledgebase.

Ensure new knowledgebase pages are created your way
Over time you will start to identify standard layouts you wish to apply to the pages in your knowledgebase, e.g. a header menu template, an uber category, plus some specific information based upon the type of page being created. There are three ways of approaching this:


 * Rely on your moderators/wiki gardners to apply the standard layout to pages.
 * Install and use the MediaWiki InputBox extension which will enable you to preload new pages with whatever content you want plus display a special set of instructions depending on the type of page being created.
 * Install the Semantic Forms extension to create a more traditional forms based application within your wiki.

=Step 4 - Keeping on top of things= Your wiki provides a number of ways for you to keep on activity within your knowledgebase:


 * MediaWiki allows you to watch specific pages of interest, meaning you get an email alert when another user makes a change. See mediawikiwiki:Help:Email Alert Functions for more details.
 * You can subscribe to MediaWiki wikis using RSS including recent changes to a specific page or for articles in a given category or newest articles in a category.
 * View Special pages for a list of additional reports and list.

=References=

= Useful links =
 * Here's a useful article on 'Priming the Pump' - how US government agencies have approached setting up their wiki knowledgebases.