Your SlideShare is downloading. ×
  • Like
Coordinating Documentation and Support: Turning Complaints into Contributions
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Coordinating Documentation and Support: Turning Complaints into Contributions

  • 1,361 views
Published

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

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

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,361
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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