I am a content stacker at Rackspace, here’s where I think we’re going
there are challenges to using these tools – social media amplifies errors and heightens drama in communities while also enabling more voices and sites.AmplificationDramaToo many channelsToo much datamap represents the number of unique authors in each Usenet newsgroup who appeared in the current year, 2003.
Making it work anyway.Use sprints, strategic stacks with analytics, licensing that enables tinkering, and purposeful collaboration to tune your open docs strategy. I’m going to walk through three areas: Community, Sprints, and Stacks of Data.
We have a schism – DocBook and RST. I have so far divided by audience since DocBook deliverables are more advanced, PDF output and comments enabled.
Translation has not yet been activated. I have only seen a Korean wiki pop up. I don’t know if tooling is the problem or if people just write in English to get the attention of the wide audience.
One hard tack and four softies.Despite writing the process up in detail, so far devs write RST, no one really writes DocBook yet.
First call was to Belinda Lopez, her advice was – work out challenges with licensing. But they had already decided on Apache. I challenged the use of Apache for content, it’s just hard to interpret, CC is much easier to explain. Still working with lawyers for wording.
I challenged the use of Apache for content, it’s just hard to interpret, CC is much easier to explain. Still working with lawyers for wording.Now moving towards licensing for training materials – slide decks, check. But what about lab setup, video, workshops, and exams? Learning how to license those.
By combining CC and Apache I can now welcome blogger’s material
Publishers want OpenStack content. I feel like I’m in a fight to be an acquisitions editor some days. Everyone wants an OpenStack book, or blog entries about OpenStack to publishion their site. I was surprised at this.
Originally had doc sprint during design summit, moved it to earlier dateExpectation – to hold these regularly, reality, releases dictated when to hold themTiming has changed again to six month releases with milestone releases in between. Doc sprints need a rethink.
Eric Holscher – read the docs - said at Pycon, Devs need to write for other devs – strongly believe what ReadTheDocs.org guy preaches now. This is a 180 degree turn for me.
Barrier to entry is quite high with BZR and Launchpad. Yes I can walk through Windows contributors but they give up early. We are moving to git for code storage – how will that affect doc contributions? Doc contributors need access to people they can interview incessantly. Plus they need access to hardware, big time. Neither are easy to offer now.
We have people who desperately want to be involved with OpenStack – get led to docs, but have no idea how to write or make images or…When you want something done, ask a busy person. Unless the busy person just answers email all day.
Comments are going great, now users answer each other. I did a content audit, does a community audit also make sense? We are seeing some dilution though with too many sites such as a new forums site and Launchpad Answers also vying for attention.
Also thinking about a tweet chat – gets out of the IRC mold which might work well for a good portion of our users
Curated search engine plus search analyticsWorking on loyalty, bounce rateProof of the PDF popularity
We came out of the gate with way too many topics out there. We quickly learned that with too many topics and not enough interaction to start, it made the community seem empty. It’s what I call ‘empty restaurant syndrome’ — if you look in a window and no one is in there, you likely won’t go in.– Mike HardyStrategic communications program managerPitney-Bowes
Next – Launch and Learn
I plan to keep iterating, keep prioritizing, keep having fun, and keep learning. Join me!
1. Sprints and Stacks<br />Building a Documentation Community<br />Anne Gentle<br />firstname.lastname@example.org<br />Open Help Conference <br />June 2011<br />
2. We are tinkerers<br />Flickr: loozrboy<br />
3. We are techies<br />Flickr: laurenkeith<br />
4. We are Helpers<br />Not always technical writers, but wanting to make an impact<br />Flickr: gi<br />
5. I believe in community<br />Flickr: ThisParticularGreg<br />
6. I am… a Content Stacker<br />OpenStack – Open Source Cloud Computing<br />Rackspace – Fanatical Support in all we do<br />
7. Welcome to Now<br />Our Challenge: Never before have we had tools for collaboration, instant communication, project tracking, and data gathering. <br />How do we harness the power of community for documentation?<br />
8. Meeting the Challenges<br />Flickr: marc_smith<br />
9. Community Documentation<br />
10. Community – Lessons Learned<br />Expectations and reality for:<br />Source files<br />Licensing<br />Community Motivations<br />
19. Timing is the Thing<br />Three month release cycles<br />Design Summit in-person meeting<br />Now six month release cycles with milestone releases<br />Flickr: plenty<br />
20. Contributors and Newbies<br />Flickr: kholkute<br />
21. Barriers to Entry<br />Flickr: AdamKR<br />
22. Attraction to Sprints<br />Flickr: ratranch<br />
23. Data Stacks<br />Social web integration<br />Web analytics<br />
24. Comments<br />
25. Twitter Responses<br />
26. Planet Blog<br />
27. Web Analytics<br />
28. Measure the Help<br />Customer support and help sites <br />New vs. returning visitors<br />Searches that had zero yield<br />Search results to site exits ratio<br />Download completion rates (if relevant)<br />Flickr: HeavyWeightGeek<br />
29. Engagement Indicators<br />Number of comments on content<br />Number of comments responded to<br />Response time on the comments<br />Number of edits<br />Volume on discussion boards<br />Flickr: atomicjeep<br />
30. Pitfalls<br />Too much content, not enough engagement.<br />Another community could take all the major players attention.<br />Dilution and repetition.<br />High barriers to entry. <br />Flickr: docpop<br />
31. Resolutions<br />Write DocBook collaboratively for web developers and system administrators (devops, also)<br />Coach developers to write RST for devs<br />
32. Resolutions<br />Automate reference documentation<br />Encourage conversation<br />Build a community around docs and with docs<br />Iterate repeatedly<br />