Coordinating Documentation and Support: Turning Complaints into Contributions

1,736 views
1,694 views

Published on

This talk describes a process to extend and integrate support and documentation contributor communities

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,736
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Coordinating Documentation and Support: Turning Complaints into Contributions

  1. 1. Coordinating Documentation and Support: Turning Complaints into Contributions Jennifer Zickerman, Mozilla Thunderbird [email_address] jenzed (IRC and Twitter)
  2. 2. Open Source Teams Open source projects coordinate teams that focus on various tasks: <ul><ul><ul><li>Development
  3. 3. Quality assurance
  4. 4. Support
  5. 5. Documentation (for users, for developers)
  6. 6. etc </li></ul></ul></ul>
  7. 7. Open Source Contributors Various types of contributors: <ul><ul><ul><ul><li>“ Core”: employees, maintainers, benevolent dictators, fairy godmothers...
  8. 8. Contributors: volunteers
  9. 9. Users </li></ul></ul></ul></ul>
  10. 10. Open Source Communities <ul>Teams / contributors The source of success, growth, vitality and longevity of every open source project </ul>
  11. 11. It's Complicated <ul>Different motivations among different teams: <ul><ul><ul><ul><li>Development versus support
  12. 12. Quality assurance versus development
  13. 13. etc </li></ul></ul></ul></ul></ul>
  14. 14. It's Even More Complicated <ul>Different motivations among contributors: <ul><ul><ul><li>It's a job
  15. 15. Professional advancement / development
  16. 16. Community membership
  17. 17. Recognition </li></ul></ul></ul></ul>
  18. 18. Silos <ul>Each of the teams (and sometimes the contributors) may operate in separate information silos </ul>via dsearles on flickr Image thx to dsearls on Flickr
  19. 19. User Support and User Docs <ul><li>Two teams / two silos
  20. 20. Similar audiences and contributor profile
  21. 21. Manage processes, platforms and people to make them interconnect </li></ul>
  22. 22. The User <ul>The largest community – the user community - is an abstraction: <ul><ul><ul><li>Too big to grapple with or ...
  23. 23. Too specific in their needs to understand
  24. 24. A cost, not an opportunity </li></ul></ul></ul></ul>
  25. 25. Users are Meta <ul>Core and contributors talk to each other, not users. Instead: <ul><ul><ul><ul><li>Traffic analysis
  26. 26. Meta-analysis of support questions
  27. 27. Usability studies
  28. 28. How our cousin feels about things </li></ul></ul></ul></ul></ul>
  29. 29. User Overload <ul>Thunderbird: <ul><ul><ul><li>Employees:10 </li></ul></ul></ul></ul>
  30. 30. User Overload <ul>Thunderbird: <ul><ul><ul><li>Employees:10
  31. 31. Contributors: 50 </li></ul></ul></ul></ul>
  32. 32. User Overload <ul>Thunderbird: <ul><ul><ul><li>Employees:10
  33. 33. Contributors: 50
  34. 34. Users: 10,000,000 </li></ul></ul></ul></ul>
  35. 35. User Potential <ul>Too many to engage individually, but: <ul><ul><ul><li>Largest potential contributor source
  36. 36. Potential for support and documentation contributors, evangelism
  37. 37. “ Army of Awesome” </li></ul></ul></ul></ul>
  38. 38. Support Individualizes Users <ul>Potential for personal engagement, but doesn't scale: <ul><ul><ul><li>Thunderbird: one support person, over 1000 new topics per week
  39. 39. Manage expectations: “Community Support”
  40. 40. Encourage peer support </li></ul></ul></ul></ul>
  41. 41. Building Community <ul>People come for support, may stay around to help others: <ul><ul><ul><li>If they have a good experience
  42. 42. Learn about the “open” in open source (contribution)
  43. 43. Exponential </li></ul></ul></ul></ul>
  44. 44. Principles of Open Source <ul>Educating users that: <ul><ul><li>Users are part of the community
  45. 45. Open source is participatory
  46. 46. High-level technical skills not required
  47. 47. Everyone is welcome
  48. 48. Everyone can make a contribution </li></ul></ul></ul>
  49. 49. Building a Support Community <ul>Engage users in helping others: <ul><ul><ul><li>Monitor support queue for resolved issues
  50. 50. Encourage users whose issues were solved to pass it along and help someone else </li><ul><ul><li>Cleaning up duplicates is a good starter project </li></ul></ul></ul></ul></ul></ul>
  51. 51. Problems with Support Silo <ul>Support silo not suitable for reference material: <ul><ul><ul><li>Noise – too many issues
  52. 52. Convoluted discussions, hard to find the upshot
  53. 53. User support not seen as authoritative
  54. 54. Platform not optimized for information management </li></ul></ul></ul></ul>
  55. 55. From Support to Doc Silo <ul>Documentation silo: <ul><ul><ul><li>Curated
  56. 56. Edited
  57. 57. Maintained
  58. 58. Structured </li></ul></ul></ul></ul>
  59. 59. Documentation Contributors <ul><li>Hard to get
  60. 60. Docs not glamorous - behind the scenes
  61. 61. Everyone hates docs </li><ul><ul><ul><li>Ignorance is a badge of honor
  62. 62. Nintendo attention span </li></ul></ul></ul></ul>
  63. 63. Overlapping Communities <ul>Docs and support have naturally overlapping communities: <ul><ul><ul><li>Targeted at users
  64. 64. Focused on helping
  65. 65. Content is related and reusable
  66. 66. Support contributors are intimidated regarding contributing to documentation </li></ul></ul></ul></ul>
  67. 67. Benefits of Reuse <ul><li>Documentation reduces the support queue
  68. 68. Interlinking support issues and documentation articles improves search results
  69. 69. Both can bring people into an open source project
  70. 70. Engage people who do not generally consider themselves potential contributors </li></ul>
  71. 71. What's in it for the users? <ul>Motivations: <ul><ul><ul><li>Distinguish self as domain expert
  72. 72. Professional development / experience
  73. 73. Recognition
  74. 74. Repay favor
  75. 75. Part of community
  76. 76. Part of a cool project
  77. 77. Idealism </li></ul></ul></ul></ul>
  78. 78. Thunderbird's Project <ul>Turning complaints into contributions: <ul><ul><li>Project is underway but no success metrics yet
  79. 79. Standard disclaimers, YMMV, not shown actual size, etc </li></ul></ul></ul>
  80. 80. The Support Platform <ul>Thunderbird uses the Get Satisfaction web application: <ul><ul><ul><ul><li>Threaded question / answer queue
  81. 81. Keywords / tags
  82. 82. Status / ratings
  83. 83. Easy to use - self-managing </li></ul></ul></ul></ul></ul>
  84. 85. The Documentation Platform <ul>Thunderbird uses a home-rolled wiki: <ul><ul><ul><li>Easy to author
  85. 86. Low barrier to entry
  86. 87. Searchable / sortable
  87. 88. Tags, types of articles
  88. 89. Authentication
  89. 90. Edit / validation </li></ul></ul></ul></ul>
  90. 92. Support Processes <ul>Light weight: <ul><ul><ul><li>Monitor answered questions
  91. 93. Ask thread contributors to create documentation
  92. 94. Tag / issue tracking
  93. 95. Round trip </li></ul></ul></ul></ul>
  94. 96. Documentation Processes <ul>Light weight <ul><ul><ul><li>Track / edit changes
  95. 97. Article requests / status
  96. 98. Links / round-tripping
  97. 99. List of needed articles </li></ul></ul></ul></ul>
  98. 100. Managing Fear <ul>Mitigate fear: <ul><ul><ul><li>No “canon”
  99. 101. Editorial safety net
  100. 102. Personal contact; easy access to community and moderators
  101. 103. Corrections are constructive not critical </li></ul></ul></ul></ul>
  102. 104. Contributor Satisfaction <ul>Provide a positive experience: <ul><ul><ul><li>No literary critics / no trolls / no grammar nazis </li><ul><ul><ul><li>Better to lose one knowledgeable but nasty editor than ten enthusiastic contributors </li></ul></ul></ul><li>Moderate community discussions to keep it positive and constructive
  103. 105. Congratulate, encourage, acknowledge: </li><ul><ul><ul><li>Swag
  104. 106. Public acknowledgement </li></ul></ul></ul></ul></ul></ul></ul>
  105. 107. Conclusion <ul>Open source community: <ul><ul><ul><li>Human values
  106. 108. Contributors rather than consumers </li></ul></ul></ul></ul>

×