Contribute/Coding/FilingGoodBugs

Filing Good Bugs

This page is intended to describe what makes a good bug, how to file one, and how to help follow it through to resolution.

It is rooted in the idea that bug triage is a lot more than getting the bug into the right component. A bug is a request for a domain expert's time, expertise and commitment; triage is an expression of shared interest in solving the bug and improving the product.

Effective triage takes a bug from "a user discovers an issue" to "an actionable decision can be made by an engineer", and that actionable state depends on a good understanding of the bug even before the decision to investigate it is made; how the bug happened, whether or not it's reproducible, when the bug was introduced and on which platform, among other things. With that in mind, filing a good bug starts us off as close to that actionable state as possible.

Context Is Everything

The more we understand about a bug's context the better. Essential information includes:

• What happened? How was that different than what you expected?
• What were you doing or trying to accomplish at the time?
• What operating system are you using, and what hardware?
• What steps can you take to reproduce the issue? And, finally
• Did this work in a previous version of Firefox? If so, which version?

A clear explanation of difference between "what was expected" and "what happened" will go a long way, even if it is no more complicated than "I expected it not to crash and it did."

Very Nice To Have

• Filing the bug in the correct category. This is very important, the first step in ensuring your bug will be seen by the responsible engineer or team.
• Steps To Reproduce the bug. These are extremely helpful.
• Using these steps to produce a Regression Range, even more so.
• Crash IDs from About:Crashes.

If STRs or an RR are not available but would be useful, selecting the appropriate choice from the "Has STRs" and "Has Regression Range" menus in Bugzilla will bring this bug to the attention of the community. Attaching crash signatures from About:Crashes also helps us to isolate and understand these bugs.

Following Up

We know for a fact that the best predictor that a bug will be fixed is whether or not it ends up getting triaged into the right category on the first try. Likewise, we know that the best predictor of a long, successful working relationship with contributors is that people get back to each other's questions, comments and patch submissions within a day. Engineers will do their best to hold to that standard, and we hope that if somebody has questions about the bug you've filed, that you'll be able to as well.

Thank you

Putting the effort into a high-quality bug report goes a long way to getting your bug fixed. Mozilla is grateful for your effort, and for your continued support.