Contribute/Coding/Mentoring

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 Bugs

There are three parts to a successful mentored bug: a clear initial description of the problem, clear expectations on the part of the both the mentor and contributor, and a cooperative working relationship as the bug is resolved.

Clear Requirements

Above and beyond what normally makes up a good bug description, a good mentored bug should include:

- A broad description of what an acceptable solution to the bug would look like, in particular including the testing/validation requirements the contributor would need to land a fix. - If possible, a [ http://dxr.mozilla.org/mozilla-central/source/ link to DXR] or other relevant repo where the bug resides. - If possible, links to prior art - similar bugs in Bugzilla, similar tests in the tree.

The Contributor's Role

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. 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 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

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.