Bug triage: Difference between revisions
Helen Foster (talk | contribs) (issue details check, fix version decision) |
Helen Foster (talk | contribs) (→Issue details check: rewording) |
||
| Line 18: | Line 18: | ||
==Issue details check== | ==Issue details check== | ||
Each tracker issue must be in a | Each tracker issue must be in a fit state, so that an informed decision can be made about it. | ||
*Does the summary accurately reflect the issue? | *Does the summary accurately reflect the issue? | ||
* | *Can the bug be reproduced? If not, a comment should be added requesting more information, perhaps recommending that the reporter enables [[Debugging|debugging]] then posts any extra error messages displayed or a screenshot. | ||
* | *Is the priority set correctly? | ||
:''Blocker'' - Blocks development and/or testing work, production could not run. | |||
:''Critical'' - Crashes, loss of data, severe memory leak. | |||
:''Major'' - Major loss of function. | |||
:''Minor'' - Minor loss of function, or other problem where easy workaround is available. | |||
:''Trivial'' - Cosmetic problem like misspelled words or misaligned text. | |||
*Are the other fields such as security level and component(s) completed correctly? | |||
Action points: | Action points: | ||
Revision as of 12:04, 3 September 2009
Note: This page is for analysing and developing a bug triage process. It is a work-in-progress. Comments or suggestions are welcome! Please use the page comments.
Triage is medical term referring to the process of prioritizing patients based on the severity of their condition so as to maximise benefit (help as many as possible) when resources are limited.
Bug triage is a process where tracker issues are sorted and categorised with the intent of maximising benefit to Moodle given limited resources. It should help us act on those issues that require immediate attention (e.g. high priority, affects most users, is a security issue) while relegating issues deemed less critical to a lessor status, to be actioned at a later date.
Bug triage should help ensure we appropriately manage all reported issues - bugs as well as improvements and feature requests.
Bug triage may be broken down into two steps:
- Issue details check
- Fix version decision
The primary benefit of a two-step process is to allocate resources appropriately: developers with greater knowledge of Moodle can focus on step 2 whilst those with less knowledge can focus on step 1 (whilst hopefully building knowledge).
Issue details check
Each tracker issue must be in a fit state, so that an informed decision can be made about it.
- Does the summary accurately reflect the issue?
- Can the bug be reproduced? If not, a comment should be added requesting more information, perhaps recommending that the reporter enables debugging then posts any extra error messages displayed or a screenshot.
- Is the priority set correctly?
- Blocker - Blocks development and/or testing work, production could not run.
- Critical - Crashes, loss of data, severe memory leak.
- Major - Major loss of function.
- Minor - Minor loss of function, or other problem where easy workaround is available.
- Trivial - Cosmetic problem like misspelled words or misaligned text.
- Are the other fields such as security level and component(s) completed correctly?
Action points:
- Identify a filter to ensure every new issue is reviewed on a periodic basis.
- Identify a person/team to check issue details.
- Identify a way of determining when an issue has been checked.
Fix version decision
Description...
Action point:
- Identify a person/team with sufficient knowledge to decide upon the assignee and fix version.
Triage filters
- Recent unresolved bugs that need triage - These bugs need checking to make sure they are assigned to the right person, category etc.
- 1.9.x Reported (Need Triage) - These are bugs that are reported as being in 1.9 stable branch but appear not to be fixed yet. They need to be looked at and given a fix version or closed. Note that many of these may not be relevant, or may be miscategorised, so they need to be processed.
Fix versions
Bugs are removed from the triage list by giving them a fix version or closing them. Confirmed bugs should be given the next unreleased version as the fix version, for example a confirmed bug in 1.9 should have a 1.9.1 fix version.
Adding watchers
If assistance is required with a bug, additional watchers may be added then a comment added. If documentation is required, Helen should be added as a watcher, then a comment saying "this requires documentation" added.
