BMO/UserGuide
You've probably noticed that BMO has a lot going on. Hopefully you've already watched Understanding Mozilla: Bugzilla, which gives a quick tour of BMO. We'll now delve into some more details of various definitions, features, and processes in BMO.
Many Mozilla teams have had their own getting-started guides to BMO usage. Some of these have fallen out of date, recommending procedures that have been obsoleted by new features. We're hoping this will be a comprehensive guide for Mozilla contributors on any and all teams. If your team has some useful info in your own BMO guide and it's not here, feel free to add it. If we notice that it's no longer a recommended way to use BMO, we'll fix it. Be bold in the wiki way!
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). If you feel like you know enough to write a paragraph or two about any subject, please do!
Contents
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.
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.
Other Searches (Instant, Simple, Google)
In case you were looking for more ways to search.
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.
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
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.
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.
Needinfo Flag
It's good and you should use it.
If you have a question about a bug, and you'd like to direct that question to a specific person, you can do that easily with the needinfo flag.
The person you need info from will get bugmail with (look up the X-Bugzilla-header) in the header. This may get a person's attention faster than adding them to the CC list of a bug.
You can see the needinfo flags you have requested of others and the ones requested of you in My Dashboard.
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.
