Development:Bug triage: Difference between revisions
mNo edit summary |
|||
(18 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
This page is for analysing and developing a | <p class="note">'''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 [[{{TALKPAGENAME}}|page comments]].</p> | ||
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. | 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== | |||
== | ===General=== | ||
* Has the issue been reported previously? | |||
Duplicate issues should be closed with no fix version set. | |||
* | * Are the correct components selected? | ||
* | * If necessary, request more information, such as debug messages for errors | ||
* | * If applicable, for example the issue covers more than one component, add watchers | ||
===Priority=== | |||
* Security issues and anything breaking badly (error/exception) => blocker | |||
* Anything leading to wrong results => critical | |||
* Anything else => major (apart from minor/trivial tweaks) | |||
Note: Improvements/new features cannot be blockers (in triaging process, though the dev team can raise them later) | |||
== | ===Assignee=== | ||
* Generally be the main component lead | |||
* Otherwise the 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) | |||
* Otherwise leave as moodle.com (for the team to grab later as the sprint progresses) | |||
== | ===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 | |||
If the issue already has a fix version set by the component lead, it should be left unchanged. | |||
For meta issues, the fix version may be set as 2.x, as generally only subtasks of meta issues are included in sprints. | |||
===Labels=== | |||
Issues are labelled ''triaged'' to indicate that all the above points have been covered. A comment may be added explaining the reason for any changes. | |||
Issues with proposed fixes are labelled ''patch'' so that they can be found easily and given attention. | |||
==Triage filter== | |||
The filter [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=11424 To triage (Moodle-all)] includes: | |||
* Issues with assignee to review (empty/nobody/moodle.com without triage label) | |||
* 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== | |||
# By priority - aim for blockers and critical issues to be reduced to 0 | |||
# Recent bugs | |||
# Whatever is of special interest at a given time e.g. for DEV sprint forumng, survey, lesson and gradebook | |||
Example query for searching for performance-related issues: | |||
project = "Moodle" AND | |||
status in (open, reopened, "In Progress") AND | |||
"Affected Branches" ~ "MOODLE_20_STABLE" AND ( | |||
component in (Performance) OR | |||
labels in ("performance") OR | |||
text ~ slow OR | |||
text ~ speed OR | |||
text ~ performance OR | |||
text ~ profiling OR | |||
text ~ benefit OR | |||
text ~ throughput) | |||
ORDER by priority desc | |||
==See also== | |||
*[[Tracker]] | |||
*[[Development:Process]] | |||
*[[Development:Weekly Code Review]] | |||
*[[Development talk:Bug triage]] | |||
[[Category:Developer|Bug triage]] | |||
[[Category:Quality Assurance]] |
Latest revision as of 13:47, 16 February 2011
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
General
- Has the issue been reported previously?
Duplicate issues should be closed with no fix version set.
- Are the correct components selected?
- If necessary, request more information, such as debug messages for errors
- If applicable, for example the issue covers more than one component, add watchers
Priority
- Security issues and anything breaking badly (error/exception) => blocker
- Anything leading to wrong results => critical
- Anything else => major (apart from minor/trivial tweaks)
Note: Improvements/new features cannot be blockers (in triaging process, though the dev team can raise them later)
Assignee
- Generally be the main component lead
- Otherwise the 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)
- Otherwise leave as moodle.com (for the team to grab later as the sprint progresses)
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
If the issue already has a fix version set by the component lead, it should be left unchanged.
For meta issues, the fix version may be set as 2.x, as generally only subtasks of meta issues are included in sprints.
Labels
Issues are labelled triaged to indicate that all the above points have been covered. A comment may be added explaining the reason for any changes.
Issues with proposed fixes are labelled patch so that they can be found easily and given attention.
Triage filter
The filter To triage (Moodle-all) includes:
- Issues with assignee to review (empty/nobody/moodle.com without triage label)
- 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
- By priority - aim for blockers and critical issues to be reduced to 0
- Recent bugs
- Whatever is of special interest at a given time e.g. for DEV sprint forumng, survey, lesson and gradebook
Example query for searching for performance-related issues:
project = "Moodle" AND status in (open, reopened, "In Progress") AND "Affected Branches" ~ "MOODLE_20_STABLE" AND ( component in (Performance) OR labels in ("performance") OR text ~ slow OR text ~ speed OR text ~ performance OR text ~ profiling OR text ~ benefit OR text ~ throughput) ORDER by priority desc