nalexander:community update, part the first
The part of my job that is special — the part I wouldn’t get working away from Mozilla — is enabling community code contributors to participate in and own the direction of Fennec (Firefox for Android). There are so many ways to contribute to Mozilla, but this post I’ll limit myself to Fennec code contribution because it’s the on-ramp that the Fennec team has put the most effort into, and it’s my own personal cause.
In part the second, I give a project status update and advertise a variety of new projects to the community. If you’re interested, contact me!
Mozilla’s very own @mhoye has been very active encouraging new contributors. Mike (and others — I’m looking at you, @lastontheboat) pioneered marking tickets as [good first bugs]; and pushed to add the mentor field to Bugzilla; and maintains @StartMozilla. Mike works tirelessly to widen the funnel of new contributors approaching the Mozilla project. In large part Mike’s internal evangelism has worked: we think we know some things that work to help people make their first contribution:
- we have improved our on-boarding documentation;
- we have made it easier to build Fennec the first time (mach bootstrap) and to read the code base (Gradle integration);
- we have made it easier to find [good first bug] tickets and mentors;
- and we have committed to making #mobile a friendly, welcoming space for potential contributors.
We’re now looking to grow our existing contributors. How do we work with contributors to move them from "new arrival" to "valued contributor"? What’s the value exchange?
I’ve been thinking about this for a few years now. Mobile team — which really means Fennec team, since the Firefox for iOS is very new — has captured some unicorns . I’m thinking of /u/capella, who is de-facto owner of the Fennec input front-end code, and /u/vivek — if I didn’t include someone, it wasn’t intentional. We’re truly lucky to have had the benefit of their contributions for as long as we have. But we don’t really understand how we caught them. And the thing about unicorns is that you only need to capture one unicorn to look like a great unicorn hunter. Mobile team is right at that point: we’ve had some success attracting code contributors, but we don’t really know how we did it — and we don’t have a strategy to attract more.
Recently I’ve had success attracting and retaining high-value code contributors with the following tactic. I’ve started offering medium-sized projects that let me and a contributor collaborate on an area of the code base over time. By medium-sized I really mean not just a [good first bug] or a [good next bug]; I mean an area of work that’s somewhat open-ended and will develop deeper expertise in at least one part of the code base. (I’m trying to keep these projects well-scoped, but that’s a battle for me as an engineer: scoping work is hard.) I mean a few things by high-value code contributor: principally, a repeat contributor who might grow into a reviewer and module peer.
This approach requires some up-front work on my part. It’s not easy writing a bug with enough context to be meaningful to someone without deep context into how Fennec is built and where our team strategy is leading us. It’s not easy to file dependent tickets that are correctly "chunked", and to provide enough links and technical details to guide a reasonable implementation. It’s especially not easy trying to anticipate high-level problems in parts of the code that I myself don’t know much (or anything!) about.
But the reward can be great. High-value contributors have time and skills that we want. In exchange, they want things: experience; an opportunity to work with excellent engineers; the chance to contribute to the Open Web; references; etc. The folks with that mix need to be challenged; they need to see that their contribution leads somewhere: to an implemented feature, to a performance improvement, to a better future. I want to give a pathway to that future. Contributions on-ramps need to lead to contribution in-roads.
On a purely practical level, after mentoring a [good first bug] to completion, it’s really hard to find a [good next bug]! Often, there’s nothing in the same or a similar area. Or there’s no ticket (that I know about!) that is a reasonable challenge. And as a contributor, there’s no satisfaction in fixing typos or doing trivial variable substitutions more than once or twice. With a scoped project somewhat specified up front, I always have at least an idea of what could come next.
I haven’t yet tried to make one of these projects self-contained, in the sense of having a [good first bug], and then some [good next bugs], and then some meatier implementation details. But I think it’s a reasonable model and I intend to try it.
There’s so much more to this discussion. I think some of my success retaining contributors is that I put in a lot of time in #mobile answering questions. I get to know the people I work with — where they live, what they do every day, what kinds of change they want to see in the project. I’ll reach out to them if I find tickets that are good fits for them. If I could scale this high-touch approach, I would!
I don’t claim to know much about our contributor motivations. I think we do a good job of recognizing our contributors inside our team but an absolutely terrible job recognizing our contributors in the Mozilla community and in the larger Android community. We have essentially no formal mentoring (outside of internships, which are paid) or formal recognition (such as writing letters of recommendation). I day-dream about a "new contributor survey" that would quickly let us learn about our community and match contributors to mentors, tickets, and the outcomes that they want.
I’m really interested in understanding the health of our contributor community. We know that keeping the pipeline of [good first bugs] and mentored tickets wide helps, but we don’t measure that flow. That’s all looking inwards, to our own community. What if we looked outwards? How much would outreach to targeted Android communities, projects, and even specific developers help? Could we further Fennec’s mission by targeting key web projects and developers? Could we attract key people to evangelize Fennec? We don’t know.
Finally, I haven’t really seen this approach used in other parts of Mozilla, although I hear rumblings that @redheadedcuban and the A-Team do something like this. If your team does this, let me know!
The Firefox for Android team is always making things better for contributors! Get involved with Firefox for Android.
- Sun 5 July 2015: Initial version.
|||I use the term unicorn to mean an extremely capable code contributor, in the most positive sense — someone who might be unique.|