Let me make one clarification. Wikis likely work very well for administrators or technical users of a product to share and correct information. Wikis are not a suitable medium for IBM knowledge management, development, or support to create product documentation. Alterntives such as Wikis only help to poach knowledge from conventional sources such as IBM Info Centers or IBM technotes.
Here are my concerns:
- Lack of authority - It's true that the advantage of a Wiki is that anyone can compose a document. But when dealing with product literature of an enterprise server or set of steps to apply fixes, will just anyone do?
- Placeholders - Some Wikis contains the makings of a Redbook. The problem is it's not yet complete. The Wiki is then inundated with "coming soon" pages. This confounds legitimate search results and superficially gives the appearance of new content.
- Flat Navigation - Granted there are tags, but when you get down to it, you're going to be looking at a list of pages. Some Wikis have API documentation. The API documentation consequently lacks the hierarchy and navigational structure of a more traditional format such as javadoc.
- Stale Content - Information within process driven repositories are subject to review and retirement through the lifecycle of a product. Will the same content within a Wiki be subject to the same timely review and revision?
So what's the answer? I believe IBM stays the course with Information Centers (IC) and Technotes. ICs provide pre-GA compiled documentation on how to install, configure, and use products. Post-GA needs to accomodate changes to ICs where appropriate: content is inadequate, confusing, or missing altoghther. Technotes serve the purpose of sending critical updates in the form of flashes. Technotes should also document specific instances of product customization or configuration.
I want to also propose a "new" mechanism for problem determination. Most engineers would create a technote documenting a particular error message and corresponding resolution. For such specific cases where log file entries directly correspond to IBM recommendations, we need to seek autonomic solutions. Case in point is Log and Trace Anaylzer for WebSphere. Rather than an administrator encountering an error in a log file, searching IBM resources, and applying suggested resolution, the autonomic solution should identify and suggest (or even apply) the recommended solution without admimistrator involvement. And this is what I'm working on as the project du jour: converting Lotus Quickr for Portal's APARs, PMRs, and technotes into a database of symptoms and recommedations. The desire is an automated method of problem determination and solution. This is good for not only the IBM support goose, but the client gander.