New community in Firefox 24; degree and improving
mhoye at mozilla.com
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 whatcanidoformozilla.org. 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.
- 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev