User:Tyler/BMOsurvival2

Bug Reports, from Top to Bottom

The Details

While the states of a bug's status is always important information, equally important, and often more so, are the nitty grity details of the bug report. Every portion of a bug has meaning, so we will cover them all. The following details will start at the top of a filed bug, and work down to the bottom.

NOTE: This document was written when BMO was at version 3.2. Minor details may have changed since then, though this document strives to be up-to-date.

The Average Bug

Summary (Title)

The summary of a bug serves as the title, and is one of the most important human aspects of a bug. It is what most users will use to recognize a bug with, and searches will display the title with the bug number. Make sure a bug title always accurately describes a bug in as few words as possible while being legible.

Bug Number

The bug number appears next to the bug summary, and is automatically assigned a bug when it is filed.

Status

This section can not be edited directly here, but at the bottom of the bug. it shows the current status and resolution of a bug.

Whiteboard

Below the summary and bug number is the whiteboard. This is a place to put notes on the bug, which are often describing actions that need to be performed. For example, the entry CLOSEME DATE is an entry usually entered when a bug has not seen any activity after a while. If no one responds within the time specified, the bug will be closed as INCOMPLETE. It is generally best to leave the whiteboard alone until you have gained experience at what needs to be entered. Part 3 goes into more detail on the Whiteboard.

Keywords

This part of the bug report is the part that many searches are run on. For example, a bug report on a crash will have the keyword "crash" in this field, while a bug with a patch that needs to be checked in will have "checkin-needed". Then, when someone wants to search for bugs that need checking, or for crashes, they can search all bugs for those keywords in this field.

CC list

In case you did not know, CC means carbon copy, and this part of the bug is a list of all those who will be notified when the bug is changed. You can add any BMO member's e-mail to this area (useful for when asking for help), and of course, your own.

Product / Component

These fields show the product (Firefox, Thunderbird, Sunbird, etc.) that the bug exists in, and the component (General, Search, etc.). Make sure to select the correct product and component for your issue.

Version

This drop down is for designating the version of software that is affected by this bug. If a bug affects two different version, such as 3.0 branch and trunk in Firefox for example, put the most recent version in this field. If the bug only affects the 3.0 branch, place 3.0 branch. Self explanatory.

OS

Choose the operating system and platform that is affected by this bug.

Importance

when filing a bug, you need to select a severity. The options are:

• Blocker
• Critical
• Major
• Normal
• Minor
• Trivial
• Enhancement

Carefully read BUG SEVERITY before marking your severity. Please note, we understand that while an issue may be a big problem for you, it may not meet the qualifications for the severity you marked it. If a Triage or QA member changes the severity, politely ask them why they did so

The important field with options such as P1, P2, etc. is usually reserved for developers and module owners to change. It is different than severity, and denotes the priority this bug holds in the "waiting to be FIXED" line.

Target Milestone

This field is similar to the above priority field, but is also supposed to be filled in by whomever checks a patch in. For example, if a patch makes the 1.9.2 Gecko release, this field should be marked 1.9.2.

QA Contact / Assigned to:

These fields are for the Quality Assurance contact's e-mail address, and the person whom the bug is assigned to. These fields are filled in by the system, unless someone decides to assign a bug to themselves.

Flags

While normal members of the community are encouraged not to mess with priority and target milestone, the flag section is one they can use. While different then Priority/Target Milestone, it works along similar lines. Because more people change this, it deserves an in depth discussion. Consider the following example:

A Bug is filed against Firefox. A member of the community marks it as wanted-3.1 "?". This means that the member would like to see a patch fixing this bug included in the Firefox 3.1 release. The next day, a module owner comes by, notices the ? and agrees the bug should be in 3.1. He then marks it as wanted-3.1 "+". This means he approves that a fix should be placed in the 3.1 release. However, he can mark it as "-", which means he sees difficulties in getting it in that release.

There are two important requests for this field. One is "blocking" and the other is "wanted". Blocking means the product should not ship without a fix. Wanted means it would be nice to have. Be careful what you mark.

URL

If the bug shows up on a specific page, put the URL here

Depends on / Blocks

If another bug needs to be fixed, is causing this issue, or blocks this bug in some way, put the number in "Depends On". If this bug blocks another bug, that that number in "Blocks"

Attachments

Below the large flags, and severity area of the bug report, what I call "the markers", is the comments and attachment area, the working section. At the top is a small box called "Add an Attachment". This could be several things. A screenshot illustrating the bug, a proposed patch, or any number of things. Patches will be gone into in detail in Part 3.

Comments

Now comes what is usually the largest part of a bug, the comments. This is the conversation on a bug. Note this is not like a forum, you can not edit your comments, and they are there for everyone to see. Make sure your comments are polite, useful and DO NOT SPAM. This means, do not post the same comment twice (or more), give useless information, etc. Also, before commenting on a bug, read the previous ones. Remember that, depending on the size of the bug, you could be sending an e-mail with everything you said to dozens of people, or hundreds on a very large bug, so put yourself in their shoes. Think "would I want to read this in my inbox?" And is it really helpful to the bug report? If not, don't post.

Status

Although the location of the status at the bottom of the page seems a little odd, it is there. This is where you can change the status of a bug, from, say, UNCONFIRMED to NEW.

More info

bugzilla fields goes into the fields in more detail