BugTracker
Overview of jobs
The issue manager has basically three jobs on the Darcs bug tracker:
Customer service - very fast response. We need to respond to incoming bugs as closely to instanteously as we can manage. The priority here is to get people unstuck, find workarounds if relevant.
Triage - fast response. Strike while the iron is hot. This usually happens at the same time as customer service. While the issue is still fresh, squeeze as much necessary information as you can (eg. what version, etc). Your main goal here is to turn the issue into some actionable. By the end of triage you either want to be waiting on somebody to do something or to be done. No more “huh?”
Maintenance - at leisure (goal: touch 3 old bugs every day). Check up on those old need-* statuses, chase up on people, check for relevance. Re-do triage.
Maintenance tasks
Maintenance can be done fairly quickly. You’ll want to add a series of three canned queries (see the BTS web interface, log in, ‘Your Queries’):
- Need Triage
- Maintenance
- Assigned
The “Need Triage” query alerts you to any issues with an “unknown” status; see the earlier parts of this document for details. Basically, no maintenance actions until you’ve finished triage.
The “Maintenance” query sorts the tickets by the last activity. In other words, you will see the stalest tickets first. For each ticket, determine if the current status and recommendations are still valid, and update accordingly. If things appear to be stuck, think about how to unstick them (re-assigning?). If everything is still in order, then just bump the ticket to the back of the queue. There’s no way to bump tickets, so you’ll have to do it manually either by making a comment (preferably saying something useful), or by changing some field (and maybe changing it back).
The “Assigned” query is potentially useful for hacking sprints, when you can harass people in real life. :-)
Bug Triage
Checklist for Reading Bug Tickets
- Did the user tell us what went wrong?
- What did they expect?
- What exactly did they do?
- Did they provide the data we regularly ask during diagnostics (logs, version numbers etc)?
- Where did the issue happen (machine, specific software running on it etc -something that might influence us).
Responding
- Does the original poster need to supply you with some particular details? Which?
- Is there a specific debugging step that needs to be undertaken? Are there particular questions that need looking into?
- Do we have a rough idea how to fix it?
Bugtracker conventions
Status
open (ex-unknown, waiting-for, needs-*, in-progress)
given-up (ex:given-up, duplicate,wontfix, deferred)
resolved.
open
, replacing:unknown
- Bugs with this status should be considered as needing customer service and/or triage.waiting-for
- Need details from the original reporter; need a dependency fulfilledneeds-reproduction
- Can anybody else reproduce the symptoms?needs-testcase
- Now that we can reproduce it, can we distill it into a formal test?needs-diagnosis/design
- We have all the information we need, now need to think about something in particularneeds-implementation
- ready to hack!in-progress
- Work is in progress to solve the problem described by the issue. Assigned to person working on it.
given-up
, replacing:deferred
- We just cannot deal with this bug right now and have to retarget it for the far future. To be used sparingly.duplicate
- The issue is a duplicate of another issue. Don’t forget to point to old bug using supersederwont-fix
- Sorry.given-up
- An issue which cannot be reproduced or with questions left unanswered for a long time.
resolved
- The issue has been resolved. The state of the issue and reason for considering the issue resolved must be described in messages of the issue.
Note: when exporting issues to darcsden, change both given-up
and resolved
to closed
.
Topic
Roundup has this handy notion of keywords/topics that helps us to classify bugs and understand relationships between them.
Milestones/Targets
Right now, issues are tagged with Target-X.X topics, which we will increment if we fail to meet the targets.
See also
- Infrastructure
- Automation and bulk-processing
- RegressionTests (whenever asking for tests)
- Notes on bug-tracker vs mailing lists
- mulander advice - Adam Wolk has kindly taken some time out to help us get better at bug tracking. Check out this discussion