Harmonizing BMO and Mozilla GitHub Projects

View the Project on GitHub mozilla/bmo-harmony

A Mozillian’s Garden of Metadata for GitHub

You have good reasons for running your piece of the Firefox project on GitHub: familiar tooling, an easy path for contributors, change sets which are integrated with code reviews, and emoji 🦊.

To have better consistency with code and task tracking among Mozilla Central, Bugzilla, and GitHub, we request that you use a common set of labels in your projects. Benefits of improved consistency in our conventions include:

Several of you are doing this already. But we need you to do some tuning of your process.


Bugs in GitHub issues have two states: closed and open. Bugzilla has a more confusing richer set of states.

When you close a bug, add a label indicating the resolution.


Firefox projects in Bugzilla use the priority field to indicate when and if a bug will be worked on.

Use these labels in your project to indicate priorities.

You probably already have a set of tags, so do an edit to convert them or use the GitHub settings app.


In GitHub issues metadata is either a label or the bug’s open/closed state.

Some Bugzilla metadata behaves like labels, but you need to be careful with how you use it in order not to confuse QA.


In Bugzilla, the regression keyword indicates a regression in existing behavior introduced by a code change.

When a bug is labeled as a regression in GitHub does it imply the regression is in the code module in GitHub, or the module that’s landed in Mozilla Central? Using the label regression-internal will signal QA that the regression is internal to your development cycle, and not one introduced into the Mozilla Central tree.

If it is not clear which pull request caused the regression, add the regressionwindow-wanted label.

Other Keywords

Other useful labels include enhancement to distinguish feature requests, and good first issue to signal to contributors (along with adequate documentation.)

Status Flags

Bugzilla uses a set of status flags to communicate priorities between contributors, product managers, and the the release management team.

A bug which contributors consider a high priority may not effect the current release, and vice versa.

In Bugzilla, status for each release number is represented by a field which takes one of multiple values.

It’s recommended that you don’t use status and tracking flag tags in GitHub issues and use another tool such a Trello or a worksheet to communicate to Release Drivers on work that needs to land in the mozilla-centra1 repository.