These are the bug triaging tasks, in descending order of priority. Some tasks are accessible to everyone, while some others require bug supervisor rights (limited to the bug supervisors team). Before you start triaging, please learn everything on how we use Bugs !
- 1 Some notes
- 2 Task 1: Confirm new bugs (anyone)
- 3 Task 2: Prioritize confirmed and triaged bugs (bug supervisors)
- 4 Task 3: Solve inconsistencies (anyone)
- 5 Task 4: Review incomplete bugs (anyone)
- 6 Task 5: Review stale In Progress bugs (anyone)
- 7 Task 6: Review bugs with a patch (bug supervisors)
- 8 Task 7: Review Critical/High bugs (bug supervisors)
- 9 Task 8: Review Medium/Low bugs (bug supervisors)
- 10 Task 9: Deprecate old wishlist bugs (bug supervisors)
- 11 Task 10: Celebrate!
- it's preferred to prepend all bug titles with the following 'tags':
- [EDP] for EDP related stuff
- [UI] for OpenStack Dashboard plugin code
- [Vanilla] for Vanilla plugin code
- [HDP] for Hortonworks Data Platform plugin code
- [Doc] for documents needs to be updated
- [DIB] for Diskimage-builder code in sahara-image-elements repo
- [python-saharaclient] for... ok... you've got the idea
If bug affects more than one areas you can mix tags. Example.
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.
- 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.
- 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):
In progress bugs without an assignee
An assignee should bet set, or the bug should return to Confirmed status:
In progress bugs without a priority set
It's better to have priority set for "In progress" bugs:
Task 4: Review incomplete bugs (anyone)
Incomplete bugs should be reassessed regularly.
- 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.
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.
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.
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.
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.
Task 10: Celebrate!
If you've reached this step, have a beer, it's on me.