GitHub Metadata Recommendations¶
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:
Consistency makes measurement of processes simpler across the organization
Consistency makes it easier to write re-usable process tools
Consistency increases clarity for those than need to work across different repositories and bug trackers
Consistency reduces friction around engineering mobility between projects
We recommend creating sets of labels in your project to do this.
In Bugzilla bugs are distinguished by type:
tasks. Use a label to make this distinction in your project.
Bugs in GitHub issues have two states: closed and open. Bugzilla has a richer set of states.
When you close a bug, add a label indicating the resolution.
A change set for the bug has been landed in Mozilla-Central
A GitHub issue could be closed, but the change set has not landed so it would be still considered open from the Bugzilla point of view
The problem described is not a bug.
The problem is vaguely described with no steps to reproduce, or is a support request.
The problem described is a bug which will never be fixed.
The problem is a duplicate of an existing bug. Be sure to link the bug this is a duplicate of.
All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur.
The triage process for Firefox bugs in Bugzilla requires a non default value of a bug’s Severity (definitions).
Release Status Flags¶
Open Firefox bugs may also have status flags
status_firefoxNN) set for Nightly, Beta, Release, or ESR.
Firefox projects in Bugzilla can use the priority field to indicate when a bug will be worked on.
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
To represent Bugzilla fields, use labels following this scheme.
N/A(reserved for bugs of type
good first bug,
You may already have a set of tags, so do an edit to convert them or use the GitHub settings app.