Confirmed users, Bureaucrats and Sysops emeriti
421
edits
(Created page with "This page is intended to describe what makes up a good Mentored Bug, and to clarify expectations around what constitutes a good bug-mentoring relationship. = Good Mentored B...") |
No edit summary |
||
| Line 17: | Line 17: | ||
We want the contributor's participation in mentored bugs to be a good experience that's the start of a long-term relationship. | We want the contributor's participation in mentored bugs to be a good experience that's the start of a long-term relationship. | ||
- For mentored bugs, it is generally expected that you've your development environment set up, and that you have made some contributions to the Mozilla codebase before. | - For mentored bugs, it is generally expected that you've your development environment set up, and that you have made some contributions to the Mozilla codebase before. Having successfully completed a Good First Bug is a good indication that you're ready; few mentored bugs, if any, will be good starting points for new contributors. | ||
- Regular communication with your mentor is important; your mentor needs confidence that the bug is moving in a good direction, and | - Regular communication with your mentor is important; your mentor needs confidence that the bug is moving in a good direction, and that you haven't gone into the weeds or lost interest. Please communicate with your mentor on IRC or via email at least once a week. | ||
-- While this is at the discretion of mentor, a bug whose contributor goes radio-silent for more than two weeks will generally be deassigned and offered to other contributors. | |||
- Respect the mentor's guidance, particularly with respect to patch submission and review; the successful integration of a mentored contributor's patch is as much a reflection on the mentor's guidance as on the work of the contributor. | |||
=== The Mentor's Role === | === The Mentor's Role === | ||
We know that the speed and manner in which we reply to new contributors questions is very highly correlated with contributor retention. | |||
- Be judicious in what bugs, as well as what contributors, you agree to mentor. You are not obliged to mentor any particular contributor, but it is a real commitment. Do not hesitate to look up prior work if you need to make a decision. | |||
- Return emailed questions promptly: within 24 hours *at most*. Engagement falloff is measurably worse after 1 day and dramatically worse after three. If possible, establish "office hours" on IRC during which you agree to be available to answer that contributor's questions. | |||
- Follow up with contributors who seem to be off track or losing interest. It you go two weeks without hearing from a contributor on a mentored bug, there is no shame in putting it back in the common pool. | |||
=== Following Up === | |||
While we have tooling around some community enagement, badges and other recognition tools, please check to make sure: | |||
- That a contributor is recognized for their efforts, even if this is a simple as thanks, and | |||
- that after a successful contribution, that the next contribution opportunity is avilable. | |||