Mozilla: Effective Community Building Practices

This morning, I got to attend a session where Mozilla folks spoke about some strategies and methods they have found work for them in building community. It was definitely an interesting session. The only thing was that it was very development centric (focused on bugs and patches). I would’ve liked to hear any efforts going on with getting more contributions from non-technical people who might be able to help with testing, documentation, etc.

Full Session Notes on Etherpad

Introduction

Mike Hoye

Slides

Our process reflect and reinforce our values.
if something is hard, we don’t value making it easy.
if something is slow, we don’t value making it fast.

Gratitude matters.

positive feedback, thanking contributors

Accessibility

barriers to participation – how hard is it to get to the point of effectively making a change to part of the code? what documentation is there, and is it out of date?
make sure to avoid “secret knowledge” e.g. out of date docs.
it should be one step from 0 to ready to help
“Patches accepted”: don’t do this. functionally identical to “we will accept your work. don’t ask us anything”
solutions: good first bugs (narrow in scope, address localized change, biggest challenge is getting set up to make change and understanding process)
People want to work with us, admire us. People follow us; talk to them, talk about ways they can work with us.
Bugzilla is a social network, and we should leverage that.
Biggest reasons for first patches failing (from study):
** suboptimal solutions 24.6%
** incomplete fix 22.3%
** including unnecessary changes 11.9%
** test failures 5.3%
avoid 2/3 of patch rejections with this one weird trick: link to previous similar guidelines/patches, link to source, describe changes necessary, tests to run (and how to run them)
~8000 patches never reviewed in bugzilla
11% of first patches have formatting issues
feature coming: automatic formatting

Retention

why participate in our projects vs. another one?
toxic members have a huge impact: actively mocking, condescending
corollary: response to mocking sends message to what is acceptable
we’re pretty good at this, but we can be a lot better at this
The person with the most authority in a room. How that person acts sends a very clear message to the rest of the community of what’s accepted. If that’s you, you need to step up.

Gratitude

David Eaves talked about state of the community. Get back to people within 24 hours of making contribution (even just “we got the contribution. thank you”, or “while we look at X, want to do Y?”)
very likely to come back for future contributions.
If you let it rot even as long as a week, then they go. Unlikely to come back.

Victory Conditions

Delegation
Mentoring
Evangelism
Growth
** next level is not just doing work with us, but representing us
** spending too much time getting new people, instead of specific people who could takeover ownership of …
** need to focus on the growth process of individuals
** dropoff rate of 2-3 patches is severe. need to identify prominent contributors and give them a chance to do more.
** this is what sustainability looks like; reinforce the culture

Community Building Tips

Mike Conley

X-Bugzilla-Mentors – set yourself as a mentor on a bug, mark them so it’s the first thing you check.
Can have multiple mentors
engaging someone with an unknown skillset…
** be gentle, probe sensitively; be careful about being too technical, welcome them into the community
** assume they’re starting from zero, but be ready to ramp up if they show they’ve got a greater understanding
** assume positive intent. They’re nervous and want to be cool.
** Be available. Yes, point to documentation, but also leave yourself available for questions.
** Ask questions – be curious about how they’re doing and if they’re having fun.
** Fun is very important.
Hand-hold, but then start to release..
** after their first patch, point them to a new one
** get them connected with other mentors as well, so they have multiple connections
** if possible, get them into IRC and talking to the team, not just PM’ing you
IRC channel is really scary for a first-timer
Recognition – badges are effective, but emphasize praising the work they’ve done rather than the contributor directly (“This patch for X was great, and it was done by Y”)
break problems down into smaller pieces
poorly spec’d solutions are heartbreaking. be truly confident when suggesting solution, or warn early if not 100% confident.
Underlying message is that they belong here.

Integrating Community into Projects

Clint Talbert

have list of “things to get done”, and then have “should be mentoring people”
community is everybody’s job, so it’s nobody’s job.
restructure the way we work on projects, community pieces become part of project, especially important for QA
in list of things to do that day, incorporate community activities
folding contributors into projects is more valuable. longer-running, has continuity, reduces falloff effect since further work is related.
When organization thinks something is important, it has a budget, a calendar, and someone is accountable for that thing. If Involving Community does not have those things, it is not valued or a priority.

Mentor Bugs

Josh Matthews

What makes a mentored bug effective?
give information up front. Is there enough information to get started? Ideally, should not have to ask any questions in order to get started.
Corollary: in providing information to get started, forces mentor to think about proposed solution. will it work? this provides value for all parties involved.
address mentor bugs first – helps retention, helps contributor goodwill
invite questions from assignees. Asking even if it was clear. Invite non-comprehension, show that it’s okay.
ask questions/make suggestions. Suggest other things to work on something else, but that seem like more work to the mentor. Thank them, and invite them to contact you or team via IRC, etc. Offer to provide suggestions for future work if they want them.

A Different Approach

Joel Maher