Recommendation of a Strategy
Coordinating Documentation and Support: Turning Complaints into
Contributions
Jennifer Zickerman, Mozilla
[email protected] (IRC and Twitter)
Open Source Teams
Open source projects coordinate teams that focus on various
tasks:
Development
Quality assurance
Support
Documentation (for users, for developers)
etc
Open Source Contributors
Various types of contributors:
Core: employees, maintainers, benevolent dictators, fairy
godmothers...
Contributors: volunteers
Users
Open Source Communities
Teams / contributors
The source of success, growth, vitality and longevity of every
open source project
It's Complicated
Different motivations among different teams:
Development versus support
Quality assurance versus development
etc
It's Even More Complicated
Different motivations among contributors:
It's a job
Professional advancement / development
Community membership
Recognition
Silos
Each of the teams (and sometimes the contributors) may operate
in separate information silos
via dsearles on flickrImage thx to dsearls on Flickr
User Support and User Docs
Two teams / two silos
Similar audiences and contributor profile
Manage processes, platforms and people to make them
interconnect
The User
The largest community the user community - is an
abstraction:
Too big to grapple with or ...
Too specific in their needs to understand
A cost, not an opportunity
Users are Meta
Core and contributors talk to each other, not users.
Instead:
Traffic analysis
Meta-analysis of support questions
Usability studies
How our cousin feels about things
User Overload
Thunderbird:
Employees:10
User Overload
Thunderbird:
Employees:10
Contributors: 50
User Overload
Thunderbird:
Employees:10
Contributors: 50
Users: 10,000,000
User Potential
Too many to engage individually, but:
Largest potential contributor source
Potential for support and documentation contributors,
evangelism
Army of Awesome
Support Individualizes Users
Potential for personal engagement, but doesn't scale:
Thunderbird: one support person, over 1000 new topics per
week
Manage expectations: Community Support
Encourage peer support
Building Community
People come for support, may stay around to help others:
If they have a good experience
Learn about the open in open source (contribution)
Exponential
Principles of Open Source
Educating users that:
Users are part of the community
Open source is participatory
High-level technical skills not required
Everyone is welcome
Everyone can make a contribution
Building a Support Community
Engage users in helping others:
Monitor support queue for resolved issues
Encourage users whose issues were solved to pass it along and
help someone elseCleaning up duplicates is a good starter
project
Problems with Support Silo
Support silo not suitable for reference material:
Noise too many issues
Convoluted discussions, hard to find the upshot
User support not seen as authoritative
Platform not optimized for information management
From Support to Doc Silo
Documentation silo:
Curated
Edited
Maintained
Structured
Documentation Contributors
Hard to get
Docs not glamorous - behind the scenes
Everyone hates docs
Ignorance is a badge of honor
Nintendo attention span
Overlapping Communities
Docs and support have naturally overlapping communities:
Targeted at users
Focused on helping
Content is related and reusable
Support contributors are intimidated regarding contributing to
documentation
Benefits of Reuse
Documentation reduces the support queue
Interlinking support issues and documentation articles improves
search results
Both can bring people into an open source project
Engage people who do not generally consider themselves potential
contributors
What's in it for the users?
Motivations:
Distinguish self as domain expert
Professional development / experience
Recognition
Repay favor
Part of community
Part of a cool project
Idealism
Thunderbird's Project
Turning complaints into contributions:
Project is underway but no success metrics yet
Standard disclaimers, YMMV, not shown actual size, etc
The Support Platform
Thunderbird uses the Get Satisfaction web application:
Threaded question / answer queue
Keywords / tags
Status / ratings
Easy to use - self-managing
The Documentation Platform
Thunderbird uses a home-rolled wiki:
Easy to author
Low barrier to entry
Searchable / sortable
Tags, types of articles
Authentication
Edit / validation
Support Processes
Light weight:
Monitor answered questions
Ask thread contributors to create documentation
Tag / issue tracking
Round trip
Documentation Processes
Light weight
Track / edit changes
Article requests / status
Links / round-tripping
List of needed articles
Managing Fear
Mitigate fear:
No canon
Editorial safety net
Personal contact; easy access to community and moderators
Corrections are constructive not critical
Contributor Satisfaction
Provide a positive experience:
No literary critics / no trolls / no grammar nazisBetter to lose
one knowledgeable but nasty editor than ten enthusiastic
contributors
Moderate community discussions to keep it positive and
constructive
Congratulate, encourage, acknowledge:Swag
Public acknowledgement
Conclusion
Open source community:
Human values
Contributors rather than consumers
