2020 is a crappy year for pretty much everyone. As you may have seen, this includes organizations such as Mozilla. So I figured it was the best time to actually talk about good stuff! This entry should be the first of a series of short articles dedicated to some great practices we have at Mozilla and that I think many open-source projects could adopt.
At its core, Mozilla is a community of open-source enthusiasts. When you’re new to an open-source community and you wish to start contributing somewhere, finding an entry point is often difficult.
This is where Mentored Bugs come in.
Mentored Bugs are a mechanism that serves:
- to introduce a new contributor to open-source in general and Mozilla projects in particular (typically Firefox, but this could just as well be any of our websites, or our data pipeline, etc.);
- to lead that new contributor up to the point they have landed their first contribution (typically code, but this could just as well be anything else, from images to translations, etc.);
- to get the new contributor discussing with a seasoned developer and the rest of the community;
- but also to offload seasoned developers from a number of tasks they do not have time to handle themselves.
So, how does this work?
Let’s consider Alice and Bob. Alice is a seasoned Firefox developer and will be our Mentor for this story. Bob is a new contributor who wishes to write some code in Firefox, but doesn’t know where to start yet. At this stage, they don’t know each other..
Like most full-time Firefox developers, Alice is currently working on a gazillion issues concurrently. She’s fixing back-end bugs, adding new front-end features and someone mentions that in her current (imaginary) project about:lizards, a simple CSS change could make this new feature much more readable. That’s great! But that’s also low priority for Alice, because most of what she’s working on is stuff that other developers are waiting for. At this stage, Alice opens an issue on bugzilla (Mozilla’s issue tracker – this would also work with github issues), write downs what needs to be done and promptly forget this low-priority task among hundreds of other low-priority tasks.
Or, in two clicks, she can turn this issue into a Mentored Bug (note that, at Mozilla, we call every change a “bug”, whether it’s something that needs to be fixed, or an improvement, or a contract that needs to be signed, etc.).
Enters Bob. Bob is curious about Firefox, has a little time, wishes to contribute some CSS, and has learnt that Mozilla has interesting tasks on Codetribute. So Bob goes to Codetribute, clicks on “I know CSS” and finds a list of open Mentored Bugs. Browsing a bit randomly, Bob picks a random entry in the list and leaves a message for the Mentor saying “Hey, I want to work on this Mentored Bug!”
The system has successfully introduced Alice and Bob.
Typically, at this stage, Alice says “Hello” to Bob and invites him to join Mozilla’s #introduction chatroom to discuss how to get started on the Mentored Bug. Bob can now ask general questions on #introduction and get an immediate response not only from Alice but also from other people who are currently connected. Members of #introduction typically help Bob get started with downloading the source code and building Firefox, etc. and help Bob find out where to ask questions. Meanwhile, Alice answers questions that are specific to the bug, either on Bugzilla or on #introduction.
And… that’s it!
It has taken two clicks from Alice to turn the task into a Mentored Bug, two clicks from Bob to find a Mentored Bug on Codetribute and they are now started. Alice and Bob are now working together until Bob has successfully provided a patch that resolves the issue.
For bonus points, Mentored Bugs can be labeled “Good first bug” or “Good later bug”, to further indicate their audience.
There are, of course, cases in which the cooperation doesn’t work. Maybe the task is more complicated than what Alice or Bob thought, or maybe Bob turns out to not have as much time at hand as he expected. But in general, this system works extremely well.
I have personally stopped counting how many new contributors I have mentored at Mozilla when I reached the count of 100 Mentored Bugs resolved, and that was about 5 years ago. Some of the contributors came back for more contributions, some moved on to other projects, some disappeared from my radar knowing a little bit more about open-source. And I know of a few who were hired by Mozilla :)
I hope I have convinced you that Mentored Bugs would be a great addition to most open-source projects. They cost basically nothing, they help both external contributors and internal contributors and are a great opportunity for both of them to learn and network. Now, this doesn’t have to stop there. I believe that even proprietary projects could benefit from (internal) mentored bugs, used to onboard new organization members and people who move across teams.
So, a round of applause to Josh Matthews, who came up with the system of Mentored Bugs back in 2011!