“The companies that figure out how to harness the power of open platforms while providing adequate incentives to all stakeholders are poised to reap great rewards.” -from Wikinomics
A few months ago, I blogged about this thought-provoking book. Around the same time I began to promote the idea of taking aspects of our product documentation (e.g. development guides) and “wikifying” them. I contend that it’s better to replace the current delivery model (i.e. a PDF drop per release) with a new model that harnesses the power of the web and the energy of the Documentum community. Better for writer (uptake, feedback), better for all cross-functional product team members (accessibility, performance, quality, functionality, architecture, usability), better for the overall community (collaboration, connectedness).
The Django Book is an example application (user experience) of what I’d like very much to see become of the DFS Development Guide content—Wikibooks (e.g. this) is another example.
As you might expect our Technical Publications group leverages XML (DocBook to be more specific) as the underlying markup for its deliverable, which are released in PDF form. This is great news, since XML to wiki markup format transformations are fairly straightforward. By taking the underlying XML content and projecting it into a wiki–for example, off the EMC Developer Network (EDN) web site–rather than a PDF document can open up documents like the DFS Development Guide to our developer/admin/user community. By doing so, I believe that such documents can be revised, extended and planned more effectively. For example:
- I find a gap I can fill. So, I simply create the missing wiki page(s)–I don’t have to wait until the next release of the software or the PDF document.
- I find a gap I don’t know how to fill. So, I add a topic to the wiki’s “wish list” page, and someone else with the ability to author the missing content gains my respect and builds his or her reputation in the DFS community.
- I can share how I took an existing code sample and tweaked or extended it to satisfy a new requirement.
- I can talk about how DFS did or did not work with my existing IT environment–and expect more timely, specific/targeted response in return.
- Etc.
Once the wiki exists, it can (and IMHO should) become the truth of its subject matter. In fact, PDF documents simply become the output of convenience (e.g. Atlassian’s Confluence wiki allows you to quickly rendition any wiki page as a PDF or, via a plugin, an entire wiki space as a single PDF document–links and all). Snapshots are just snapshots, and the current state of information is open for all to access and contribute.
To quote one of my colleagues: “The idea that we can control and perfect the quality of the information internally and shield it from possible inaccuracies introduced by customers is pretty flawed.”
When I talk with developers, partners and customers in the Documentum community to explain the idea of such wikis, the universal response is, to paraphrase, “sure…and yesterday would be great!” To trim it down to a single word: “Duh!”
So, to quote Jerry Maguire, “Help me help you” by posting a comment here, sending an email to the good folks at EDN and/or posting to the EDN forums, or call your main EMC point of contact to make your voice heard and your vote count. Thanks! 
Update 12/27/2007: Thanks to Anne Gentle’s link to my post, I found Wiki Patterns, which offers an open catalog of patterns and anti-patterns concerning people using and adoption of wikis (e.g. a WikiGnome versus a WikiTroll).
-Craighttp://craigrandall.net/
@craigsmusings
OMG, yes, absolutely. I’m so tired of the stale, late documentation. I’m equally tired of the “wiki error” discussion. It’s amazing how many people remember the wikipedia errors article. The funny thing is that wikipedia corrected ALL of those errors in less than a week. Then Wikipedia pointed out a number of errors in Encyclopaedia Britannica and those are ALL still there…
Hi Craig,
This is a good idea.
We have integrated our Docbook publishing process from Subversion into our project website recently.
The idea is that customers can link tickets, wiki pages, comments into the docbook.
This close feedback loop within the documentation is really fantastic as it keeps it alive.
An additional feature can be to merge the comments automatically back into the docbook via XUpdate to facilitate the authoring process.
We have used Ruby Lucene implementation(Ferret) in order to use ‘more like this’ functionality between the content.(tickets, wiki, external websites, docbook).
Back in March a colleague referenced We Are Smarter Than Me (i.e. the site). Looks like the book has been published and may be worth reading: “The book focuses on ways in which companies are learning to leverage social networks and the power of communities to improve their performance by allowing customers or others to take over functions typically performed by experts.”
Another colleague suggested the following lessons from this particular project: “They already had a ghost-written first draft, which also makes it pretty intimidating to jump in and start changing things when they’re already laid out in a nice narrative form. The resulting book will be largely ghost-written with presumably some ancedotes filled in from the participants. Affordances of the wiki/discussion software, size of the chunks to be edited, and there’s probably some others in there too. It’s been a remarkably “faceless” project. I imagine a celebrity guru like Seth Godin could have whipped the acolytes into a frenzy. The usual lessons on bootstraping a new community. Again IMHO too much b-school and McKinsey-ite strategery, and not enough grass-roots movement.”
What is your experience with wikis?
Do you see “the need for a strong editor who ensures that the necessary information is provided, guides the community to flesh out areas that need attention, culls obsolete material, guides the architecture by creating page and object templates, and evangelizes the use of the wiki?” If you work with open source, do you see the typical lead-committer-contributor-lurker model as applicable to wikis (i.e. applies equally well to code or documentation)? What models and roles are successful in the wikis you find most compelling?
I couldn’t agree more, putting the documentation online and allowing user comments would be a phenomenal customer advantage.
One site that I think does this well is the MySQL documentation, where the user comments are often more valuable than the documentation itself…giving you all the gotchas and resolutions when the process in the docs goes wrong.
http://dev.mysql.com/doc/refman/5.0/en/upgrading-to-arch.html
It would be nice to attach a minimal amount of metadata to each comment for filtering…for example, you may want to have a score for comments so that the community could “+1″ those that were relevant/important. Also, attaching a release tag to a comment could allow a filter for “comments only relevant to 5.3″. So I guess an aggregate score based on age, release version, and user points could assist in keeping the most relevant comments at the top.
With this type of scoring, it becomes less necessary to have a formal Administrator screen every comment. The community provides the fitness score.
[...] intriguing snippet of information in a comment from xaop on a blog post by Craig (2nd comment in the list) mentions integrating their Docbook publishing process from Subversion [...]
In her post that links to mine above, technical writer Sarah Maddox observes that wikis are not document management systems and are better suited to knowledge management. I agree that wikis are focused on low (or even zero) barrier to collaborative authoring. I also believe that there is a difference between the user experience of a wiki and the underlying implementation.
As someone in the information lifecycle profession, “wikis ‘R’ content.” Wikis can (should?) be backed by a backend that can distinguish when collaborative authoring is purely free-form, when it becomes actionable, and when it becomes part of deeper, broader business processes. That is, a wiki (i.e. its presentation and interaction) can be married to a platform such as EMC Documentum so that all information produced and consumed in an enterprise of any size can be archived, transformed, distributed, protected and versioned, regardless of its point of origin or consumption.
I’d like to know what Sarah and her professional community sees in terms such integration’s benefits, opportunities, priorities and challenges. There is a significant technical publications team I work with that would love to participate in this discussion, too.
[...] a wiki can fulfill a customer need. I got a small chuckle out of the title of this blog entry – Wikify Documentum Already – but he’s talking precisely about the gains you and your customers make when documentation [...]
Mmm… Lifecycle management… wait, Homer Simpson probably never said that.
But seriously, Craig, nice post. Great to see/hear/read cogent thoughts on “new media” (wikis) meeting “old media” (e-docs), and not losing sight of enterprise concerns, and from within the bowels of a big “old media” solution provider.
For anyone interested in lending a hand (and brain), we just launched our Enterprise 2.0 survey, and can always use more responses. It covers a wide swath of landscape, at 67 questions, and will take you somewhere around 20-30 minutes to complete (you can save your place and come back in a 2nd pass if you like), but we believe we’re going to uncover some fresh thinking and data with this.
Take a peek at the survey at http://aiimMarketIntelligence.questionpro.com. (let’s see what markup you’ve got running here Craig – copy and paste the URL as necessary, should it not survive the journey)
Survey respondents get an early peak at the findings, and anyone is eligible for the full writeup, gratis, due out mid/end March. So either way, keep an eye out, if you’re interested in things wiki or in the broader Enterprise 2.0 realm.
[...] RSS ← Wikify Documentum already [...]
[...] still working on this, but at least this content is available via [...]