As more and more wikis are deployed to share business content, especially technical documentation, an idea that has been gaining in popularity is the concept of “round-tripping.” In her book, Conversation and Community[Gentle09], Anne Gentle defines round-tripping as “the conversion from source to wiki and back.” This generally means taking your source content, converting it to a wiki output, collecting the changes made on the wiki, and incorporating them back into the source files before starting another round of editing and publishing.
Most companies that have documentation wikis already do this as a manual process. When I hear people using the phrase “round-tripping” they tend to be talking in terms of automating the process. When I have asked people what the business case is for implementing automated round-tripping, very few have an answer beyond “well it would be cool.”
One notable exception where automated round-tripping may be of benefit is with a multilingual wiki. For instance, I recently heard about a wiki with a community base of 90,000 users that had copies of the base English wiki in twenty-two other languages. To ensure a true global reach, the community had no requirement that members speak English to have access to the wiki. In this instance, round-tripping would have to be coordinated with language translation memory systems to ensure a simultaneous update. A daunting task, but one that would have a measurable impact.
If you think that you need round-tripping between your wiki and your source documents, think carefully about what you really need. Consider if there are any consequences to altering the source material. There may be legal and liability issues related to such changes. Going back to my days in aerospace documentation; in the unfortunate instance of an aircraft accident, all the work on the documentation was frozen, and we had to be able to reproduce the exact version of the documentation that was used the last time that particular aircraft was serviced. If you had automatic round-tripping of user-generated content into the source content, satisfying such a request would require your wiki management and control systems to be synchronized with your document management and content version control systems.
It might seem that the best way to approach round-tripping is to develop a scripted, automated system to incorporate feedback and changes into the source content. However, this approach is also fraught with potentially harmful consequences. Without checks and balances you may overwrite sensitive information and potentially cause liability, safety, and warranty issues.
If the end result of round-tripping is important to you, and you do not want to go through the manual process of incorporating feedback and wiki changes into the source documentation, you might consider using the wiki itself as the new source for any changes after the initial publication cycle. That is, use the wiki as your authoring environment.
If you cannot use the wiki as an authoring environment – perhaps because you need to leverage the efficiencies, knowledge, and investment in existing authoring tools, or you need to create high-quality output alongside the wiki from a single content source – then round-tripping may be an essential part of your process.
In such instances, you need to make sure that your process still includes what I term the “human element.” No matter how much you manage to automate, you still need to include a person in the process who can ensure that all content coming from the wiki is appropriate, has been reviewed, and (if necessary) approved. This person also needs to ensure that the new content is correctly attributed and does not overwrite sensitive information.