Confirmed users
1,094
edits
Sescalante (talk | contribs) m (→Product Backlog: update query) |
Sescalante (talk | contribs) m (→Triage Guidelines: updated) |
||
Line 18: | Line 18: | ||
===Triage Guidelines=== | ===Triage Guidelines=== | ||
The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting. | The Product Backlog is continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting. | ||
* Priorities | * Priorities: if you are filing a bug - based on your knowledge of the bug feel free to set a priority for consideration based on the following criteria: | ||
** Priority 1 - Blocker, must-fix before shipping. | ** Priority 1 - Blocker, must-fix before shipping in the next release. | ||
** Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping. | ** Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping. | ||
** Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product. | ** Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product. | ||
Line 25: | Line 25: | ||
** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability. | ** Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability. | ||
*RANK: As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value. | *RANK: Not needed when filing a bug, set during weekly Triage meetings. As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value. | ||
** P1 Rank options=1-19, default 15 | ** P1 Rank options=1-19, default 15 | ||
** P2 Rank options=20-29, default 25 | ** P2 Rank options=20-29, default 25 | ||
Line 31: | Line 31: | ||
** P4 Rank options=40-49, default 45 | ** P4 Rank options=40-49, default 45 | ||
** P5 Rank options=50-59, default 55 | ** P5 Rank options=50-59, default 55 | ||
** any that we don't think we can get to in the next 6 months should | ** any that we don't think we can get to in the next 6 months should be set to 100 | ||
<p> </p> | <p> </p> | ||
Line 39: | Line 39: | ||
***Typically goes with in-testsuite set to "+", to show testing via another method. | ***Typically goes with in-testsuite set to "+", to show testing via another method. | ||
*"Points" should be set when known (if nothing set - assumed a "1" or very small). Most relevant if taking a bigger bug so we know when bugs are large bits of work. | *"Points" should be set when known (if nothing set - assumed a "1" or very small). Most relevant if taking a bigger bug so we know when bugs are large bits of work. | ||
*"Iteration" should be updated when a bug is being worked on during a particular Sprint. | *"Iteration" should be updated when a bug is being worked on during a particular Sprint. | ||
===Filing a bug=== | ===Filing a bug=== |