Contribute/Coding/Pathways: Difference between revisions
Jennierose (talk | contribs) No edit summary |
|||
(11 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
[[Category: Contribute]] [[Category: Coding]] | |||
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. | 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 [ | It is broadly based on the [[Contribute/Pathways|Pathways model]] adopted by the Community Building Team. Engagement points that feed into to the Coding pathway are [[Contribute/Coding/Engagement|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. | 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. | ||
Line 17: | Line 19: | ||
* Installing Nightly | * Installing Nightly | ||
** Metrics: mzl.la, download count | ** Metrics: mzl.la, download count | ||
**Rewards/recognition: Thanks on Nightly page. | ** Rewards/recognition: Thanks on Nightly page. | ||
**Related initiatives: | ** 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. | ** Followup: The Nightly first-run page includes invitations to join Mozillians, file bugs and hack on Firefox. | ||
** Next steps: | ** Next steps: Get a Bugzilla account, build Firefox. | ||
* Creating Bugzilla account | * Creating Bugzilla account | ||
Line 27: | Line 29: | ||
** Related initiatives: | ** Related initiatives: | ||
** Followup: | ** Followup: | ||
** Next steps: | ** Next steps: File a bug, reproduce a bug. | ||
* Filing a bug | * Filing a bug | ||
** Metrics: Bugzilla | ** Metrics: Bugzilla | ||
** Rewards/recognition: Thanks. I | ** Rewards/recognition: Thanks. I | ||
** Related initiatives: Automated badge-awarding and metrics integrated into [ | ** 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. | ** 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: | ** Next steps: Creating a test case, triaging a bug. | ||
* Creating a test case | * Creating a test case | ||
Line 41: | Line 43: | ||
** Related initiatives: | ** 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. | ** 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: | ** Next steps: Build Firefox, create a patch. | ||
* Creating a Mozillians Account | * Creating a Mozillians Account | ||
Line 48: | Line 50: | ||
** Related initiatives: | ** Related initiatives: | ||
** Followup: The signup process should present users with engineering-relevant groups to sign up for, among the usual regional options. | ** Followup: The signup process should present users with engineering-relevant groups to sign up for, among the usual regional options. | ||
** Next steps: | ** Next steps: Follow a Mozillians group (Themed? Regional?), look at the Reps program. | ||
=== Tier 2 - Active Contributors === | === 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. | 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 | * Submitting a patch / Filing a pull request | ||
** Metrics: Bugzilla / Github | ** Metrics: Bugzilla / Github | ||
** Rewards/recognition: Message of thanks. | ** Rewards/recognition: Message of thanks. | ||
** Related initiatives: | ** Related initiatives: (Github <-> Baloo?) | ||
** Followup: Prompt. As per [ | ** Followup: Prompt. As per [[Contribute/Coding/Mentoring#Reviewer_Followup|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: | ** Next steps: Working through patch review/resubmit process. | ||
* Having | * Having patches r+’ed and merged | ||
** Metrics: Mercurial (script something for Github?) | ** 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... | ** 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. | ** 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. | ** Followup: When a patch is r+’ed, contributors should be guided towards their next bug. | ||
** Next steps: | ** Next steps: Apply for try-server access | ||
* | * Gain try-server (Commit Level 1) access | ||
** Metrics: Bugzilla | ** Metrics: Bugzilla | ||
** Rewards/recognition: Badge on Mozillians (For access? For first all-green push?) | ** Rewards/recognition: Badge on Mozillians (For access? For first all-green push?) | ||
** Related initiatives: Eventual ReviewBoard integration. | ** Related initiatives: Eventual ReviewBoard integration. | ||
** Followup: | ** Followup: We should figure out how to celebrate somebody's first all-green test run. | ||
** Next steps: | ** Next steps: Direct contributor to a next patch, offer a mentored bug that appears to be a good fit. | ||
=== Tier 3 - Core Contributors === | === Tier 3 - Core Contributors === | ||
Line 79: | Line 85: | ||
These are consistent contributors | These are consistent contributors | ||
* Consistent Tier 1 participation across (3+?) | * Consistent Tier 1/2 participation across several (3, 4+?) releases. | ||
** Metrics: | ** Metrics: Mercurial, other | ||
** Rewards/recognition: Badge? | ** Rewards/recognition: Badge? Lotta badges getting thrown around here. | ||
** Related initiatives: | ** Related initiatives: | ||
** Followup: | ** 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: | ** Next steps: | ||
* Gaining Level | * Gaining Level 2 commit access | ||
** Metrics: | ** Metrics: Mercurial? LDAP? | ||
** Rewards/recognition: | ** Rewards/recognition: Everything gets a badge, I guess, but we should send a shirt at this point. | ||
** Related initiatives: | ** Related initiatives: | ||
** Followup: | ** Followup: | ||
** Next steps: | ** Next steps: More of the same. | ||
* Mentoring a new contributor through the contribution process. | * Mentoring a new contributor through the contribution process. | ||
** Metrics: | ** Metrics: ? Bugzilla, maybe? Need an answer for this one. | ||
** Rewards/recognition: Badge on Mozillians, mention in “mentors” section in release notes. | ** Rewards/recognition: Badge on Mozillians, mention in “mentors” section in release notes. | ||
** Related initiatives: [ | ** Related initiatives: [[Contribute/Coding/Mentoring#Good_Mentored_Bugs|The mentoring doc]]. | ||
** Followup: | ** Followup: Do we need a Mentors dashboard? | ||
** Next steps: | ** Next steps: | ||
* Reviewing patches / pull requests | * Reviewing patches / pull requests | ||
** Metrics: Bugzilla / Github | ** Metrics: Bugzilla / Github | ||
** Rewards/recognition: | ** Rewards/recognition: First reviewed patch merged should be worth something interesting. Swag? | ||
** Related initiatives: | ** Related initiatives: | ||
** Followup: | ** Followup: | ||
** Next steps: | ** Next steps: | ||
=== High-level contributors === | === 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 | 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 | * Gaining Level 3 commit access | ||
Line 122: | Line 128: | ||
* Becoming a module owner or peer | * Becoming a module owner or peer | ||
** Metrics: Despot (LDAP?) | ** Metrics: Despot (LDAP?) | ||
= Gardening And Routine Maintenance = | = Gardening And Routine Maintenance = | ||
To support the tiered engagement approach and measure its ongoing success, Mike Hoye will | 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 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. | * 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. | * Identify 10 "diamond" work items each two-week iteration with willing mentors. | ||
* Verify that all the above meet the criteria laid out in the [ | * Verify that all the above meet the criteria laid out in the [[Contribute/Coding/Mentoring|Mentoring guidelines]] | ||
* Routinely evangelizing the above in various channels, including [https://twitter.com/startmozilla Start Mozilla]. | * 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. | * 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. | ||
* interviewing first-time contributors, as well as contributors who have moved on, to figure out how to improve our processes. | * 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 | * 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. |
Latest revision as of 21:27, 22 September 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 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.