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

Slides

  • different ways to look at community that may be effective
  • not everyone is going to make it a priority, not everyone is a good mentor
  • don’t try to make everyone be a mentor
  • recognizing people: if contributor fixes a bug, tell them “you just saved me 5 minutes per day with this change”. Identify value of work. Knowing that work is beneficial, sense of ownership. Bugs filed against contributor’s work yields ownership.
  • Not everyone’s a mentor, but everyone needs to participate:
    ** chat on IRC as a team, they can be an observer and learn
    ** define the work you’re doing, in a way that someone can understand the goal and how to contribute
    ** good first bugs and mentors – small subset of team should be good mentors, and every bug should have multiple mentors
  • We talk about community, but no one makes it a goal. Let’s make it actionable. Vision and direction is not enough.

Published by

Cynthia

A librarian learning the ways of technology, accessibility, metadata, and people

Leave a Comment

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s