Size: 3304
Comment:
|
Size: 3358
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 32: | Line 32: |
* Get diagnostics first, give suggestions later | * Get diagnostics first, give suggestions later (see [[Advice]]) |
Line 60: | Line 60: |
== See also == * WritingTests |
Managing Bugs
How to do bug triage on the BugTracker.
This page is intended for developers.
Contents
1. Definitions
1.1. Status levels:
- Unread - no one's ever responded to this bug (bad)
- Deferred - we've decided not to deal with this problem now
- Chatting - we're discussing a solution
- Need-eg - we need more information to progress
- In-progress - a partial fix exist or fix exists but isn't yet integrated
- Testing - a patch is merged, but poster has not confirmed it works, or it didn't reach the main repo yet
- Done-cbb - (could be better or couldn't be bothered) not perfect, but we've done as much as we're going to do
- Resolved - problem is fixed or was not a bug
1.2. Priorities
- critical - data loss or security issue
- urgent - bug that's blocking development or is a regression
- bug - bug that's not blocking development
- feature - it's not a bug, it's a feature
- wish - would be nice
2. How to do triage
2.1. Handling Individual Bugs
Get diagnostics first, give suggestions later (see Advice)
- Respond to new bugs as quickly as possible, especially where more info would be useful
- Make sure its priority is set appropriately
- Make sure its title is useful (ie convert commands should mention the backend)
- Add appropriate developers to nosey
- Add appropriate topics
- If it is a common issue, mark it as a duplicate
- Bugs that have long been fixed in main should be marked resolved
- Bugs that have been marked 'testing' can be marked resolved after two weeks if the user doesn't confirm earlier
- Bugs that have recently accepted patches should be marked testing
- Bugs with active work, including patches that aren't in main should be marked in progress
- Bugs that require more info from the user should be marked need-eg
- Bugs that remain in the need-eg state for an extended period may be closed
- Features and wishes that have been decided against should move to done-cbb
Commits summaries containing '(issueNNNN)' will automatically move issues to the testing state.
2.2. Marking Duplicates
- Choose whichever bug is resolved (or has a clear description) as the master
- Set superseder on the duplicate to point to the master, add a note, and set the bug as resolved
- If the master is not resolved, copy the nosy list from the duplicate and add a message pointing back to 'issueXXX'
2.3. Reducing Backlog
- Close out bugs that have been in testing and need-eg state too long
- Similarly, check if bugs marked in-progress are really in-progress
Sort open issues by priority and activity - here is a triage and a unloved query
- Degrade long-standing bugs to features and features to wishes where appropriate