Contribute/Coding/Pathways: Difference between revisions
No edit summary |
|||
Line 132: | Line 132: | ||
* Identify 10 "diamond" work items each two-week iteration with willing mentors. | * Identify 10 "diamond" work items each two-week iteration with willing mentors. | ||
* Verify that all the above meet the criteria laid out in the [https://wiki.mozilla.org/Contribute/Coding/Mentoring Mentoring guidelines] | * Verify that all the above meet the criteria laid out in the [https://wiki.mozilla.org/Contribute/Coding/Mentoring Mentoring guidelines] | ||
* | * Routinely evangelizing the above in various channels, including [https://twitter.com/startmozilla Start Mozilla]. | ||
* Evangelizing the use of Josh Matthews' [http://www.joshmatthews.net/blog/2013/12/you-are-receiving-this-mail-because-you-are-mentoring-this-bug/ 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. | |||
As well, in Q2 2014, Hoye will also be interviewing first-time contributors, as well as contributors who have moved on, to figure out how to improve our processes. |
Revision as of 18:36, 28 March 2014
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 Communiy 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: Proposed for
- Followup: The Nightly first-run page includes invitations to join Mozillians, file bugs and hack on Firefox.
- Next steps: Linked off
- Creating Bugzilla account
- Metrics: Bugzilla (feeds Baloo)
- Rewards/recognition: A badge (automatic)
- Related initiatives:
- Followup:
- Next steps:
- Filing a bug
- Metrics: Bugzilla
- Rewards/recognition: Thanks. I
- Related initiatives: Automated badge-awarding and metrics integrated into [ https://wiki.mozilla.org/Baloo 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
- 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:
- 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:
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.
- Submitting a patch / Filing a pull request
- Metrics: Bugzilla / Github
- Rewards/recognition: Message of thanks.
- Related initiatives:
- 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.
- Next steps:
- Having patches r+’ed and merged
- Metrics: Mercurial (script something for Github?)
- Rewards/recognition: 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:
- Try server access
- Metrics: Bugzilla
- Rewards/recognition: Badge on Mozillians (For access? For first all-green push?)
- Related initiatives: Eventual ReviewBoard integration.
- Followup:
- Next steps:
Tier 3 - Core Contributors
These are consistent contributors
- Consistent Tier 1 participation across (3+?) consecutive releases.
- Metrics: HG
- Rewards/recognition: Badge?
- Related initiatives:
- Followup:
- Next steps:
- Gaining Level 1/2 commit access
- Metrics: HG
- Rewards/recognition: Badge?
- Related initiatives:
- Followup:
- Next steps:
- Mentoring a new contributor through the contribution process.
- Metrics: Unclear
- Rewards/recognition: Badge on Mozillians, mention in “mentors” section in release notes.
- Related initiatives: [ https://wiki.mozilla.org/Contribute/Coding/Mentoring#Good_Mentored_Bugs The mentoring doc ].
- Followup:
- Next steps:
- Reviewing patches / pull requests
- Metrics: Bugzilla / Github
- Rewards/recognition:
- Related initiatives:
- Followup:
- Next steps:
High-level contributors
At this point typical rewards for contributions become a disincentive. Substantial and meaningful involvement with contributors at this level should be routine; contributors who have demonstrated this level of commitment should be supported with harbe 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 will be pursuing the following goals:
- 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.
As well, in Q2 2014, Hoye will also be interviewing first-time contributors, as well as contributors who have moved on, to figure out how to improve our processes.