This document describes the contribution pathways towards becoming a core Firefox contributor, including goals, metrics, and followup, to help Mozilla meaningfully and measurably grow and maintain our contributor base.

It is broadly based on the Pathways model adopted by the Community Building Team. Engagement points that feed into to the Coding pathway are listed on the Engagement page.

As of early 2014, Mozilla's biggest challenges around community growth revolve around accessibility and retention; the two biggest dials we can turn to drive contribution rates are to make it easier for new participants to contribute and rewarding for them to continue.

Contribution Tiers

Individual contributions here have been roughly grouped into tiers, for reasons that will be explained in the "Gardening" section below.

Tier 1 - Casual Contributors

These are the foot-in-the-door starting points and entry-level contributions that are the bread and butter of community contribution. They don't (and should not) present a high bar to participation, and be amenable to anonymous contribution where possible.

Tier 1 contributions include:

• Installing Nightly
  • Metrics: mzl.la, download count
  • Rewards/recognition: Thanks on Nightly page.
  • Related initiatives: Point Aurora start page towards nightly? Advocacy to Student Ambassadors list.
  • Followup: The Nightly first-run page includes invitations to join Mozillians, file bugs and hack on Firefox.
  • Next steps: Get a Bugzilla account, build Firefox.

• Creating Bugzilla account
  • Metrics: Bugzilla (feeds Baloo)
  • Rewards/recognition: A badge (automatic)
  • Related initiatives:
  • Followup:
  • Next steps: File a bug, reproduce a bug.

• Filing a bug
  • Metrics: Bugzilla
  • Rewards/recognition: Thanks. I
  • Related initiatives: Automated badge-awarding and metrics integrated into Baloo gives us lots of
  • Followup: Contributor is invited to create a Mozillians acc't. When a bug or its dupe is resolved fixed, first-time contributors should be receive a note thanking them for their contribution.
  • Next steps: Creating a test case, triaging a bug.

• Creating a test case
  • Metrics: HG (?)
  • Rewards/recognition: A badge (manual)
  • Related initiatives:
  • Followup: This may count as a contribution - up to the discretion of the filer - towards adding that contributor to Mozilla’s list of contributors.
  • Next steps: Build Firefox, create a patch.

• Creating a Mozillians Account
  • Metrics: Mozillians.org
  • Rewards/recognition: No
  • Related initiatives:
  • Followup: The signup process should present users with engineering-relevant groups to sign up for, among the usual regional options.
  • Next steps: Follow a Mozillians group (Themed? Regional?), look at the Reps program.

Tier 2 - Active Contributors

This is the target tier for contributor engagement; we know that the dropout rate between third and fourth contributions is dramatically lower than between first and second, so fostering contributors at this level - a process as simple as prompt replies to questions and basic acknowledgement of their contributions - is essential.

While some of the badge-awarding here is numerical - 1,3,5 etc... - as badge awarding becomes more common and easier to automate, more interesting and whimsical choices become possible.

Active Contributors may enjoy:

• Submitting a patch / Filing a pull request
  • Metrics: Bugzilla / Github
  • Rewards/recognition: Message of thanks.
  • Related initiatives: (Github <-> Baloo?)
  • Followup: Prompt. As per here we know that prompt review of a patch is strongly correlated to contributor retention. Invite contributor to sign up for Mozillians, if they have not yet done so.
  • Next steps: Working through patch review/resubmit process.

• Having patches r+’ed and merged
  • Metrics: Mercurial (script something for Github?)
  • Rewards/recognition: Badge, Name in about:credits, callout in release notes for first patch. Recognition at various contribution intervals - 1, 3, 5, 10, 25, 50, 100...
  • Related initiatives: ReviewBoard integration with Baloo is going to be important.
  • Followup: When a patch is r+’ed, contributors should be guided towards their next bug.
  • Next steps: Apply for try-server access

• Gain try-server (Commit Level 1) access
  • Metrics: Bugzilla
  • Rewards/recognition: Badge on Mozillians (For access? For first all-green push?)
  • Related initiatives: Eventual ReviewBoard integration.
  • Followup: We should figure out how to celebrate somebody's first all-green test run.
  • Next steps: Direct contributor to a next patch, offer a mentored bug that appears to be a good fit.

Tier 3 - Core Contributors

These are consistent contributors

• Consistent Tier 1/2 participation across several (3, 4+?) releases.
  • Metrics: Mercurial, other
  • Rewards/recognition: Badge? Lotta badges getting thrown around here.
  • Related initiatives:
  • Followup: People who make it here for a few releases and then disappear need to be followed up through separate channels. A regular contributor's departure, silent or otherwise, is a big deal worth investigating.
  • Next steps:

• Gaining Level 2 commit access
  • Metrics: Mercurial? LDAP?
  • Rewards/recognition: Everything gets a badge, I guess, but we should send a shirt at this point.
  • Related initiatives:
  • Followup:
  • Next steps: More of the same.

• Mentoring a new contributor through the contribution process.
  • Metrics: ? Bugzilla, maybe? Need an answer for this one.
  • Rewards/recognition: Badge on Mozillians, mention in “mentors” section in release notes.
  • Related initiatives: The mentoring doc.
  • Followup: Do we need a Mentors dashboard?
  • Next steps:

• Reviewing patches / pull requests
  • Metrics: Bugzilla / Github
  • Rewards/recognition: First reviewed patch merged should be worth something interesting. Swag?
  • Related initiatives:
  • Followup:
  • Next steps:

High-level contributors

At this point typical rewards for contributions become a disincentive; nobody at this level of play needs badges. Substantial and meaningful involvement with contributors at this level should be routine; contributors who have demonstrated this level of commitment should be supported with hardware and software as required and invited to workweeks and events (MozFests, etc) as a matter of course.

• Gaining Level 3 commit access
  • Metrics: LDAP

• Checking in your own code to repo
  • Metrics: Mercurial / Github

• Pushing someone else's code to repo
  • Metrics: Mercurial / Github

• Becoming a module owner or peer
  • Metrics: Despot (LDAP?)

Gardening And Routine Maintenance

To support the tiered engagement approach and measure its ongoing success, Mike Hoye [mhoye] will:

• Maintain a list of minimum of 40 good first bugs with active mentors at all times.
• Maintain a list minimum of 30 good next bugs with active mentors at all times.
• Identify 10 "diamond" work items each two-week iteration with willing mentors.
• Verify that all the above meet the criteria laid out in the Mentoring guidelines
• Routinely evangelizing the above in various channels, including Start Mozilla.
• Evangelizing the use of Josh Matthews' Mentored bug email filter. With many engineers relying exclusively on the Needinfo flag now, lots of "may I work on this bug?" questions get ignored for weeks or months at a time.
• interviewing first-time contributors, as well as contributors who have moved on, to figure out how to improve our processes.
• Auditing existing mentored and good-first bugs to make sure they are as claimed. Reassigning bad-good-first-bugs as mentored bugs as appropriate, verifying that mentors continue to be willing.