Wikis and crowdsourcing
- What are wikis and crowdsourcing?
- Why I embraced wikis and crowdsourcing
- Why I abandoned wikis and crowdsourcing
- Current status of wikis and crowdsourcing
- Takeaway
- Next post
What are wikis and crowdsourcing?
Wikis allow for larger numbers of people to contribute and edit content. Open-source wikis like MediaWiki (the same platform powering Wikipedia) scale in an impressive way to allow practically anyone to edit and contribute content from a browser. Any reader can usually toggle the webpage into an editor mode, make and update, and click Save.
Wikis support the possibility of crowdsourcing, which is the idea that you no longer need a dedicated team of writers; instead, the content can be contributed by many different people, just like Wikipedia. If 100 people each contribute a few paragraphs here and there, you’ve suddenly created the bulk of your docs without the need for tech writers. Or at the very least, tech writers’ efforts can be magnified and enhanced through contributions and refinements from community members.
Why I embraced wikis and crowdsourcing
As I explained in HATs and single-sourcing, I was working for a company that had a large number of volunteers eager to contribute content. Wikis were the right tool for this scenario, not HATs. Further, because MediaWiki was open source, we didn’t have any licensing issues for each contributor.
Why I abandoned wikis and crowdsourcing
Trying to crowdsource documentation from volunteers didn’t work. I wrote about this extensively here: My Journey To and From Wikis: Why I Adopted Wikis, Why I Veered Away, and a New Model. The most common reason people volunteered was to build up their portfolios and get more tech writing experience (which makes sense), so they needed a lot of handholding and direction. Most of the documentation tasks required access to internal project teams and information. It was hard to connect external volunteers with the needed inside information, especially given corporate access restrictions.
For those volunteers who did contribute content, their contributions were often mediocre, and the volunteers didn’t take into consideration how their added paragraph or article flowed with the rest of the page content or surrounding product context. The reality is that writing technical content is hard and many people falsely assumed that just because someone can write, they can also produce professional-level documentation. It isn’t the case. Crowdsourcing really only works if you have simple tasks that don’t require much expertise or effort.
In the end, I expended a lot of effort trying to wrangle and manage volunteers, without much output or productivity. One day I measured up the time I spent managing and coordinating the volunteers versus the output and how long it would take me to produce the same content, and I decided the crowdsourcing model didn’t really work, so there was little point in continuing to use a wiki.
Current status of wikis and crowdsourcing
Wikis are still going strong in internal contexts, such as for corporate platforms. Confluence is a common internal infrastructure for many companies. It does seem that within the enterprise, you need a scalable, simple solution that allows everyone to create and publish content. But as far as a doc platform for external docs, as well as crowdsourcing models, I don’t see too many examples outside of Confluence. Splunk’s Ponydocs is probably the strongest current example of MediaWiki-based external documentation.
Even when wikis are used for external docs, the docs don’t usually give outsiders the ability to edit the content. To allow for “crowdsourcing,” making the docs available on GitHub and allowing people to submit pull requests is now more common. Even so, the GitHub model of pull requests never worked for me either, but I’ll get to that later.
In hindsight, the failure of crowdsourcing actually ensured the survival of the technical writer’s role. Even within the most celebrated success stories with wikis (Wikipedia), the actual number of active contributors and editors is a tiny fraction of user base.
Takeaway
Wikis are most useful for internal docs in contexts where employees feel that writing documentation is part of their responsibility and job function. When docs aren’t their job, employees tend not to contribute in substantial ways, and volunteer contributors lack access to the resources and information needed to write docs.
Next post
Continue to the next post in this series: Faceted filtering.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.