Stay updated
Keep current with the latest trends in technical communication by subscribing to the I'd Rather Be Writing newsletter. 6,100+ subscribers. (See email archive here.)

Search results

Wikis and crowdsourcing (Trends to follow or forget)

Trends to follow or forget

by Tom Johnson on Feb 24, 2022 •
categories: technical-writing

This post is part of a series that explores tech comm trends that I've either followed or forgotten, and why. The overall goal is to better understand the reasons that drive trend adoption or abandonment in my personal career. This post focuses on wikis and crowdsourcing.

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.

Sponsored content

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.

Buy me a coffeeBuy me a coffee
Stay current with the latest in tech comm
Keep current with the latest trends in technical communication by subscribing to the I'd Rather Be Writing newsletter. 6,100+ subscribers. (See email archive here.)

follow us in feedly

About Tom Johnson

Tom Johnson

I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.

Comments