Session at Community Leadership Summit on Saturday, July 18, 2015 at 3:30 PM in Session 2
One company needed to provide more documentation because company wasn't communicating news to customers and they were forced to ask customer support. Distinguished between its knowledge base (trendig news, bugs and workarounds, etc.) whereas paid writers could focus on official documentation--user guides. Took weeks to decide where to put items. But then a staffer could work with the community to find out what they needed and find ways to generate it. Rigid publication schedule of official documentation didn't fit well with fast-breaking news in knowledge base. Now involve support team and put up most frequently asked questions the support team gets. When members of the community answer questions on a forum, the support team can take that for the knowledge base.
Some communities contribute code and use cases. The community manager puts it in the template, perhaps retests answers, and publishes it. In one case, actually helped the community manager exceed his yearly goal for producing articles. If they want it, contributors are acknowledged.
If someone seems knowledgeable, you should ask them to do more.
Another company has produced two books, publishes them as PDFs or ePub, and gets contributions from community to update books. A hundred contributors on some projects, but need more.
Customer can point out that something is out of date. Then a support person writes up a change ticket.
One big project has open documentation that thousands of people edit. Encourages more contributions, but has some negative consequences: there is no canonical documentation set. A user may decide that the software works differently from what the developers said, and totally change the documentation. Also, a very fast-moving project can make it hard for documentation to keep up. Can't document something that may change.
Storing documentation in a public source control repository (GitHub, in this case) raises contributions because it's so easy to check out documentation and correct it.
Bounty system: give a small sum for fixing persistent bugs, or for writing a guide. Have to check quality of contributions.
One project puts documentation through a review process similar to code: each contribution is vetted by two other people for style, tone, accuracy, etc. Raises quality of documentation but also raises the bar, making it harder for a new contributor to get documentation accepted.
Curating community input also takes a lot of time.
Set aside time to take material from an internal mailing list and turn it into external documentation.
Extract useful material from forums and put it into a more structured place where people can find it. Or ask the contributor to write up the answer in a more formal way.
Organize documentation tasks into small pieces so that potential contributors can fit a task into their schedules.
Ask experienced contributors to refrain from fixing simple things, so that new contributors have something to start with.