Bug triage: Difference between revisions
From MoodleDocs
Helen Foster (talk | contribs) (major rewrite following discussions with Eloy) |
Helen Foster (talk | contribs) (→The triage process: rewording and adding further Eloy wisdom) |
||
| Line 11: | Line 11: | ||
===Step 1 - Issue details check=== | ===Step 1 - Issue details check=== | ||
* | # Check whether the issue has been reported previously | ||
* | # Check and amend as necessary: | ||
#* Issue summary and description | |||
#* Priority (see below) | |||
#* Components | |||
#* Assignee - component lead, otherwise developer currently assigned to most issues for that component (click on the component link and it will show current assignees and then click on "resolved" to see who has been working on it recently) | |||
# If necessary, request more information, such as debug messages for errors | |||
# If applicable, for example the issue covers more than one component, add watchers | |||
Notes on selecting the appropriate priority: | |||
* Anything causing error/exception is a blocker | |||
* Improvements/new features cannot be blockers (in triaging process, though the dev team can raise them later) | |||
===Step 2 - Setting a fix version=== | ===Step 2 - Setting a fix version=== | ||
* If the issue is a bug in the current stable version (eg 2.0), assign "Fix version" | * If the issue is a bug in the current stable version (eg 2.0), assign "Fix version" to STABLE backlog | ||
* If the issue is related to backup and restore, assign "Fix version" to | * If the issue is related to backup and restore, assign "Fix version" to STABLE backlog with high priority | ||
* If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to | * If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEV backlog | ||
* If the issue is a feature request, assign "Fix version" to | * If the issue is a feature request, assign "Fix version" to DEV backlog | ||
(List copied from [[Process]]) | (List copied from [[Process]]) | ||
Issues are then labelled ''triaged'' to indicate that step 1 and 2 have been completed. | Issues are then labelled ''triaged'' to indicate that step 1 and 2 have been completed and a comment added explaining the reason for any changes, for example | ||
* "Setting a fix version of DEV backlog so that we consider including the feature in 2.1." | |||
==Triage filter== | ==Triage filter== | ||
Revision as of 15:58, 10 December 2010
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. It should help ensure we appropriately manage all reported issues - bugs as well as improvements and feature requests.
The triage process
Step 1 - Issue details check
- Check whether the issue has been reported previously
- Check and amend as necessary:
- Issue summary and description
- Priority (see below)
- Components
- Assignee - component lead, otherwise developer currently assigned to most issues for that component (click on the component link and it will show current assignees and then click on "resolved" to see who has been working on it recently)
- If necessary, request more information, such as debug messages for errors
- If applicable, for example the issue covers more than one component, add watchers
Notes on selecting the appropriate priority:
- Anything causing error/exception is a blocker
- Improvements/new features cannot be blockers (in triaging process, though the dev team can raise them later)
Step 2 - Setting a fix version
- If the issue is a bug in the current stable version (eg 2.0), assign "Fix version" to STABLE backlog
- If the issue is related to backup and restore, assign "Fix version" to STABLE backlog with high priority
- If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEV backlog
- If the issue is a feature request, assign "Fix version" to DEV backlog
(List copied from Process)
Issues are then labelled triaged to indicate that step 1 and 2 have been completed and a comment added explaining the reason for any changes, for example
- "Setting a fix version of DEV backlog so that we consider including the feature in 2.1."
Triage filter
The filter To triage (Moodle-all) includes:
- Issues with assignee to review (empty/nobody/moodle.com)
- Issues with fix version empty or set to some released version
- Issues not included in a backlog and not yet labelled as triaged
Triaging priorities
- Recent bugs
- By priority - aim for blockers and critical issues to be reduced to 0
- DEV sprint - focus on components of interest (currently forumng, survey, lesson and gradebook)
