There are two takeaway points that I would like to state up front:
- when you find a bug that’s well-scoped and you have a fairly clear idea of how to fix it, add [mentor=yournickname] to the whiteboard.
- when stating that a bug is good for someone else to work on, please please add a comment with relevant MXR links and information on how to fix it.
I’m absolutely thrilled to see people marking bugs as being good for other people to fix. That’s what the “good first bug” and “mentor=” annotations are all about. It’s a message from someone who understands the issue, and it indicates that the bug is fixable with a reasonable amount of effort on the part of someone who is not a core contributor.
I’m going to go out on a limb and say that using [good first bug] is no longer desirable. The list of bugs with this annotation has grown beyond a manageable size (not in a good way), and it can appear like an impenetrable barrier for someone who shows up with the idea that they “want to work on Firefox.” Now, I subscribe to the RSS feed of this list, so I see every new addition and will likely to ping the culprit on IRC and ask whether the bug in question would make a better mentored bug. What is a mentored bug, you might ask? Segue!
Mentored bugs are the new hotness. A mentored bug is one in which someone with knowledge of the code in question has added the [mentor=name] annotation to the bug’s whiteboard, and represents a contract that:
- the issue is fixable
- a fix is desired
- there exists a plan for how to proceed with fixing it
- the specified mentor understands the problem and proposed solution
These are the absolute basics. Without these guarantees, a bug should not be assigned a mentor, and certainly shouldn’t be proposed to a contributor looking for work.
Furthermore, I propose that bug mentorship be a social contract as well. When I was a volunteer contributor with a non-Mozilla day job, I found it difficult to get on IRC during work hours, so I wasn’t able to have real-time conversations with my mentor. Moreover, the work I was doing was understood by very few people, so the folks on IRC in the evenings couldn’t really help me either. Therefore, I recommend that bug mentors make the commitment to respond to emails from contributors regarding the bug in question, because that can significantly ease the burden for eager volunteers in situations like my own. I have carried on several long email conversations with people working on my mentored bugs, consisting of advice, links to documentation, and technical support, and they have resulted in patches for those bugs every single time.
So, should you become a bug mentor? Absolutely! How can you decide whether a given bug is a good candidate for mentorship? Here’s a helpful checklist that I go through when considering that question:
- Does it fulfill the basic requirements above?
- Am I willing/able to answer questions about the proposed solution, or do I know who to point a contributor towards if I don’t have the answers?
That’s it! Bug mentorship is easiest when you have a complete understanding of a problem, but all that is truly necessary is enough knowledge to act as a willing guide for someone who knows less than you.
The final point that I want to emphasize – when you’re marking a bug as being good for another person to work on, please take a few moments to dump your investigative work in the bug. Function names, MXR links, steps to reproduce, explanations of the problem and how it can be solved: these are the stepping stones that allow a contributor to start looking into how to solve the problem without waiting to get in contact with you. The less latency involved, the better. Remember, these bugs are often being approached by people with very little experience in the code in question – spell out the assumptions you make, and you’ll make someone else’s job easier.
Appendix A – Types of bugs that are good candidates for mentoring:
- Reliable edge-case crashes – easily reproducible, typically not in the critical path, great visibility (contributor can demonstrate behaviour change to third party)
- Bugs containing simple (or at least explicitly spelled-out), verified testcases – easily reproducible, good visibility
- Well-scoped tasks (ie. change all uses of X to Y, remove Z) – easily explained
Posted on September 30th, 2011 by Josh Matthews
Filed under: mozilla | 2 Comments »