From MozillaWiki
< BMO‎ | UserGuide(Redirected from BMO/Whiteboard)
Jump to: navigation, search

Each bug has a free-form single line text entry box for adding tags and status information. This wiki page is dedicated to collect a comprehensive list of whiteboard tags used in the Mozilla project.

Whiteboard considered harmful

It is recommended that you request alternative metadata instead of using whiteboard tagging.

  • Updating whiteboards tags through the API is non-trivial
  • There is no global auto-suggest for whiteboard tags
  • There is no verification of whiteboard tags; typos will not be caught and prevented
  • Renaming a whiteboard tag requires writing a script to update every bug with that tag, changing its last modified timestamp and generating bugmail; other solutions involve a simple change by administrators
  • Whiteboard tags cannot be disabled; people might continue to provide them after they are no longer relevant thinking they still apply
  • If desired it's possible to restrict who can set flags to particular values; it will never be possible to prevent accidental or other changes to the whiteboard from any user with editbugs or the bug's reporter

Consider using a keyword, a flag, or a status flag. You can request this on Bugzilla.

Contributor mentoring

For more information, see Mentors.

  • [lang=]: The programming language involved for this bug.
  • [mentor-lang=]: (human/natural) language other than English the mentor will be able to communicate to the contributor with.

Automated Testing

  • [test disabled]: Indicates an automated test has been disabled. Typically used in bugs filed for intermittent test failures, to indicate that the absence of new failures in the bug is due to the test being disabled - as well as remind module owners that the test needs fixing and re-enabling.


[no-nag]: Indicates that a bug should not be modified or commented in by our Autonag scripts.

Release Engineering

  • [capacity]: This bug will help increase (or free up) capacity for our automated build & test machines.


  • [leave open]: This has been deprecated in favour of the 'leave-open' keyword. Used to ensure that the bug updating tool mcMerge does not close the bug when commits referencing it are merged into mozilla-central.
  • [retriggered]: Used by sheriffs when investigating Fresh Oranges [1] to find where a failure started from, using backfills and retriggers


  • dupeme, dupme, or DUPEME: we're pretty sure this bug report is a duplicate of another bug, but cannot recall which one or cannot find it.
  • [qa-]: QE (Quality Engineering) verification not required - superseded by the qe-verify flag.
  • [adv-mainNN+] (where NN is some number): a security advisory about this bug for the release NN will be (has been) written.
  • [MemShrink]: a project to reduce memory consumption.

Community reported bugs

  • [nightly-community]: This bug was reported by a member of the Firefox Nightly community. Used to triage community-reported bugs and measure the impact of our core community on product quality.
  • [mozfr-community]: This bug was reported by a member of the MozFR French-speaking community. Used to evaluate the impact of the community on product quality.

Firefox OS

Template:Note: This project is no longer active, but we leave these definitions for bug tracker historian purposes

  • [POVB]: Part of vendor build; the fix of this bug is not in the Mozilla codebase, but it's in our interest to track it.
  • [priority]: Indicates we are asked by a partner to address this issue with priority.
  • [tarako_only]: Special pref or feature that only lands on branch for Tarako (low memory phone), i.e. 1.3T branch of Gaia and Gecko. To be picked up on future releases.
  • [p=]/[u=]/[c=]/[s=]: See Scrum Development. Firefox OS uses the u= tag as the milestone instead, see Firefox OS Performance Triage
  • [ft:<name of the team>], [systemsfe], etc: Bugs identified to be owned by a "functional team" within B2G engineering. Each team owns a specific set of Bugzilla components, and tags are used to denote owned bugs outside of these components.


Web Compatibility

Our whiteboard keywords are already described.

Scrum Development

The following flags are used by tools like for managing sprints using the scrum development framework:

  • [p=]: A rough estimate from engineer on how long the bug is going to take.
  • [u=]: The user (in the scrum sense) that this story affects
  • [c=]: The component (in the scrum sense) that this story affects
  • [s=]: An explicit sprint slug this bug should belong to.

If you are not managing a product, you probably don't have to set these.

What does this whiteboard keyword mean?

If you know what one of the following whiteboard keywords means, please describe it and put it into one of the above categories above (or create a new one):