Blowing the dust off

First of all, I’d like to thank Tom Johnson for inspiring me to continue writing my blog. Albeit an intimidating prospect, being called out on Tom’s blog and everything, I think it is important to share kowledge within our industry. Second of all, I need to clarify Tom’s statement. It’s not that I know a lot about dokuwiki. My team started using dokuwiki about a year ago and have some practical experience using it.

In May 2006, a writer on my team proposed that we implement a wiki to document our team’s processes and standards. Based on his proposal and the climate of the technical writing industry changing towards collaboration and community via wikis and blogging, I gave him reponsibility for the project. He diligently researched our options and with a zero budget for the project, decided that dokuwiki would best suit our needs.  After some initial headache with the install and setting up some limited securities, we had a working wiki.

Aside from the install process, one of the biggest problems that we had was that we soon hit our limit on our technical aptitude for making dokuwiki do what we needed it to do. We were not able to set user rights like we wanted so essentially, our wiki was open to all who accessed it. In addition, updating the style sheet was proving problematic for our team. Eventually, the troubleshooting and configuration problems became too time consuming with little return, we decided to re-examine the open-source tool we used.

The next wiki tool we chose was pmwiki. From the start, the install and conversion of our .txt files from dokuwiki were less frustrating than it was starting with dokuwiki from scratch. We again ran into problems with user rights, but after consulting with a developer for 30 minutes, we were able to implement the security we had wanted to implement with dokuwiki. From a manager’s perspective, our pmwiki implementation provides more options for viewing page histories and changes, as well as a more robust site tracking tool. From a line level worker’s perspective, I find that pmwiki provides more ease-of-use than our dokuwiki implementation did. The markups are similar, but I find that pmwiki is more intuitive for my work habits.

Now, please don’t confuse this post as disrespecting dokuwiki. For our team, at the time, it was too much for us to deal with without letting it consume too much of our resources.  As a post script, after moving to pmwiki, we revisited dokuwiki and they had released an updated version. The installation is much more streamlined, as demonstrated by Tom’s post, and we have implemented the latest version within our environment and are using it to produce the style guide for our team.

I’m interested to hear how other documentation teams are implementing wikis and the struggles and successes that they are realizing. Are there requirements for team members to contribute to the team wiki or is it more of a dependence on each writer’s sense of responsibility to grow the project?