Bugzilla

The following information applies to the addons.mozilla.org product of bugzilla.mozilla.org.

Priorities

We prioritize bugs in milestones on the following scale:

• P1 - Highest priority. These bugs are goals for the quarter or release and will always block release.
• P2 - High priority. These bugs are important and usually block release.
• P3 - Medium priority. These are wanted for the release but don't block.
• P4 - Low priority. These are nice-to-haves and should be done after higher priority bugs if time permits.
• P5 - Lowest priority. These bugs are of trivial priority and should only be done after all other bugs in the milestone.

P5 bugs in the current development milestone are more important than P1 bugs in the next development milestone. Low priority bugs that are repeatedly bumped from milestone to milestone are likely to have their priority raised.

Target Milestones

We regularly triage bugs for upcoming milestones and assign them. If you'd like a bug to be considered for a milestone, place it in the milestone prior to triage and leave it unassigned. The current milestone should not be used as a bug dumping ground; only bugs that need to be fixed in the current milestone should be placed there. Unassigned bugs in the current milestone are triaged and assigned throughout the release.

Status Whiteboard

The following status whiteboards are often used within AMO/Marketplace:

• [ddn] - Design Decision Needed. Flag for Product/Design to comment on a design issue or determine whether a bug should be WONTFIXed.
• [tdn] - Technical Decision Needed. Flag for Development to determine whether a technical bug should be implemented or WONTFIXed.
• [good first bug] - an easy bug for a new contributor to pick up
• [qa+] - Bug needs extra QA. Should be used for changes that have potential for wide impact.
• [qa-] - Bug does not need QA. Should be used for administrative requests.
• [clint eastwood] - Bug is good for someone learning the code base (like a new hire). Like our squinty-eyed hero, it keeps to itself and doesn't have a lot of friends. It's self contained and avoids touching large portions of code so chances of conflicts are low while someone takes their time to figure things out. Pretty much used by clouserw exclusively.

These are deprecated:

• [z] - bug applies to Zamboni (Python) code (optional)
• [r] - bug applies to Remora (PHP) code (optional)

Keywords

• push-needed - Bug is fixed on trunk but requires a site update to show up.
• regression - An existing feature that worked fine no longer works the same way.

Misc.

• Always set the platform and OS to "All" unless the issue really is platform-specific.

Following Along

We use fake QA contacts so that it's easy to get emails about changes to components that you're interested in.

You can watch users/QA contacts by going to User Preferences and adding the e-mail addresses at the bottom.

You can select which components above that you'd like to watch, or copy/paste this list to watch all of them:

   security@add-ons.bugs,admin-tools@add-ons.bugs,administration@add-ons.bugs,api@add-ons.bugs,blocklisting@add-ons.bugs,code-quality@add-ons.bugs,collections@add-ons.bugs,collector-extension@add-ons.bugs,compatibility@add-ons.bugs,developers@add-ons.bugs,dictionaries@add-ons.bugs,discoverypane@add-ons.bugs,facebook@add-ons.bugs,forums@add-ons.bugs,l10n@add-ons.bugs,maintenance@add-ons.bugs,plugin-listings@add-ons.bugs,policy@add-ons.bugs,web-ui@add-ons.bugs,search@add-ons.bugs,search-plugins@add-ons.bugs,statistics@add-ons.bugs