Some of my projects include community-involved documentation. When you work for a church, it's not hard to find dedicated members willing and committed to sacrificing a few hours for a higher cause. To harness community efforts, I gathered up a large pool of volunteer names and formed a listserv. I communicated project needs with the listserv members and asked for help.
Despite some contributions, the majority of volunteers are hindered by too many obstacles -- access to information, time, standards, and more -- to contribute much. As such, I've begun to change my expectations from content creation to content review and feedback.
The community volunteer, as an outsider, faces difficulties accessing the right people and information. As a volunteer, you may not know the project manager, the quality assurance lead, the developers, and other contacts that have information you need. Without access to the right information sources, documentation efforts are vain.
If you do have contact information, you may be contributing only in your spare time, outside of regular working hours. So you'll be left with email and voicemail exchanges, if you're bold enough to even make contact. If you've ever tried to get information when no one is in the office, you know how frustrating that can be.
Trust also becomes an issue, because many times project information is sensitive or still in deliberation. Project managers may be hesitant to disclose the full facts to an outsider they don't know, whom they've never met or worked with.
Another problem is time. Many volunteers have full-time jobs, families, and little time. The idea with volunteer work is to harness the long tail: if 100 volunteers each contribute two hours in a day, that's more than a month of labor of one full-time employee. The problem is, tasks often cannot be chunked into two hour increments that can be done independent of a specific sequence.
Think about designing and creating a quick reference guide, or configuring an online help. The tasks can't be broken down into two-hour chunks that can be created by different people at different times. Many times tasks are sequential -- they build on one another. You must first gather the information, then organize it, then illustrate it, then lay it out, then review it, then test it, then publish it, and and so on. The whole work may take 200 hours to complete, but each phase builds on the previous one, more or less, so distributing the entire work to the community would require that you spread out the work in phases. This kind of coordination is tough and complicates volunteer efforts.
Another problem with community contributions deals with style and standards. I'm a picky writer, and anything the community produces will be perceived as coming from my group, or me. If a deliverable doesn't match my standards, style, or preference, I'm less inclined to support it. When a volunteer submits what I feel are sub- or non-standard deliverables or content, I face an uncomfortable situation that I'm not sure how to handle tactically -- offend the volunteer by refusing the work, accept the work and lower confidence in my team, or spend time reworking the deliverable to my satisfaction, which may require more work than creating it from scratch.
It's impractical to expect volunteers to be familiar with the intricacies of our department's style, to know my own preferences for formats, etc. I might as well expect a writer from another company to magically match the style and approach of our own.
In working with community, you also have to consider time for volunteer management. Expect to spend about 25 percent of your time communicating, responding, and managing community member questions and tasks. This is somewhat of a risk, because you assume that the results from the community will surpass what you could have done yourself in that 25 percent of time. Management may not be something you can bill towards, especially if you aren't already a manager.
Further, management is complicated by the remote distance. You're managing people you've never met, working with them without any idea of their background, or without understanding their expectations and motivations. You could be managing your neighbor, or someone in an island in the Pacific, or a retired army colonel -- all with little understanding of their background.
Where community efforts have succeeded for me is with reviews and feedback. At times, when I finish a page of documentation and publish it to the wiki, I often send out an announcement to the community listserv asking for their review. Their comments sometimes triple the depth of the original article. Community members pose tough questions, present perspectives I hadn't considered, note situations I hadn't thought about, and generally scrutinize the information available.
Having a sounding board of 65 intelligent people is not something to underestimate. Sometimes I'll just throw an idea out to them to get their thoughts. Other times their non-response tells me information too -- for example, that something is not an issue for people.
Although community members may be reviewing a specific collection of pages, it's rare that they make edits directly. More often they send a response with some suggestions and questions, and prefer that I make the edits. I prefer this method too.
So far I've been speaking generally about my experience with typical community volunteers. But for every 100 volunteers, there are a few who are golden contributors. Their efforts far exceed the efforts of normal volunteers. They go above and beyond the call of duty with a feeling of personal ownership and dedication. I don't exactly know what motivates these super volunteers, but I love them.
Last week we were facing a tough decision about where to publish information to avoid duplication, so I consulted with a super volunteer. His response was thorough and insightful. Not only did he provide a sound reason to help me make a decision, he also pointed out a problem with terminology that I hadn't considered. I ended up reworking and re-organizing the content.
This example reinforces the best benefit I've received from community efforts: feedback and insight. Rather than inviting community volunteers to make direct edits and create raw content (and then get frustrated when they don't participate), I'm now more inclined to invite them to provide feedback and insight, to review and comment. I ask how they would handle a situation. I ask if a specific page I wrote seems clear. I ask if a topic covers all the issues they face with a task.
With an expectation of feedback and review, rather than raw content creation, I've had a lot more success with community efforts. Trends with minimal participation fall away, and the sound of the community voice increases.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.