You've probably noticed that BMO has a lot going on. We'll now delve into some more details of various definitions, features, and processes in BMO.

For people working on Firefox, please see the Bug Handling section in the in-tree documentation for information on how to triage and make decisions on bugs.

Finally, this is a work in progress (and may always be, since BMO is improving all the time). There are many stubs (indicated by italics).

Creating a Bugzilla Account

To fully use all of the features of bugzilla.mozilla.org and most importantly, to file a new bug you will need to create an account. Currently there are two ways to do this.

Create a Local Account

From the homepage, click "new account," which will let you create an account directly. You will need a valid email address. An email will be sent that will provide a special link you can follow to finish the account creation process. You will be able to enter your own private password.

Log in With GitHub

If you have a GitHub account you can use it to log in and create an account.

First click "Log in".
Then click the Octocat/GitHub logo.
If you are signed into GitHub you'll be asked if you want GitHub to login to bugzilla.mozilla.org on your behalf and what information about your account will be shared from GitHub with us.
If you aren't signed in, GitHub will ask you to login, then if you want to be asked if you want GitHub to be able to login on your behalf.
You'll be identified by the email address you use on GitHub.

Note: If you have previously created a local account as described in the first method above, and then decide to use GitHub to login later, just make sure the email address you have registered in GitHub matches the email address used to create the local account. Otherwise, a separate account will be created which is likely not what you want.

Searching

Omg, so many ways to search; why do we have so many, and how do they work?

Quick Search

Quick Search rocks! You should use it.

Advanced Search, Pronouns

Advanced search looks hardcore, but the rewards for learning how to drive it are plentiful. Also, pronouns are amazing.

Bugmail

Bugmail is the common term for automated emails from BMO. The biggest source of bugmail is changes to bugs, but BMO may also email you reports and other notices.

Filtering

Too much bugmail? Filter on BMO itself and/or via x-headers!

Filtering with GMail

GMail's ability to filter on headers is somewhat limited. We've got a separate, complete guide on advanced bugmail filtering with GMail.

Users

Bugzilla isn't as user-centric as many modern web apps, but we've added a few features in the last few years.

User Profiles

By selecting My Profile from the dropdown in BMO's header, you can see a collection of statistics about your interactions with BMO. You can use the Search field at the top to see the profile of any other BMO user. Clicking on a user's name in a bug view also provides a link to that user's profile.

There's a project page about User Profiles which has brief description of the fields.

"New to Bugzilla"

A user's comments will be tagged as "New to Bugzilla" under the following conditions:

The user does not have editbugs access.
The user has made 25 comments or less OR the account is less than 60 days old.

The "New to Bugzilla" indicator doesn't mean this account was created recently, it's an indicator that this user hasn't used Bugzilla much, please tailor your responses accordingly.

This is only displayed to people with canconfirm or editbugs access.

Understanding, Editing, and Filing Bugs

Standard Bug Fields

Bugzilla bugs have a lot of fields that allow for classifying types of bugs. This also allows for easy grouping and searching for specific bugs. Most of the standard bug fields are described here.

Comment Tagging

Want to convey some out-of-band information on a comment? Tag it. Want to auto-collapse a spammy, abusive, or obsolete comment? Tag it.

Comment Editing

Some users can edit comments made on bugs, if you do so, please follow our guidelines.

Keywords and the Whiteboard

What are all these keywords and weird whiteboard stuff? What is a whiteboard anyhow? Which should i use?

Keywords: These are a limited set of keyword tags, set by teams and people with admin privilege. You can start typing a tag and get a dropdown menu of all the keywords currently available. Keywords like "regression" and "crash" are used by engineering, release, and QA teams, for example.

Whiteboard: The whiteboard field is for free tagging. It's used both by teams and by people who want to track bugs they're interested in.

Tracking Flags

tracking-firefoxXX

Who's doing the tracking? Should i even set these flags?

Tracking flags are used by developers, triagers, QA and the release management teams to keep track of bugs whose fixes are slated to go into a particular product release. A tracking flag shows whether a bug is being investigated for possible resolution in the Firefox XX release. Bugs marked tracking-Firefox XX are bugs that must be resolved one way or another before a particular release ships. Release drivers will track and shepherd the bug until it is determined the bug no longer impacts the release.

Tracking flags have the values:

Value	Meaning
---	Default/Not nominated
?	Bug is nominated for this release
+	Bug is tracked for this release
-	Bug will not be tracked for this release
blocking	Bug is considered a blocker for this release

Most users will only be able to nominate a bug for tracking by setting the tracking flag for a release to ?. The Release Drivers group (which includes Release Management) will respond to the request for tracking.

For example, a search for tracking Firefox Beta and "+" would list the bugs which release managers decided to track for the Beta release of Firefox.

If you would like to suggest a bug and its fix be considered (by release managers) for a particular release, edit the bug and set the tracking flag for that release to ?. This is often done for a bug that's been fixed in one release channel but needs to be uplifted to another.

Refer to these guidelines on setting the tracking flag.

status-firefoxXX

A flag which represents the status of the bug with respect to Firefox XX.

status-firefoxXX
---	We don't know whether Firefox XX is affected
?	We don't know whether Firefox XX is affected, but we want to find out
unaffected	This bug does not affect Firefox XX
affected	This bug affects Firefox XX
fix-optional	This bug affects Firefox XX, we would take a fix but don't consider it as release blocking
fixed	This bug is fixed in Firefox XX
verified	This bug is fixed and verified in Firefox XX
disabled	This feature is disabled in Firefox XX
verified disabled	Disabling the feature is verified in Firefox XX
wontfix	A fix for this bug will not be accepted in Firefox XX

