Some community engagement news.

Marco Mucci mmucci at
Fri Aug 8 17:30:33 UTC 2014

We'll start adding a set amount of non-iteration priority bugs which require point values from the backlog to the estimation sheet starting with Iteration 34.3. 

----- Original Message -----
From: "Gavin Sharp" <gavin at>
To: "mhoye" <mhoye at>
Cc: "Firefox Dev" <firefox-dev at>
Sent: Thursday, August 7, 2014 6:18:19 PM
Subject: Re: Some community engagement news.

Rather than trying to get more bugs into the meetings, it might be
better to focus on estimating more of the existing backlog (which
already represents a very large set of "wanted" bugs):

If more of the backlog is estimated, it would be easy to split out the
"easy" bucket and use that as a set of diamond bugs.

We have a new "async estimation" process now, which makes it easier at
least for the core dev team to estimate large swaths of bugs. We
estimate bugs in the prioritized backlog before every iteration, it
wouldn't be too hard to add a few more bugs from the rest of the
backlog to that list every week. We could also set up separate
meetings to only estimate the longer tail of backlog bugs, and perhaps
even eventually broaden the pool of "estimators" to further spread out
that burden.


On Fri, Aug 1, 2014 at 10:33 AM, mhoye <mhoye at> wrote:
> This is partly a repost, as it was suggested I'd find a wider audience for
> it. A bit of a wall of text, sure, but I think it'll be worth your while.
> There are bits in here about what we're doing right, what we need more of,
> and what we can learn to do better.
> Here's an interesting paper that came out recently: " Barriers faced by
> newcomers to open source projects: a systematic review", by Igor
> Steinmacher.
> You might want to skim it, but you'll be happy to hear that:
> - We are doing basically everything right, and
> - Nothing in there comes as a huge surprise.
> That's a pretty good feeling, but it's important to have a feeling like that
> backed up with evidence.
> One nice thing about that paper is that it's got a couple of numbers in it
> that continue to matter a lot to us. Getting back to new contributors with
> 48 hours remains super-important. Likewise DXR links in good first bugs and
> tags that help matchmaking contributors' skills to the bug's needs.
> Mentors that are helpful, thank contributors and point people to the next
> bug they can work on. We do these things because we're all civilized people
> who care about our work and our community, obviously, but it's nice to know
> that in addition to feeling good, this stuff is what works.
> So: I'm in the early stages of planning a short course about effective
> mentoring; what we know about communicating and educating people, how that
> applies to our community, best practices to adopt and pitfalls to avoid. I'd
> like to subject people inside Mozilla to this thing and then expand that out
> to community contributors who we'd like to see become mentors.
> If you're interested in being a part of that - as a recipient or contributor
> - let me know.
> NEXT AND LAST you're almost done go team: We're getting a lot of good
> results from our community-engagement efforts around good-first and mentored
> bugs, but getting community members on to priority bugs hasn't been anywhere
> near as successful. Diamond bugs - bugs that make it all the way to triage
> meetings but don't ultimately get assigned - are in very short supply; we
> don't have enough variety that there are a lot of good matches to offer
> people who want to move up to the next level.
> I'd like to open the floodgates a bit here; if we can bring an extra 30 to
> 50 points worth of work into these meetings, knowing that they won't get all
> the way to assignment and particularly stuff that you can eyeball as being
> at the 1-5 workpoint level, that would give our community members a better
> sense of how to engage with stuff that's capital-I important to Mozilla.
> I've been answering community mail about how to find bugs that matter, and
> I'd like to have a good answer for people who want to do that work with us.
> Thanks,
> - mhoye
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at
firefox-dev mailing list
firefox-dev at

More information about the firefox-dev mailing list