Downloaded 13 times
![Coordinating Documentation and Support: Turning Complaints into Contributions Jennifer Zickerman, Mozilla Thunderbird [email_address] jenzed (IRC and Twitter)](https://image.slidesharecdn.com/openhelptalk-110604114809-phpapp01/75/Coordinating-Documentation-and-Support-Turning-Complaints-into-Contributions-1-2048.jpg)
More Related Content
Similar to Coordinating Documentation and Support: Turning Complaints into Contributions
Coordinating Documentation and Support: Turning Complaints into Contributions
- 1. Coordinating Documentation andSupport: Turning Complaints into Contributions Jennifer Zickerman, Mozilla Thunderbird [email_address] jenzed (IRC and Twitter)
- 2. Open Source TeamsOpen source projects coordinate teams that focus on various tasks: Development
- 3.
- 4.
- 5. Documentation (for users,for developers)
- 6.
- 7. Open Source ContributorsVarious types of contributors: “ Core”: employees, maintainers, benevolent dictators, fairy godmothers...
- 8.
- 9.
- 10. Open Source CommunitiesTeams / contributors The source of success, growth, vitality and longevity of every open source project
- 11. It's Complicated Differentmotivations among different teams: Development versus support
- 12. Quality assurance versusdevelopment
- 13.
- 14. It's Even MoreComplicated Different motivations among contributors: It's a job
- 15. Professional advancement /development
- 16.
- 17.
- 18. Silos Each ofthe teams (and sometimes the contributors) may operate in separate information silos via dsearles on flickr Image thx to dsearls on Flickr
- 19. User Support andUser Docs Two teams / two silos
- 20. Similar audiences andcontributor profile
- 21. Manage processes, platformsand people to make them interconnect
- 22. The User Thelargest community – the user community - is an abstraction: Too big to grapple with or ...
- 23. Too specific intheir needs to understand
- 24. A cost, notan opportunity
- 25. Users are MetaCore and contributors talk to each other, not users. Instead: Traffic analysis
- 26. Meta-analysis of supportquestions
- 27.
- 28. How our cousinfeels about things
- 29. User Overload Thunderbird:Employees:10
- 30. User Overload Thunderbird:Employees:10
- 31.
- 32. User Overload Thunderbird:Employees:10
- 33.
- 34.
- 35. User Potential Toomany to engage individually, but: Largest potential contributor source
- 36. Potential for supportand documentation contributors, evangelism
- 37. “ Army ofAwesome”
- 38. Support Individualizes UsersPotential for personal engagement, but doesn't scale: Thunderbird: one support person, over 1000 new topics per week
- 39. Manage expectations: “CommunitySupport”
- 40.
- 41. Building Community Peoplecome for support, may stay around to help others: If they have a good experience
- 42. Learn about the“open” in open source (contribution)
- 43.
- 44. Principles of OpenSource Educating users that: Users are part of the community
- 45. Open source isparticipatory
- 46. High-level technical skillsnot required
- 47.
- 48. Everyone can makea contribution
- 49. Building a SupportCommunity Engage users in helping others: Monitor support queue for resolved issues
- 50. Encourage users whoseissues were solved to pass it along and help someone else Cleaning up duplicates is a good starter project
- 51. Problems with SupportSilo Support silo not suitable for reference material: Noise – too many issues
- 52. Convoluted discussions, hardto find the upshot
- 53. User support notseen as authoritative
- 54. Platform not optimizedfor information management
- 55. From Support toDoc Silo Documentation silo: Curated
- 56.
- 57.
- 58.
- 59.
- 60. Docs not glamorous- behind the scenes
- 61. Everyone hates docs Ignorance is a badge of honor
- 62.
- 63. Overlapping Communities Docsand support have naturally overlapping communities: Targeted at users
- 64.
- 65. Content is relatedand reusable
- 66. Support contributors areintimidated regarding contributing to documentation
- 67. Benefits of ReuseDocumentation reduces the support queue
- 68. Interlinking support issuesand documentation articles improves search results
- 69. Both can bringpeople into an open source project
- 70. Engage people whodo not generally consider themselves potential contributors
- 71. What's in itfor the users? Motivations: Distinguish self as domain expert
- 72. Professional development /experience
- 73.
- 74.
- 75.
- 76. Part of acool project
- 77.
- 78. Thunderbird's Project Turningcomplaints into contributions: Project is underway but no success metrics yet
- 79. Standard disclaimers, YMMV,not shown actual size, etc
- 80. The Support PlatformThunderbird uses the Get Satisfaction web application: Threaded question / answer queue
- 81.
- 82.
- 83. Easy to use- self-managing
- 84.
- 85. The Documentation PlatformThunderbird uses a home-rolled wiki: Easy to author
- 86. Low barrier toentry
- 87.
- 88. Tags, types ofarticles
- 89.
- 90.
- 91.
- 92. Support Processes Lightweight: Monitor answered questions
- 93. Ask thread contributorsto create documentation
- 94. Tag / issuetracking
- 95.
- 96. Documentation Processes Lightweight Track / edit changes
- 97. Article requests /status
- 98.
- 99. List of neededarticles
- 100. Managing Fear Mitigatefear: No “canon”
- 101.
- 102. Personal contact; easyaccess to community and moderators
- 103. Corrections are constructivenot critical
- 104. Contributor Satisfaction Providea positive experience: No literary critics / no trolls / no grammar nazis Better to lose one knowledgeable but nasty editor than ten enthusiastic contributors Moderate community discussions to keep it positive and constructive
- 105.
- 106.
- 107. Conclusion Open sourcecommunity: Human values
- 108. Contributors rather thanconsumers