Slightly Off KIlter

As I mentioned a few months ago, the Company I work for has been giving serious consideration to moving the Development section of the Intranet onto TWiki. However, when I spoke to one of the engineering managers last week, I learned that he is considerably less ecstatic now about using the Wiki for all of our Project tracking and documentation. I find myself in agreement with that; I’ve never been much in support of migrating alll of our web use to the Wiki.

However, I personally still see the Wiki as a potentiallty valuable tool. I believe we should continue to keep Wiki available (and improve upon it) as part of the Corporate Intranet.

Instead of saying

Let’s convert all of our project development workflow over to using Wiki.

What can Wiki do for the Company? What are the strengths and weaknesses of Wiki? What should we migrate and what should we leave as is?

Wiki should complement what we have, link into pages that already exist, and give us the ability to move forward using all of our tools as they work best.

First, let’s take a look at some things that Wiki isn’t well suited for (at least not at the Company where I work, in my opinion).

Bug reports

Bugzilla is specifically designed and optimized for bug reports.

Code repository

CVS (or something similar) is far superior for this.

Offline viewing and editing

Wiki needs a full distribution behind it. Unlike simple HTML pages, Wiki sites are not easy to download and view offline.

Scheduling & Communication

There are applications specifically designed to handle scheduling, calendaring, to-do lists, etc. Many of these are far better than Wiki. For example, over the holidays we tried to set up a vacation calendar in the Wiki. I contend that a public Outlook Web calendar (yes, I said Outlook) would have been much more usable (and would have seen more use as well).

Project Document repository

There is a lot of disagreement over whether Wiki is suitable as a code or document repository. While Wiki can be used for design specs (one of our teams has done this), many of the Company engineers prefer documents under “pure” CVS and I have to agree. I do not believe that engineering should be storing all project documentation under Wiki.

Dynamic information

I am not convinced that Wiki is a good place to put dynamic information such as project status updates and schedules. Wikis are optimized for easy, fast, static page creation with simple formatting. Wiki is not so good at handling pages that need to be changed often (either manually or in an automated fashion), pages that need to be edited by many people, or pages that need to convey a lot of information. For these, you should probably use “real” HTML, PHP, MS Excel, or other, more suitable, tools.

Page “sets”

Wiki is great for creating one page at a time but poor for uploading sets or hierarchies of pages. Wiki is, in many ways, meant to be an interactive, not a batch, web page creation environment.

Scripts

Wiki does not support PHP. We have PHP scripts in use in-house now.

Now that I have claimed, essentially, that Wiki isn’t particularly well suited for exactly what many people hoped to use it for, i.e. tracking project status and documentation, let’s consider what Wiki is good for and why I think we should continue to keep it in general use at the Company.

Wiki can enhance the quality and quantity of all available information by improving the ability of many people to collaborate on documenting and sharing what they know. Wiki “lowers the bar” to web page creation, providing nearly anyone the ability to create a document and publish it to the web. This ability is critical to the longterm growth of our company knowledge base.

As a (non-Wiki) example, prior to July, 2004, all of the Company development engineering pages were stored statically in the filesystem on the internal webserver. Only a small handful of people had server write access. The web pages were rarely updated and new material was added infrequently.

In July, one of those people with server access created a new CVS module and checked all of the existing content into the CVS tree. The engineering team now had easy web publishing capability simply by editing a file and checking it into CVS. Within a very short time, we had doubled the number of how-tos and other docs, simply because they were trivial to create. Of course, many of the pages were text-only (not html). These were engineers after all (the shortest distance between two points …).

Nevertheless, the quantity and quality of our internal documentation improved drammatically when more people had access to the web. Consider how much information we might add if the entire company has the opportunity to add what they know to the knowledge corpus. And, with Wiki, they can still write in plain old text, yet the results will be formatted and consistently styled.

The results could be impressive.

Wiki is well suited for use by individuals and small teams.
I’d like to see us using the TWiki throughout the Company for “personal” home pages, team/group pages, and small project pages (e.g. pages for features). I’d love to see Wiki use increase for the non-engineering Company areas, such as HR, Training, Finance, etc.

A Wiki could be superb for handling:

• topics with a relatively small and/or tightly defined audience
  
• topics with a relatively small and/or tightly defined scope
  
• short topics with broad appeal that don’t change often (e.g. how-tos)
  
• pages that need to be created or maintained within a small group of
  domain experts (e.g. HR, Training) for viewing by a wider audience (note that these should be write-locked)
  

Wiki puts information publication in the hands of the people who have the information (and frees the IT team for other tasks). Even so, we should nevertheless make every effort to “batten down the hatches”. We should be sure to implement as much security and tracking as is available for WIki. While the ability for anyone to add content is valuable, we still need to protect that content from accidental erasure or undesirable modification.