User:Tyler/Triage Guidelines
Contents
General Principles
The purpose of Triage is two-fold:
- To ensure that bugs are properly filed, and have enough information for developers to take action on. Also confirm bugs as needed and assist QA.
- Provide a Friendly face to the scary world of BMO for End-users. Empower them to follow up with the proper information needed for their bug.
I have tried to cover the most common triage scenarios. However, there are many other cases that I can't cover. Keep in mind that reporters are usually just end-users who want to help improve the product they use every day. They don't have to report bugs, and Triage needs to keep a professional and friendly face. Even if you are not a Mozilla employee, your actions and words influence people's perception of Mozilla. Our goal is to empower users and help them as they need it, not to make them feel inferior.
- Always tell a user what they need to do next and give them places to look for help if they need it. Instead of saying "can you give a stacktrace", say "Can you please type about:crashes into your address bar, and copy and paste the crash ids there into this bug report". Never give an ambiguous comment. Make sure to follow Bugzilla Etiquette at all times.
- Never make a reporter feel unappreciated. They took their time to report a bug and didn't have to. Even if their bug is INVALID, don't bash them for it.
- Grow a thick skin. Don't get into a shouting match, it doesn't help anybody. If you feel like some moderation needs to occur, contact the right people to ensure that happens.
Extension Bugs
A bug that is actually caused by an extension, or a bug in an extension, is generally INVALID. For example "Google Toolbar button does not work properly" or "Installing Download Helper causes back button to stop working". These bugs should be moved to the Firefox:Extension Compatibility component (for Firefox Bugs), and a whiteboard tag such as [Caused by Google Toolbar] should be added. An explanation should also be given to the bug saying why the bug is INVALID and what the next steps the reporter should do are.
For example, "This bug is caused by the Google Toolbar, and needs to be fixed by their developers. Please contact them and hopefully they will take action on this issue. You can find their support page at www.....". Giving a friendly reply helps show users that while they are having a real bug, it is not in Firefox. Telling them where to go helps them know we are not just brushing their issue off and passing the buck.
There are bugs related to extensions that can be legitimate bugs in a Mozilla product. Some crash bugs are caused by extensions for example. If there is any doubt about the issue, CC a developer onto the bug and ask for their input.
Support Bugs
If a user files a bug that can quickly be identified as a Support Issue (eg. "How do I change my Home Page") and the issue isn't caused by a bug (eg. A Regression that causes Firefox to revert the home page to Default"), then the bug should be closed as RESOLVED INVALID, and the user should be directed to SUMO. If there is an easy answer to their question, feel free to provide it, but BMO is not the place for Support. SUMO is a better environment for End-User support, and answered questions are a resource for the SUMO community.
Don't belittle a user for submitting a Support Issue to BMO, as many users have a hard time differentiating between Bugs and Support problems. Remember to remain polite and professional.
Resolving Bugs as INCOMPLETE
There are two uses for RESOLVED>INCOMPLETE.
- When a bug is filed with very little or no information.
E.g. "My Gmail doesn't load properly"
Most bugs should not be closed as INCOMPLETE immediately. The Triager should ask for more information, and possibly place a CLOSEME tag in the whiteboard, but a chance should be given the reporter to respond without immediately closing the bug. By closing a bug immediately, reporters tend to get discouraged and feel that their contribution was not appreciated. Instead, method 2 should be used.
- Place a CLOSEME tag in the whiteboard of the bug, and a comment asking for more information. The comment should be informative, and give specific information on what is being requested.
Bad Example: "Reporter, any updates on this bug?"
Good Example: "Reporter, can you please try to reproduce this bug with version X of Firefox or later. When you test it, can you try using a fresh, unmodified profile (link to profile help page). Also, make sure that your plugins like Flash, Reader, Java, etc. are all updated. Please update your graphics drivers and operating system as well. After retesting, post a comment on here with the results."
Using friendly explanations and asking for specific things to be done helps a user feel like they are not wasting their time, and is much nicer sounding.
After the date marked in the CLOSEME tag has passed, come back and mark the bug as RESOLVED>INCOMPLETE. When doing so, again leave a friendly comment asking the user to reproduce the issue using updated software and post their results.
The CLOSEME Tag
When preparing to close a bug as INCOMPLETE, it is important to place a CLOSEME tag in the whiteboard of the bug. This way, other triagers know that the bug is waiting for a reply, and bugs with past dates can be closed using simple queries. The typical format of CLOSEME tags is [CLOSEME YYYY-MM-DD]. A CLOSEME should specify a date at least 3 weeks in advance, except in special cases. Once a bug is closed as INCOMPLETE, please keep the CLOSEME tag for tracking purposes.
Resolutions
INVALID
Use INVALID when the reporter reported a bug that is not a bug in Firefox. For example, an extension bug, an issue where the reporter modified a pref and was just seeing the expected behavior without knowing it, etc. While closing the bug, give an explanation of why the Bug is INVALID. remember the user will likely be confused without an explanation, because the issue is very valid to them. Without an explanation they may feel that reporting to Mozilla just results in getting brushed off.
INCOMPLETE
As said above, do not close a bug as INCOMPLETE without giving a reporter ample time to reply, at least three weeks is what I recommend.
