Bugmasters/Guide

Welcome, bugmasters! Managing and sorting bugs, or "triaging" can mean many different things to different people and teams. Here are some paths to contribution.

This page is a rough draft; please help improve it!

Starting up as a bugmaster

• Make a bugzilla.mozilla.org account, and confirm it through email.
• Read the bug writing guidelines, which has best practices for bug reports.
• Join us in the irc channel on #bugmasters and introduce yourself. We can help get you started.
• Take a look at some Bugzilla bug lists and individual bugs.
• Download and install the latest nightly build for the product you're testing (e.g. Firefox Nightly).
• Set up a testing profile for that product, separate from any work or personal profiles you use.
• Become familiar with examples of common responses to newly filed bugs.
• Become familiar with Bugzilla QuickSearch.

Beginning bugmastering

If you're new to bugmastering, it will be easiest to tackle early bug triage and tasks such as:

• Very old bugs that are likely to be already fixed or no longer relevant. Find them and close them, or request more information and tag them "closeme".
• Website bugs that are relatively easy to confirm. (Broken links and so on.)
• Bugs marked in the whiteboard field as dupeme or closeme.
• Bugs in your particular field of expertise.
• Incoming, untriaged bugs.
  • Bugs reported in the last 24 hours
  • Report for Firefox untriaged bugs that are UNCONFIRMED and where the bug reporter is the last commenter.

Note that the best way to get started though is to join us on #bugmasters on IRC and we can work with you.

These are some good ways to test the waters.

Over time, beginning bugmasters will build up more and more knowledge about how to move bugs from one part of their life cycle to another. As the bugmaster community grows it will be crucial for us to listen to feedback from people with all levels of experience, so we can improve how we work. Please help to improve this page and other documentation!

Advanced bugmastery

• Ask for canconfirm permissions if you have edited or filed at least three bugs that are in good shape.
• Email to ask for editbugs permissions if you find you need to change a field (such as the title) in several bugs, but could not, and had to make the change in comments instead.

Branching out as an expert bugmaster

Here are some possible ways to dive deeper into bug triage and management. Please add more to this list as we evolve the bugmaster pages!

• Pick a product or component to specialize in.
• Read its related wiki.mozilla.org pages and MDN pages.
• Join IRC channels for that area.
• Become familiar with the module owners and peers.
• Set up bugmail folders and filters to watch your bugmaster specialty.
• Tag "good first triage" bugs with the whiteboard tag easytriage.

More links on triaging and managing bugs

Miscellaneous documentation and triage instructions, useful for bugmasters. We'll use these to help us overhaul the general triaging and bug workflow.

Bugzilla docs

• How to create a good first bug report Wikimedia post on making good bugs.
• Confirming unconfirmed bugs from MDN
• Bugzilla etiquette from BMO
• What to do and what not to do in Bugzilla from MDN
• Bug writing guidelines
• How to write a proper bug from QMO
• How to write a proper bug part 2 from QMO

Triage docs

• Module owners
• Doing Investigation For support questions, but often useful for bug triage.
• QA/Triage  from 2008/2010
• Bug Guidelines QA guide for crash bugs.
• Triage guidelines by Tyler
• BMO Survival Another great writeup by Tyler
• Confirming unconfirmed bugs from MDN
• Reducing testcases from MDN
• Bug verification days Mondays in #qa are bug verification days for Firefox Desktop fixed bugs (near end of lifecycle)
• Softvision triage process

Triage docs for specific teams or modules

• Triaging crash bugs. Tackle bugs that may have caused a crash. Learn how to find crash bugs, add complete steps to reproduce, a stack trace, and a reduced testcase for a crash bug, then tag it for a developer to review. The CraskKill team triage notes may be helpful.

• B2G Triage: https://wiki.mozilla.org/B2G/QA/Triage with a list of keywords agreed on by the B2G team and QA. B2G developers use keywords to tag bugs with steps-wanted, testcase-wanted, regressionwindow-wanted, verifyme, and qawanted.

• Firefox Triage days (tuesday) https://etherpad.mozilla.org/firefox-triage Backchannel: #fx-team

• Triaging within a team, for example the SDK/ Jetpack team's triage meetings. https://wiki.mozilla.org/Jetpack/Triage_Process

• Triaging networking bugs. An explanation of the networking components, whiteboard tags, and other processes used for triaging by developers in this area of Mozilla.

• Confirming unconfirmed bugs  (this page is a bit out of date)

Tools and Custom Dashboards

• Heather Arthur's Bugzilla to-do list by user: http://harthur.github.com/bugzilla-todos/
• David Teller's dashboard for managing mentored bugs: http://yoric.github.com/bugzilla-dashboard/#username=dteller@mozilla.com&mentorname=Yoric
• Stefan Arentz's dashboards:
  • https://people.mozilla.com/~sarentz/p/kickoff/#
  • https://people.mozilla.com/~sarentz/p/websecbugs/#

Some Bugmastering communities

Here are a few other FLOSS projects that have bug-focused communities.

• Bugsquad GNOME's Bugsquad community.
• Bug Wranglers Gentoo bug wrangler community.
• WikiMedia's bug triage pages.