Bug triage
This page is for analysing and developing a Moodle issue triage process. This process is STILL UNDER CONSTRUCTION.
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.
Moodle issue triage is a process where 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.
Triaging issues should help ensure we appropriately manage all reported issues (bugs as well as feature requests).
--> The following white paper assumes a 2 step process: (1) quality review of information in Tracker, and (2) triage
- the primary benefit of a 2 step process is to allocate resources appropriately: team members with greater product knowledge can focus on triage while those with less knowledge can focus on Tracker quality assurance (while hopefully building product knowledge).
Tracker Quality Review
Each Tracker issue must be in a "fit state", so that an informed decision can be made about it. This is a quality review of the information entered into Tracker. Every new issue entered into the Tracker should be reviewed.
Here is a starting point for Tracker QA:
- Does the Summary accurately reflect the issue?
- Is there enough information for a developer or a tester to reproduce the problem.
- Are fields completed adequately?
- Has it been categorised correctly (priority is an obvious example)
- Has it been assigned to the appropriate tester/developer?
Action item: identify a filter to ensure every new issue is reviewed on a periodic basis. Is the nightly? Weekly?
Action item: identify a person/team to review new issues for quality.
Action item: identify a way to know that each issue has been reviewed.
Triage process
Triage should take place against issues that have been verified.
Action item: identify a person/team with sufficient product knowledge to make and informed call on newly logged issues.
Triage filters
- 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.
- Recent unresolved bugs that need triage - These bugs need checking to make sure they are assigned to the right person, category etc.
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 should have a 1.9.1 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.
