New community in Firefox 24; degree and improving

Mike Hoye mhoye at
Mon Sep 30 16:09:53 UTC 2013

On 2013-09-28 4:26 PM, Justin Dolske wrote:
> I'd be curious to hear thoughts and ideas (Summit fodder!) on how we 
> can work on improving that. Are there things other teams are already 
> doing that we can do too? Front-end is the most Web-like part of 
> Firefox (JS/DOM/CSS), are there web-developers who can get involved 
> but don't know it? And so on.

There are a bunch of people - an entire Community Building Team, you 
might say! - working on this right now on a couple of fronts.

- Codebase accessibility efforts; we know that there are a lot of 
pain-points involved in getting set up to actually fix a Firefox bug, 
particularly if you (like the overwhelming majority of our user base) 
are on Windows, starting from "getting set up to actually build Firefox 
is quite hard" right down to "our build documentation is inconsistent, 
sometimes  opaque, and often implicitly assumes you're a journeyman Unix 
developer". Glob and Liz Henry, among many others, have done a ton of 
work to mark routes and sherpa people up Mount Bugzilla, but getting 
past the MDN basecamp is still too hard a climb for many. There's plenty 
of progress being made here, but plenty still to make.

- Contribution onramps - We're getting better at flagging bugs as 
good-first-bugs and surfacing other entry-points for new contributors. 
Josh is doing a lot of heavy lifting there that you've seen go by 
already, but there's more work to be done there. We don't have a 
spectrum of "non-critical-path-but-nice-to-have" bugs, projects or just 
contribution-efforts that we can show people, so they have a 
smorgasboard of things to choose from. It's gotten a bit sidelined by 
the Summit - my own contributions to this have, at least - but David 
Boswell is doing some thankless work trying to redesign our moribund, 
not-very-helpful "contribute to Mozilla" page with a spectrum of options 
ranging from "I'm waiting for a bus and I've got Firefox Beta on my 
phone" to "I'm the head of the PhD program at a major university, and 
I'm looking for research opportunities for a dozen grad students." We 
suspect that spelling out what people need to have, or know, or invest 
time-wise into this stuff will make it a lot easier for people to find 
opportunities that are a good fit, and pretty soon we'll have enough 
data to know for sure.

- Recognition efforts aimed at contributor retention; getting people to 
contribute _one_ bug is great, but getting people to become longtime 
contributors is way better. Movement on this is slow, but we've got a 
bunch of research now that shows that getting back to new contributors 
about their first patch within a day or so - even if it's just to say 
"thank you, we'll get to this within a week" has a huge impact on 
retention rates. We've also been calling out new contributors in the 
release notes recently, and I've been sending new contributors postcards 
stickers as well as a small physical token of thanks. I don't have 
enough data there to judge if it's an effective program, but it's one of 
a couple of things we're trying.

- Tracking the migration of contributors across different aspects of the 
project is also something underway, so that when somebody moves from 
Sumo to Firefox to Thunderbird to Bugzilla, or whatever, we know that we 
haven't actually _lost_ that contributor, they're just moving around, 
and so that we can get a better sense of what parts of the project are 
doing really good work fostering and retaining community, and who 
aren't. For example, the SUMO people are at one end of the spectrum, 
doing an _amazing_ job of getting people involved as long-standing 
contributors; at the other end of the spectrum *[REDACTED - You know who 
you are. -mhoye]*. Slightly more speculatively, a thing I'd like to see 
in the next few months is that our "community-supported" projects have 
some access to the rewards structures - the Mozilla Reps, etc - that our 
flagship projects enjoy, in the hopes that they'll act as gateway drugs 
to our high-priority efforts.

And that's just a taste.

*So in short:* if the question is "Community involvement is important, 
what can I do and how can I help?", there's a couple of things you can 
lead out with that I think will make a big difference.

- Throw the little fish back in the water. If it's a small thing that's 
not on a critical path, flag it as a good first bug so Josh can surface 
it via  If it's a nice-to-have project, link 
it up on a wiki page so that when somebody says "how can I help", you 
have an answer to hand.

- From an engineering perspective, get back to first-time contributor's 
bugs promptly, even if it's just to say thanks and you'll follow up 
soon. And when you do land that patch, suggest one or two things they 
can work on next.

- Active outreach: there's a whole team of people here with deep ties to 
the community, chomping at the bit to help you.  Waiting for people to 
come to you isn't going to cut it, when there are other places _just 
inside Mozilla_, much less "out there in a universe full of 
opportunities" actively fostering community involvement.
**Most importantly:*

- If community is important to you for real, then make community 
engagement - mentoring, first-bug resolution, outreach, recognition, the 
rest - an honest-to-God instrumented-for-success-metrics quarterly goal. 
If this is a real priority for you, or your corner of Mozilla, then run 
up a banner that saying you're going to put this many hours trying to 
accomplish this many things. And then tell us, so that the 
community-building team can make your success part of _our_ quarterly 


- mhoye

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the firefox-dev mailing list