Managing Knowledge
Over the years, Headscape has built and worked on a lot of websites, probably somewhere in the hundreds, no-ones counting. I, on the other hand, have been with Headscape for just 16 months. Currently we have 4 full time developers plus a contractor. Usually we are all working on different projects, each with their peculiarities and oddities. Often a client requires us to make changes to an old site, upgrade hosting or change the way features work, and without knowing the history of a project, this can be a minefield.
So we needed a solution. Turn’s out wiki’s are quite nifty at this.
We tried out a few, and being a .NET company, experimented with a few free or open source options, but ended up settling on MediaWiki. It’s easy to setup and get started, reliable, and there are heaps of plugins floating around. The hardest part is content population, but once a couple of us got excited about the idea, we soon had the foundations of a knowledge base.
The benefits of a wiki are clear, being able to link information together and categorise it is invaluable, and the principle of quick editing is ideal. This allows us to gradually build up the fragments of information that hold a project together. Projects that are linked by a technology or hosting platform can be easily referenced, enabling a developer to solve problems faster and track down solutions smarter. Eventually, maybe. The experiment is too early to see how well it’s going to work, but it should be interesting.
The downsides to this approach are learning curves and structure. MediaWiki is designed for managing large numbers of isolated pages, so naming conventions are crucial to finding information and avoiding confusion. Fortunately, wikipedia has already developed conventions ready for adoption, so this is a good starting point.
Before installing MediaWiki, I had little experience with wikis, so it took some learning to get up to speed with formatting, but it soon came naturally. This can be a stumbling block for others, so the next step is to ensure everyone has a basic understanding of editing a page. Having knowledge of wiki editing is a skill in it’s own right, so the time spent learning is worth it.
We’ll see how things pan out.
Tags: organisation, programming, wikis
October 30th, 2008 at 10:13 pm
Great post.
I’ve been in the middle of developing a process for web development and working with a team of developers for a while now.
So would you say that the information in the Wiki would be the same or similar information you would put in some kind of source control such as SourceSafe or SVN?
Thanks for the insight.
Jonathan
October 31st, 2008 at 12:02 am
Hey Zuno, glad you liked it.
I would keep SVN comments for information specific to the file(s) being checked in. Generally if you’re working on a file, it makes sense to check it’s version history first to understand how it got to this point.
The wiki should be for generalised information on a website / project, and information that is useful across multiple projects. A wiki’s real power lies in the links.
Of course it’s up to you how you use it, I’d be interested to know how you get on.
November 3rd, 2008 at 8:08 pm
Hi Dave
Nice post, im currently looking at a wiki to hold all info about our work websites from holding the high level change log, keep track of bugs, holding info about error codes and our customer support using it as an internal help area.
Did you come across any good .net wikis as it would be easier if i can just whack it on an existing server in the building, we too are all Microsoft servers.
Thanks
Stu
November 4th, 2008 at 8:07 am
Hi Stu,
We tried out ScrewTurn and LiteWiki, after investigating a few more but found problems with most. They were ok, but nothing could quite match the reliability, feature set and 3rd party plugins of MediaWiki. As we were already running PHP, MySQL and ISAPI ReWrite, it was no issue for us to run it on our Microsoft Servers.
If you do find something, let me know. If you can get MediaWiki running, you won’t regret it
Dave