Bug triage: Difference between revisions

Revision as of 12:17, 13 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

General

Has the issue been reported previously?
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

Note: A backlog fix version should not be set for quiz component issues.

Label

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.

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

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)

@@ Line 9: / Line 9: @@
 ==The triage process==
-===Step 1 - Issue details check===
+===General===
-# Check whether the issue has been reported previously
+* Has the issue been reported previously?
-# Check and amend as necessary:
+* Are the correct components selected?
-#* Issue summary and description
+* If necessary, request more information, such as debug messages for errors
-#* Priority (see below)
+* If applicable, for example the issue covers more than one component, add watchers
-#* 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:
+===Priority===
-* Anything causing error/exception is a blocker
+* Security issues and anything breaking badly (error/exception) => blocker
-* Improvements/new features cannot be blockers (in triaging process, though the dev team can raise them later)
+* Anything leading to wrong results => critical
+* Anything else => major (apart from minor/trivial tweaks)
-===Step 2 - Setting a fix version===
+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
@@ Line 32: / Line 37: @@
 * If the issue is a feature request, assign "Fix version" to DEV backlog
-(List copied from [[Process]])
+Note: A backlog fix version should not be set for quiz component issues.
-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
+===Label===
-* "Setting a fix version of DEV backlog so that we consider including the feature in 2.1."
+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.
 ==Triage filter==
@@ Line 42: / Line 47: @@
 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)
+* 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

Documentation