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.

Bugmastering is a perfect gateway into open source involvement and can lead you toward any number of goals as you build your skills. It may lead you to work on code and submit patches. In fact, some of our top coders began as bugmasters. Or you may find that you prefer working with the quality team to help resolve Firefox crashes and run complex tests on Mozilla's products. Perhaps you'll decide to work more closely with the other first-time users as a user advocate – or as a long term bugmaster. Whatever you choose, bugmastering is a great first step to allow you to meet the people that power the Mozilla project and learn the ropes to accelerate your involvement.

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 tasks

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 marked in the whiteboard field as qawanted or testcaseneeded.
• 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 commented on, triaged, 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.

Finding and filing bugs

If you would like to hunt for bugs, QA has information on running Nightly builds and doing software testing.

If you've found a bug and want to report it, read How to File a Bug.

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.
• Start looking at the code and commit logs. Here is a good story with pointers to practical ways to approach Bugzilla and the code base: http://www.joshmatthews.net/blog/2010/03/getting-involve-with-mozilla/

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
• Bugzilla keywords: https://bugzilla.mozilla.org/describekeywords.cgi

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: QA's page, 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. Also, B2G Triage meeting notes from the B2G team.

• Mobile: https://wiki.mozilla.org/Mobile/Triage/
• WebRT: https://wiki.mozilla.org/Mobile/Triage/WebRT

• FirefoxOS triage for blocker bugs (slides) http://prezi.com/hgwp6xx2mmc5/firefox-os-qa-process/

• DevTools triage: https://wiki.mozilla.org/DevTools/Triage
  • Process: P1 = blocking others, very important, P2 = important, P3 = valuable, can wait
  • P1 and 2 have to have an assignee
  • Bugs without a priority need triaging to get one assigned.

• 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

• The GFX meetings every 2nd Monday do urgent triage of Layout, GFX, and Media bugs. Example: https://wiki.mozilla.org/Platform/GFX/2013-May-6

• 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)

• Mozilla Reps planning team: https://remo.etherpad.mozilla.org/planningtriage

• Core modules listed with explanations and links.

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/#
• Axel Hecht's B2G triage dashboards:
  • Late l10n triage: http://pike.github.io/late-l10n-triage/
  • Firefox Beta Bug Activity: http://pike.github.io/beta-dash/
• Atul Varma's Bugzilla dashboards
  • https://github.com/toolness/bugzilla-dashboard

Some Bugmastering communities

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

• Bugsquad GNOME's Bugsquad community.
• Bug Wranglers Gentoo bug wrangler community.
• WikiMedia's bug triage pages.
• WordPress: http://make.wordpress.org/core/handbook/bug-gardening/
• Joomla: http://docs.joomla.org/Bug_Squad