Bug triage: Difference between revisions

Revision as of 12:07, 9 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

Perform housekeeping, fix spelling, remove duplicates and spam
Update priorities/assignees/components/descriptions/statuses
If necessary, request more information

Step 2 - Setting a fix version

If the issue is a bug in the current stable version (eg 2.0), assign "Fix version" as STABLEBACKLOG
If the issue is related to backup and restore, assign "Fix version" to STABLEBACKLOG with high priority
If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG
If the issue is a feature request, assign "Fix version" to DEVBACKLOG

(List copied from Process)

Issues are then labelled triaged to indicate that step 1 and 2 have been completed.

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)

@@ Line 4: / Line 4: @@
 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 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.
-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:
+==The triage process==
-# Issue details check
+===Step 1 - 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).
+* Perform housekeeping, fix spelling, remove duplicates and spam
+* Update priorities/assignees/components/descriptions/statuses
+* If necessary, request more information
+===Step 2 - Setting a fix version===
-==Step 1 - Issue details check==
+* If the issue is a bug in the current stable version (eg 2.0), assign "Fix version" as STABLEBACKLOG
+* If the issue is related to backup and restore, assign "Fix version" to STABLEBACKLOG with high priority
+* If the issue is a bug in the current stable version requiring database changes, assign "Fix version" to DEVBACKLOG
+* If the issue is a feature request, assign "Fix version" to DEVBACKLOG
-Each tracker issue must be in a fit state, so that an informed decision can be made about it.
+(List copied from [[Process]])
-*Does the summary accurately reflect the issue?
+Issues are then labelled ''triaged'' to indicate that step 1 and 2 have been completed.
-*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 (as described in the help popup) set correctly?
-*Is the security level (as described in the help popup) set correctly?
-*Are appropriate component(s) selected?
-*Is the issue assigned to the correct person? By default, an issue is automatically assigned to the [http://tracker.moodle.org/browse/MDL?report=com.atlassian.jira.plugin.system.project:components-panel component lead] of the first component listed. For example, if a reported issue affects the components 'administration' and 'groups', it will automatically be assigned to the administration component lead. If the component(s) field has been completed incorrectly, the issue may require reassigning.
-*How difficult is the issue to resolve? Setting an appropriate difficulty level enables bugs of a certain difficulty level to be easily searched for.
-If the person checking issue details is unsure of any of the above points, they should add a comment e.g. 'I have reproduced this bug but don't know who it should be assigned to' for the person doing step 2 of the bug triage.
+==Triage filter==
-Action points:
+The filter [http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=11424 To triage (Moodle-all)] includes:
-*Identify a way of ensuring 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. A simple solution might be for the person checking issue details to add a comment stating 'issue details confirmed'.
-==Step 2 - Fix version decision==
+* 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
-Once a tracker issue's details have been confirmed, a decision can be made regarding the fix version. In addition, any comments made by the person checking issue details should be addressed. Regarding the assignee, issues assigned to moodle.com should be reassigned to an individual.
+==Triaging priorities==
-Action point:
+* Recent bugs
-*Identify a person/team with sufficient knowledge to decide upon the fix version.
+* 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)
-==Triage filters==
-*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10231 Recent unresolved bugs that need triage] - These bugs need checking to make sure they are assigned to the right person, category etc.
-*[http://tracker.moodle.org/secure/IssueNavigator.jspa?mode=hide&requestId=10544 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.5 should have a 1.9.6 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.
 ==See also==

Documentation