Weeding the Wiki Garden

I just started at my new job about 4 weeks ago. The company has been up and running for almost 5 years, and so there is a lot of history. To be effective in my job, I need to understand the history of the product and the discussions that lead to its current design.

The company wiki seemed like a great place to go.

However, I had trouble making progress. As like with most wikis, it had grown over time and its structure was fragmented. The SocialText blog summarizes it pretty well:

Like any organic process, however, it can be messy. There will be duplicate pages with slightly similar names, links to nonexistent pages, pages that aren't linked to, and so on.

My biggest problem actually was in the number of places where technical information was stashed. I kept bumping into new pages in different spaces in the wiki that contained important information. It was all over the place.

Wiki Gardening Advice

Frustrated, I looked for advice on how to properly perform gardening on a wiki. I had done this before back on the WebLogic Portal wiki, but that was a product I knew well. I wanted to see if there was general guidance for this kind of thing, especially for someone walking into a wiki without a lot of context.

The best document I found was from SocialText in this blog entry: Wiki Gardening Tips

I did everything from that list, plus a couple more:

Deferred Weeding

Instead of removing every page that I felt needed pruning, I tagged some with label "weed". This will allow me to ask a veteran's advice before removing the pages I wasn't sure of.

Two Use Cases: Browse and Search

Be aware of the two main use cases: browsing and searching. Newbies like me will be doing mostly browsing, because we don't know what we need. We need to be able to have a rational navigation structure so we can systematically read pages from the site. On the opposite side are the veterans. Veterans do searches since they know what they are looking for.

This is important to keep in mind when gardening the wiki. When working with a page, it is helpful to know which use case(s) are important. It will help you to decide how to work with it.

For pages that provide basic information, make sure they are easily found in the place people will expect in the navigation hierarchy. For pages that relate to some obscure detail - don't worry too much about where it lives. Those pages are probably only going to be accessed via search.