Coordinating Documentation and Support: Turning Complaints into Contributions

Coordinating Documentation and Support: Turning Complaints into Contributions Jennifer Zickerman, Mozilla Thunderbird [email_address] jenzed (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 flickr Image 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 else
Cleaning 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 nazis
Better 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

Coordinating Documentation and Support: Turning Complaints into Contributions

by jenzed on Jun 04, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 5

Statistics

Coordinating Documentation and Support: Turning Complaints into Contributions — Presentation Transcript