TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Wiki as a documentation delivery system? (take II)
Subject:Wiki as a documentation delivery system? (take II) From:Geoff Hart <ghart -at- videotron -dot- ca> To:TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 01 Aug 2006 11:33:25 -0400
Responding to my suggestion of the need for strong access and
modification control, Matt Horn noted: <<If you make it difficult to
add or collaborate, then it isn't a wiki. I would guess there's an
inverse relationship between the difficulty of adding content and the
amount of content added.>>
This is true, but you're forgetting the context of the original
message: this is not a tool for collaboration within a company, but
rather a way to obtain input from users of the company's products.
That's a great idea in terms of creating a dialogue with your product's
users and producing documentation that meets their needs. It also lets
you add content you wouldn't have thought to create on your own. So
far, so good.
However, if you let any joker modify the content, then you get the same
problem you get with Wikipedia: people with an agenda or who don't
really know what they're talking about can modify the content. If they
do a bad enough job, your company's reputation will suffer, and if
someone gets hurt or suffers financial or other damage as a result of
following bad advice, your company will be legally liable because the
wiki ostensibly represents your company's advice.
Unlike the Wikipedia, you can bet that people won't be accessing the
wiki regularly (nobody reads docs for pleasure), and that means errors
may endure for quite a long time before someone catches them. That's
particularly true if the errors are subtle, which many of them will be.
And if you think it's hard to get technical reviewers to do their
reviews with documentation that you control and that they only have to
review once (see the current thread on this topic), do you imagine
they'll be happy to add a daily check of the wiki to their list of
responsibilities? Not bloody likely.
So to reiterate: The concept is a good one, but there are some
significant pitfalls you have to overcome if you want to keep the wiki
quality high and protect your employer.