New community in Firefox 24; degree and improving

[Justin Dolske]

You may have seen
https://blog.mozilla.org/community/2013/09/16/firefox-24-new-contributors/
on Planet recently. Here it is in a nutshell: Firefox 24 contained 93
bugfixes from 43 developers (32 specifically being new volunteers) for
whom it was their first contribution. Note that this includes all
community members who landed their first patch in FF24 -- employees and
interns too.

I was curious how this broke down so I, uhh, broke it down (by Bugzilla
product, see bug 921752 if you want a ginormous buglist URL):

* 62 of the bugs listed were in Core. (Within that there were 15
JavaScript Engine bugs, 8 Audio/Video bugs, and 7 Canvas bugs. But it's
actually pretty spread out, because those three biggest clusters were
due to new developers fixing multiple bugs. EG, Benjamin Bouvier fixed
12 of the 15 JS bugs.)

* 13 Firefox for Android bugs. (Including 8 bugs from two developers who
fixed 4 apiece.)

* 6 Desktop Firefox bugs
* 4 Firefox Health Report bugs
* 4 Testing bugs
* 3 Toolkit bugs
* 1 Mozilla Services bug (log4moz)

This is just one data point (Firefox 24), and doesn't include fixes from
people who have landed patches in previous releases. But I don't feel
like this is anomolous in the bigger picture -- volunteer involvement in
desktop front-end developent is pretty light, and that doesn't bode well
for a healthy and vibrant community.

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.

Also, has anyone done the Hg/Bugzilla-fu to get data on all volunteer
contributions (first-patch or not) by release? I think I've seen such a
thing before, but can't remember who did it or where. Bonus points for
data on how people come-and-go over time -- helping people get involved
is one thing, helping them stay involved is another. I've not seen any
analysis of that before.

Justin
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Monica Chew]

> Also, has anyone done the Hg/Bugzilla-fu to get data on all volunteer
> contributions (first-patch or not) by release?

Josh has a dashboard of commits from new contributors over time here: http://www.joshmatthews.net/swagger/health.html

Monica

[Josh Matthews]

On 09/29/2013 04:14 PM, Monica Chew wrote:>> Also, has anyone done the Hg/Bugzilla-fu to get data on all volunteer

>> contributions (first-patch or not) by release?
>
> Josh has a dashboard of commits from new contributors over time here: http://www.joshmatthews.net/swagger/health.html
>
> Monica
>

I should really write a script to keep that updated; you can tell that I haven't touched it in the past year. What Justin is likely thinking of is my collection of volunteer contribution statistics per release at https://docs.google.com/spreadsheet/ccc?key=0ApOXjgdvXthCdEtVMndsWHFzVlNzZzJoR0I3ZVJkSWc#gid=0 . Be sure to look at both the overall view (default page) and the breakdown per release (other pages) that buckets volunteers into number of commits in a given release.

I don't have information about carry-over and churn yet, but that's coming next. My scripts just gained the ability to get results for specific directories (such as browser/ and mobile/), and I'm currently working on generating the graphs automatically instead of copying the data into Google Docs. I'll be sure to drop a link to github in the next few days.

Cheers,
Josh

[Justin Dolske]

On 9/29/13 6:20 PM, Josh Matthews wrote:

> What Justin is likely thinking of
> is my collection of volunteer contribution statistics per release at
> https://docs.google.com/spreadsheet/ccc?key=0ApOXjgdvXthCdEtVMndsWHFzVlNzZzJoR0I3ZVJkSWc#gid=0

Not sure I've seen that before, but it's exactly the kind of data I'm
interested in!

I'm pretty surprised to see volunteer commits hovering around the 1/3
mark, even with an increase in overall commits. That's great, although
I'd want to see how that holds when looking at LOC and what areas it
might be concentrated in.

> [...]I'll be sure to drop a link to github in the next
> few days.

That would be fantastic.

Justin

[Josh Matthews]

Scripts available at https://github.com/jdm/outrider, first cut at graphs available at http://www.joshmatthews.net/graphs/ (still learning how to use R, de-uglifying patches welcome). Anyone with access to the MoCo phonebook should be able to replicate my results and start playing with the data (sorry, I had to swear up and down that I wouldn't distribute the employment data before I could get access to it); I wrote a python script that scrapes all emails from the phonebook programmatically.

Cheers,
Josh

[Rodrigo Rocha Gomes e Souza]

On Sat, Sep 28, 2013 at 5:26 PM, Justin Dolske <dol...@mozilla.com> wrote:

Also, has anyone done the Hg/Bugzilla-fu to get data on all volunteer contributions (first-patch or not) by release? I think I've seen such a thing before, but can't remember who did it or where. Bonus points for data on how people come-and-go over time -- helping people get involved is one thing, helping them stay involved is another. I've not seen any analysis of that before.

I created some graphs using bug reports from Firefox for Android: https://rawgithub.com/rodrigorgs/mozilla-contributors/master/mozilla-contributors.html. I selected only fixed bugs, and considered a "contributor" anyone who flagged an attachment with review?. 

I'm a PhD student at Federal University of Bahia, Brazil, and I perform statistical analyses on bug reports as part of my research. I currently only have access to Firefox for Android bugs, but my scripts should work on other projects as well. 

Please let me know if you'd like to see any other statistics computed from bug reports. I'll be glad to help.

[]s

Rodrigo

[Mike Hoye]

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.

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 goals. 

Thanks,

- mhoye

[Gervase Markham]

On 30/09/13 17:09, Mike Hoye wrote:
> - 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.

A long time ago, I wrote some software called Patch Manager, which
allowed people to hack on and produce patches for chrome bugs using only
a downloaded build of Firefox. Patch Manager itself morphed into Patch
Maker, a general "help you use your SCM" thing
<http://www.gerv.net/software/patch-maker/> but perhaps the idea could
be revived?

Gerv

[Axel Hecht]

FWIW, I proposed an open session in Santa Clara for contributing to
Firefox through the browser. The way that you can fork/edit/pull-request
all within the browser on github. Not something we can just copy, but I
think that we can use as inspiration.

Axel