Hack 98. Survive Bugzilla

Survive and thrive in the scary world of Mozilla's Bugzilla database.

Bugzilla, like Firefox, is a product of the efforts of the Mozilla Foundation and, before that, of Netscape Communications. Its home page is http://www.bugzilla.org. Within the Mozilla community, the Bugzilla installation at http://bugzilla.mozilla.org contains a great deal of the workflow, history, current status, and collective memory associated with Mozilla technology. This hack provides a brief introduction.

9.9.1. Landing on Planet Bugzilla

Anyone can contribute to Mozilla's Bugzilla database, but it is a place of work, not a place of play. Marc Prensky's Digital Game-Based Learning (McGraw Hill) describes a related concept called "hard fun." Bugzilla requires systematic rather than spontaneous participation, so any hard fun only comes through hard preparation. Spontaneous participation is poorly received in Bugzilla.

9.9.1.1 Differences between labor and work

In a normal workplace, such as an office, you might be accustomed to a workflow that involves several people. When you hand tasks to those after you, you expect them to be done. When people before you hand tasks to you, they expect you to take them on. This is all based on an obligation that you incurred. You agreed to supply labor in return for money from the workplace. You can't meet your obligation without assistance from your coworkers.

Bugzilla does not operate like that. Most participants are volunteers or have solved the money problem. None, or very few, of the Bugzilla participants have a labor contract. They work only because they want to. As a result, most participants can do or not do whatever they want. There is no point making rules, because there is no labor obligation. Even those with labor contracts are employed for what they might do, rather than what they must do.

Regardless of how you judge Mozilla culture, it is this freedom of individuals to wander about without any formal arrangement that makes Mozilla a community.

9.9.1.2 Gift culture

If you put a piece of work into Bugzilla that someone else has cause to appreciate, that's good for them. Eventually, someone will put something into Bugzilla that you will have cause to appreciate. That is all there is to it: nonspecific gift giving.

The gifts offered, however, are not entirely nonspecific. Software development is an intensive activity that requires concentration. People don't like their concentration being broken, especially by irrelevancies. Gifts that fit with the narrow topics a recipient works on are welcome. All other gifts are not. Precision and accuracy in gift giving is very importantlet's say criticalin Bugzilla.

Furthermore, new gift givers represent a risk. The risk is that their gifts might not be appropriate. The new gift giver could be a burden on the whole community, which is trying hard to concentrate. It takes existing participants a long time to let their guard down and accept that a new participant is contributing in a way that's reliable and not merely disruptive.

Typically, a gift offered in Bugzilla might just be a few sentences. Said out loud, a few sentences carry little weight. In Bugzilla, they carry a great deal of weight.

9.9.2. Dissecting Bug Reports

Each Bugzilla bug report contains several kinds of information, all mixed together.

Figure 9-2. Essential fields for a bug report

This figures in this hack show the different sets of fields present in a bug report. These screenshots are from the URL https://bugzilla.mozilla.org/show_bug.cgi?id=193068, which you can examine at any time. The pages diplayed here have been slightly hacked so that all important fields fit in a single window. There's no effect on the way the form works.

Figure 9-2 highlights the fields that contain the essential information about the bug.

These few fields are all that's really required to start a bug report. The bug number is generated automatically. These fields are also just about all you need when doing a free text search for bugs. It is not trivially obvious where the description information is stored. It can be searched from Bugzilla's query page using the comments field. That's where it resides.

As shown in Figure 9-3, the bug report is burdened with lots of helpful information for beginners. Many of the links lead nowhere, except to an explanatory Help screen. This is a little confusing, because other controls on the page do form submission or query requests. Perhaps one day, there'll be a separate Help system for Bugzilla.

Figure 9-3. Help hotspots in a bug report

After the bug is entered, it starts its journey through a set of states (the combination of Status and Resolution) until it reaches its end. That end could be the garbage bin, an accepted new feature of Mozilla or Firefox, or a number of other options. This is a complex process, and the best way to learn it is to CC yourself on a new bug or bugs and watch the email reports come in as work on the bug progresses. During this journey, more information is added to the bug that describes the problem or issue at hand, such as test cases and patch fixes.

The particular bug being reported in Figure 9-4 has no test-case attachments; instead, it has two candidate patch fixes. Figure 9-4 shows all this in-process bug data and the things to click or type into that add data to the bug.

Figure 9-4. Data entry and data for a bug report

While the bug report is underway, lots of people are interested in it. They show their interest by adding their email addresses and by marking the bug in many different ways. This marking behavior supports each interested person's own work practices; they can then recall the bug using special or standard queries.

Release Managers, module owners, and QA people need these marks to get their jobs done, so there are some standard and agreed-upon marks that shouldn't be used for other purposes. If a mark includes a +, that means "looking good for a given release" (good news). If a mark includes a -, that means "this bug is to be stalled or slipped past a given release" (bad news). A + used on a version number has a different meaning than a + as described above; when used on a version it means "this is a trunk version that includes experimental changes on top of the noted release." Figure 9-5 points out examples of many marks.

Figure 9-5. Marks and observers placed in a bug report

Finally, the bug report contains more information than can possibly fit on one page. A number of bug-report features just replace the current page with special reports and ancillary information about the bug, as shown in Figure 9-6.

Figure 9-6. Ancillary information for a given bug report

Try loading up this page and running through the screenshots in Figure 9-2 through Figure 9-6. There's no substitute for experience with Bugzilla, but some early orientation can help.