Bug triage
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).
Step 1 - 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 (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 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.
Action points:
- 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
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.
Action point:
- Identify a person/team with sufficient knowledge to decide upon the 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.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.
