canmove, Confirmed users
868
edits
Contribute/Coding/Pathways: Difference between revisions
Contribute/Coding/Pathways (view source)
Revision as of 21:27, 22 September 2014
, 22 September 2014no edit summary
Jennierose (talk | contribs) No edit summary |
|||
| (6 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 32: | Line 34: | ||
** 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: Creating a test case, triaging a bug. | ** Next steps: Creating a test case, triaging a bug. | ||
| Line 53: | Line 55: | ||
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: | Active Contributors may enjoy: | ||
| Line 60: | Line 64: | ||
** Rewards/recognition: Message of thanks. | ** Rewards/recognition: Message of thanks. | ||
** Related initiatives: (Github <-> Baloo?) | ** 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: Working through patch review/resubmit process. | ** Next steps: Working through patch review/resubmit process. | ||
| Line 98: | Line 102: | ||
** Metrics: ? Bugzilla, maybe? Need an answer for this one. | ** 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: Do we need a Mentors dashboard? | ** Followup: Do we need a Mentors dashboard? | ||
** Next steps: | ** Next steps: | ||
| Line 111: | Line 115: | ||
=== 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 124: | 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. | ||