Fuel/BugTriage

These are the bug triaging tasks, in descending order of priority. Some tasks are accessible to everyone, while some others require bug supervisor rights (usually limited to core teams). Before you start triaging, please learn everything on how we use Bugs !

Task 1: Confirm new bugs (anyone)
When someone files a bug, its state is set to New. The most important step in bug triaging is to provide feedback on that bug and make sure it's a genuine bug.

bugs list, bugs graph


 * If the bug description is incomplete or the report is lacking the information necessary to reproduce the issue, you should ask the reporter to provide missing information, and set the bug status to Incomplete
 * If the bug report contains enough information, you can reproduce it (or it looks valid), then you should set its status to Confirmed
 * If the bug has security implications, you should set the security flag (under "This report is public" on the top right)
 * If the bug affects a specific area covered by an official tag, you should set the tag. For example, if the bug is likely to be quite easy to solve, add the low-hanging-fruit tag

While they are at it, people with bug supervisors rights can complete task 2 for the same bug.

Task 2: Prioritize confirmed and triaged bugs (bug supervisors)
When someone files a bug, its importance is set to Undecided. Setting importance is pretty critical as it allows to prioritize all the rest of the work correctly.

bugs list, bugs graph


 * Based on the bug information, set priority to:
 * Critical if the bug prevents a key feature from working properly (regression) for all users (or without a simple workaround) or result in data loss
 * High if the bug prevents a key feature from working properly for some users (or with a workaround)
 * Medium if the bug prevents a secondary feature from working properly
 * Low if the bug is mostly cosmetic
 * Wishlist if the bug is not really a bug, but rather a welcome change in behavior
 * If the bug contains the solution, or a patch, set the bug status to Triaged

Task 3: Solve inconsistencies (anyone)
Some bugs might end up in an incorrect state. You should fix:

New bugs with a priority set
Status should be set to Confirmed (or In progress if an assignee is set):

bugs list

In progress bugs without an assignee
An assignee should bet set, or the bug should return to Confirmed status:

bugs list

Task 4: Review incomplete bugs (anyone)
Incomplete bugs should be reassessed regularly.

bugs list


 * If the reporter provided the requested answer: bug status should be set to Confirmed
 * If the reporter did provide information, but more detail is required: ask for missing information
 * If the reporter did not answer within 2 weeks: Politely remind the reporter to provide missing information, for example:

We cannot solve the issue you reported without more information. Could you please provide the requested information ?


 * If the reporter did not answer the reminder for another 4 weeks: Set the bug status to Invalid with a comment, for example:

This bug lacks the necessary information to effectively reproduce and fix it, therefore it has been closed. Feel free to reopen the bug by providing the requested information and set the bug status back to New.

Task 5: Review stale In Progress bugs (anyone)
Make sure In Progress bugs are actually in progress. Unassign them and set them back to Confirmed or Triaged if not.

bugs list

Task 6: Review bugs with a patch (bug supervisors)
Some bugs are filed with an attached patch. We should review if the patch looks indeed like a patch, and if yes, set the bug status to Triaged to show that it comes with a likely solution, ready to be implemented.

bugs list

Task 7: Review Critical/High bugs (bug supervisors)
We should review all Critical and High bugs to make sure they are still relevant and properly prioritized.

bugs list, bugs graph

Task 8: Review Medium/Low bugs (bug supervisors)
We should review all Medium and Low bugs to make sure they are still relevant and properly prioritized.

bugs list

Task 9: Deprecate old wishlist bugs (bug supervisors)
We should review all Wishlist bugs to make sure they are still relevant. Old wishlist bugs (created more than a year ago) should be reviewed to see if they were not accidentally implemented or improperly prioritized. If they really are wishlist items that nobody seems to be interested in implementing, they can be closed as "Opinion" to reduce bug list clutter. You can use the following message:

This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on. This bug can be reopened (set back to "New") if someone decides to work on this.

bugs list

Task 10: Celebrate!
If you've reached this step, have a beer, it's on me.