And it is just plain DAMN JARRING, trying to read an article on more than one person, when the terms are different. When they aren’t. As in:
• XXX is “spouse”
• XXX is “domestic partner”
• XXX isn’t even FREAKIN’ MARRIED to the person they have been linked with.

Drives me crazy. And I can do that by myself.

But I seriously don’t believe that I should have the burden-of-proof in correcting factual errors (not opinions). I don’t have the time to jump through the hoops to correct information that is a matter of public record. And I don’t care how earnest they may/may not be in wanting to correct entries, I don’t care. I go by your actions and not your words.

Any of you have serious reservations about Wiki, feel free to contact me.

Yes, versioning between software releases sucks. We struggle with the same problem, and tackle it mostly by avoidance. That is, we avoid starting on the next version’s documentation until the previous has (all but) stabilised. Then we duplicate the previous version to create a new Space for the next version, and new work happens in the copy.

Still, naturally there are times when we need to update both, and this needs to be done manually. This is why I would love to see a wiki with *real* version control in the backend, that would allow branching and merging. It is really quite sad to see all the wikis that have created their own, limited version control systems. Versioning is not easy, but there is enough work out in this domain that I expect a lot better from the top wikis. I notice with interest that the Google Code wiki actually *does* use Subversion in the back end, which is a first that I know of (though it seems so obvious that I bet there are more).

Currently, wikis do not distinguish in this matter… as perhaps you have said, wikis aren’t meant for the purpose of documentation. I wish it was just as easy to migrate to a more sophisticated option.

My colleagues are world-wide, and it is the most efficient and effective means to collaborate (read, No File Sharing; no track-changes, no waiting), while letting our users have access as soon as we ’save’. I read your blog on methodology for documentation in wikis, but the Comment is closed. Any thoughts or tips would be greatly appreciated.

A good ‘living document’ Wiki requires a good taxonomy, and a taxonomy requires a maintainer….

However, I disagree with some of your complaints and suggested approaches for dealing with them. For example (and as other posters have pointed out) use a version control system for version control. (sk’s approach to this is admittedly minimal here). And I don’t think rich-text editing will help styling issues.

I also agree with the poster who said that for it to maintain reaonable organization and coherence the wiki needs continual maintenance.

I think many commenters here are right to say that it really depends on the people. There are some fantastically well-organized and readable wikis built on totally awful software, and vice versa. They really form a blank slate.

But yes, as a document management tool they haven’t grown into the features that most CMS/DM tools have had for years now. They’ll get there, it just takes a long time to do.

I didn’t understand your point about styles. All the wiki software I’ve worked with had stylesheets and forced semantic markup. If you wanted to inline FONT tags you could, but it wasn’t rendered by the wiki itself. It seems to follow the XHTML/CSS model exactly. How do wikis abandon the stylesheets idea and go back to manual formatting?