Approval Flags: Set on the attachment of a bug All patches landing on mozilla-beta/release/esr branches must have these nominated by setting a ? flag.
Please make sure to fill in the populated list of questions [Approval Request Comment] that come up on the attachment. This helps Release Management understand the user impact & the risk/reward analysis before we grant or deny approval. If this form is left incomplete it will be sent back to you for completion.

Status Flags

Status flags detail, at the release level, if a bug is present or will be addressed in a particular version.

Project Flags

Project flags are used to supplement a bug's prioritization. These flags are defined at the product and component level and will not be present for all bugs. Most often they are used to establish when a bug is to be worked on during a multi-release spanning project.

Example project flags are:

Needinfo Flag

In some bug tracking systems, to request information from someone about a bug, the bug is usually assigned to the person asked. In Bugzilla, we use needinfo flags.

The needinfo flag can be set at or after a bug's creation. When a needinfo flag is set, the person asked receives an email directing them to visit the bug, logging in if necessary, and answer the question.

To create a needinfo, you can specify the bug's assignee (if any,) the bug's triage owner (if one is defined,) the bug's reporter, or another user. Ask the question in a comment and set the needinfo flag before you save the bug.

Common uses of needinfo include:

Asking a bug reporter for more information so that a bug can be triaged
Asking a subject matter expert for direction or clarification

Please respond to needinfo requests quickly to keep others from being blocked.

To clear a needinfo, go to the bug's page, respond to the question and save your comment. By default the clear this needinfo request checkbox is ticked.

If you need to route the request to another person, leave the clear this needinfo request checkbox ticked, and set a new needinfo for the person to which you want to send the question to, then save the bug.

You can see the needinfo flags you have requested of others and the ones requested of you in My Dashboard.

Team to components mapping

All Bugzilla components are linked to a team.

The full list of teams is available at https://bugzilla.mozilla.org/rest/config/component_teams.

The full list of components linked to a specific team is available at https://bugzilla.mozilla.org/rest/config/component_teams/TEAM_NAME (replace TEAM_NAME with an actual team name).

Use https://bugzilla.mozilla.org/rest/product?type=accessible&include_fields=name&include_fields=components.name&include_fields=components.team_name if you want to find out what team is assigned to a specific component.

When creating a new component, make sure to link it to the right team. If you are not sure, use the team the triage owner of the new component belongs to.

Adding a new team or changing an existing one

File a bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.org&component=Administration asking to change component info.

Make sure :marco is CCed so they can adjust the quality weekly reports. Needinfo :dveditz to adjust the weekly security report

Other Ways to use BMO and its Data

Whining

Bugzilla can automatically send you buglists (requires canconfirm).

BMO can automatically send you buglists (or a group of people) at defined intervals. This requires that you have specific rights required to create whines.

APIs

I hear you want to integrate with BMO. Where to start, what to do next, and best practices which won't get you blocked.

BMO has a REST API that can perform most common tasks and is great for allowing external systems to integrate with Bugzilla. More details on how to use the API can be found here.

Dashboards

Trying to answer the "what should i do today" question? Go no further than the dashboards.

My Dashboard has some nice options for viewing lists of bugs that may be of interest to you.

Permissions and Groups

If you would like to be able to change the status of bugs from UNCONFIRMED to NEW, you will need the canconfirm permission. It also allows you to file a bug as NEW rather than as UNCONFIRMED, which is the default for bugs filed by new users to bugzilla.mozilla.org.

The editbugs permission gives you the ability to edit most fields of a bug. It's very useful for adding good information to a bug, and for making summaries more clear and descriptive.

How to apply for upgraded permissions

If you want canconfirm, you can add it yourself using triage request form.

If you want editbugs, file a new bug, including:

The URLs of two bugs to which you have attached patches or testcases.
The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.

Note: editbugs implies canconfirm there's no need to apply for both.

There are many other groups, some team-specific, some for security reasons, and some that are for corporate confidential bugs or comments. By default, everyone is in the BMO group everyone. Your permissions affect which shared searches you can see. When you create a saved search of your own, you can choose to share it with any group that are in.

You can see your current groups and permissions.

BMO vs Bugzilla

Bugzilla is the name of the popular issue-tracking software application, used by many organizations and maintained by the Bugzilla project. Its home is at http://www.bugzilla.org. While the Bugzilla project was started by Mozilla, it is administered separately, having its own Project Lead, Assistant Project Leads, and other roles. Most of the roles are, at current, occupied by Mozilla contributors, but in the past core Bugzilla contributors have not had significant involvement in other Mozilla projects. Mozilla does provide resources, including employee time, to the Bugzilla project. The best description of Mozilla's involvement in Bugzilla is that of a steward.

BMO is an abbreviation of bugzilla.mozilla.org. It is Mozilla's site-specific Bugzilla installation, which is a slight fork of the standard Bugzilla source (or "upstream") with many extensions. At the moment, the fork is technically from Bugzilla 4.2, but many features have been backported from 4.4 and master—in fact, many features in those branches were written by the BMO developers, who added them to upstream but also backported them so they could be immediately available to BMO users. Since we've backported most fixes and features that are of particular use in BMO, we haven't been strict about keeping up with the latest official upstream release. Another difference is that the BMO devs have not prioritized deployability in BMO, since fixes and features are just pushed out each week to the BMO installation, although they have made significant progress in making BMO more hackable.

In sum, the main difference between Bugzilla and BMO is that the former is the name of the general-purpose software, and the latter Mozilla's site-specific installation. An analogue is MediaWiki versus Wikipedia.

BMO/UserGuide

Contents