Tales of Science-Fiction Bugs: The Thing That Killed Talos

Have you ever encountered one of these bugs? One in which every single line of your code is correct, in which every type-check passes, every single unit test succeeds, the specifications are fulfilled but somehow, for no reason that can be explained rationally, it just does not work? I call them Science-Fiction Bugs. I am sure that you have met some of them. For some reason, the Mozilla Performance Team seems to stumble upon such bugs rather often, perhaps because we spend so much time refactoring other team’s code long after the original authors have moved on to other features, and combining their code with undertested libraries and technologies. Truly, this is life on the Frontier.

Today, I would like to tell you the tale of one of these Science-Fiction Bugs: The Thing That Killed Talos.

Fighting the good fight for fun and credits, with Mozilla Education

Are you a student?

Do you want to fight the good fight, for the Future of the Web, and earn credits along the way?

Mozilla Education maintains a tracker of student project topics. Each project is followed by one (or more) mentor from the Mozilla Community.

Then what are you waiting for? Come and pick or join a project or get in touch to suggest new ideas!

Are you an educator?

The tracker is also open to you. Do not hesitate to pick projects for your students, send students to us or contact us with project ideas.

We offer/accept both Development-oriented, Research-oriented projects and not-CS-oriented-at-all projects.

Are you an open-source developer/community?

If things work out smoothly, we intend to progressively open this tracker to other (non-Mozilla) projects related to the future of the web. Stay tuned – or contact us!

Helping Bugzilla Help Newcomers Help Mozilla Help Users

tl;dr

We can make Bugzilla more newbie-friendly.

edit Thanks for pointing me to mentored bugs, Josh!

The context

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:

1. “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.
2. “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.).
3. “Help me find project doc” points to the project-specific wiki page with all the documentation.
4. “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.
5. “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:

1. “Unconfirmed” lists the number of UNCO bugs followed by the user.
2. “In progress” lists the number of NEW bugs followed by the user.
3. “Review” lists the number of patches pending review in bugs followed by the user.
4. “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.

Submission add-on

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”

Badges!

• 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 …

Any thoughts?

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?

Le logiciel libre

Je commence ce billet depuis la Journée du Libre à Bourges, assis tranquillement dans l’amphithéâtre, en train d’écouter un exposé fort intéressant. Dans l’assistance, personne ne demande ce qu’est un Logiciel Libre ou à quoi cela peut bien servir. C’est que les orateurs, il faut l’avouer, prêchent à des convertis, certains d’entre eux acteurs du monde du Logiciel Libre.

Lundi dernier, par contre, lorsque j’ai mentionné les Logiciels Libres à mes étudiants, la classe s’est divisée en deux parties : ceux d’entre eux qui n’en avaient jamais entendu parler et ceux qui m’ont répondu sans hésiter que, oui, il s’agissait du “freeware”, c’est-à-dire du logiciel gratuit. J’espère que vous ne m’en voudrez pas si je les corrige par le biais de ce blog.

Un logiciel libre est caractérisé non pas par son coût mais par la liberté — c’est-à-dire par des droits accordés aux utilisateurs.