October 13, 2011 § 11 Comments
We can make Bugzilla more newbie-friendly.
edit Thanks for pointing me to mentored bugs, Josh!
Earlier today, a discussion got me thinking about how we can lower the entry barriers for people who want to contribute to Mozilla in a technical or semi-technical way but do not know where to start – by “technical or semi-technical”, I have in mind developers, web developers, translators, and more generally people who need to commit some form of patch to any of the Mozilla subprojects.
There are many things that we can improve, but for this post, I would like to concentrate on Bugzilla tweaks that I believe could be useful. These tweaks come from a simple remark: for all contributors Bugzilla is, in fact, a form of contribution console. Unfortunately, for the moment, I see the following problems:
- Bugzilla doesn’t help newcomers find easy entry points;
- Bugzilla doesn’t guide newcomers towards their first patch;
- Bugzilla doesn’t help old-timers help newcomers.
So, let’s see how we could improve Bugzilla.
Making newcomers visible and encouraging old-timers to help them
I believe that the first thing we need to do is to make sure that newbies are more visible to old-timers. For this purpose, we can provide an account attribute “I’m a beginner, please be gentle”, which appears in the profile, ticked by default, and remains there until unticked. Every message, attachment or patch provided by a newbie is clearly labelled as such.
This label may come with a link to the wiki with suggestions for old-timers wanting to help the newbie.
Similarly, we can encourage old-timers to adopt a newbie. For this purpose, we can provide an account attribute “Adopt a newbie”, with a list of accounts. Every message, attachment or patch provided by an adopted newbie is automatically tracked by the adopter.
Note As far as I understand, these features are already essentially implemented. I’m just proposing a small tweak.
Having Bugzilla tell stories
Bugzilla is a nice place for reporting bugs and discussing how to solve it. I propose a simple tweak to make Bugzilla tell the story of a patch. Let me show you one possible manner of doing this:
Each of these link should help a newcomer on one step towards getting a patch submitted and accepted:
- “Help me set up for contributing” points to some of the wiki pages we already have containing project-specific setup documentation. For Mozilla coding bugs, this explains how to build Mozilla. For localization bug, this explains how to setup whichever tools are required, etc. This is set up on a per-component basis.
- “Help me contact the developers” points to the component-specific wiki page with all the contact information (IRC channel, forum, mailing-list, module owner e-mail address, etc.).
- “Help me find project doc” points to the project-specific wiki page with all the documentation.
- “Help me submit a contribution” points to a beginner-oriented wiki page with the information on submitting. For mozilla-central, for instance, beginners should be able to find the two lines that will let them export everything they have done as one hg patch.
- “What’s next” points to a wiki page detailing the submission approval process, the various forums, IRC channels, etc. to which the contributor can participate.
This is for beginners. As you may have seen, there is another toolbar, designed for experienced developers/community members:
This toolbar is designed to keep track of activity on bugs that the user follows:
- “Unconfirmed” lists the number of UNCO bugs followed by the user.
- “In progress” lists the number of NEW bugs followed by the user.
- “Review” lists the number of patches pending review in bugs followed by the user.
- “Mentoring” lists the unread messages and patches submitted by newbies adopted by the user.
Clicking on each link points to a bugzilla search of the corresponding bugs.
Making easy bugs easy to discover
New contributors need to find good entry points. For this purpose, we have project-specific lists of good first bugs. However, at the moment, the lists I could find are both hard to discover and unmaintained. So, let’s integrate this in Bugzilla. As it turns out, it’s
quite easydone already (and better than what I suggested initially). I suggest adding two tags: “easy” and “average”. Every bug can be annotated as “easy” if a developer believes that it’s a good first bug or “average” if a developer believes that it’s a bug that requires some experience but no architectural overview.
Once this is done, we can link from all our wikis and contributor engagement pages to Bugzilla searches with all the “easy” and all the “average” bugs, both project-wide and by component.
This one is more of a dream. I believe that, at some point, we could develop an add-on that can be installed directly fro the Bugzilla toolbar, and whose role is to provide a wizard to help users:
- install the appropriate source management tool;
- once the tool is installed, submit a patch for review.
Initially, this add-on covers only mozilla-central. Later, upgrades to this add-on and/or project-specific add-ons may be added for projects not covered by mozilla-central (typically projects hosted on github).
Inspiration: want to do better than (otherwise excellent) github “pull request” 🙂
- First bug report tagged “new”? Earn a badge!
- First patch submitted? Earn a badge!
- First patch accepted? Earn a badge!
- Same thing for the marks of 10, 50, 100 …
Ok, this lists the tweaks that I can think of to improve newbie experience with contributions. What do you think? Any way we can make this better?