<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2013-09-28 4:26 PM, Justin Dolske
wrote:<br>
</div>
<blockquote cite="mid:52473B81.2060803@mozilla.com" type="cite"><br>
<br>
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.
<br>
</blockquote>
<br>
There are a bunch of people - an entire Community Building Team, you
might say! - working on this right now on a couple of fronts. <br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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.<br>
<br>
- 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 <b>[REDACTED - You know who you are. -mhoye]</b>. 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.<br>
<br>
And that's just a taste. <br>
<br>
<big><big><b>So in short:</b></big></big> 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.<br>
<br>
- 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. <br>
<br>
- 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. <br>
<br>
- 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. <br>
<big><big><b><br>
</b><b>Most importantly:</b></big></big><br>
<br>
- 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 goals. <br>
<br>
Thanks,<br>
<br>
- mhoye<br>
<br>
<br>
</body>
</html>