Apenwarr on triaging bugs
Apenwarr’s recommended triage process
Use labels to look at only interesting subsets of bugs.
Have a “Triaged” label and one label for each upcoming milestone/story. (He calls this a “hotlist”).
Then, there is a triage team that meets periodically and examines all new bugs (that don’t yet have the “Triaged” label).
Then the triage team, for each bug, will:
- Assign the bug to at least one hotlist (either a release milestone, aka story, or a backlog of not-yet-scheduled features; maybe it’s even relevant to more than one feature hotlist)
- Assign the bug to the Triaged hotlist to make it disappear from their queue (Pennarun 2017)
As a practical tip for starting this process when there is a pre-existing backlog, he suggests that most bug trackers allow you to query for bugs in your project by modification date.
But this one, instead of having a modified>DATE absolute cutoff, uses a relative cutoff date. In this example I picked 730 days, or two years. What this means is that any bug created more than two years ago, but untriaged, will show up in the query, inviting you to triage it now. Over the course of the next two years, this moving window will slowly pass over all your remaining bugs. (Pennarun 2017)
His last tip is to use a “Needs Discussion” list for old bugs that need more information. This list allows him to use a special bug tracker query to exclude bugs that have been recently discussed/modified. Once it goes idle for a short period of time (he uses 6 days), he is prompted to discuss again or can close it without angering the person who originally filed it.
Hot takes
The priority is useless
First of all, in my corner of the world, priority levels have been made almost completely meaningless by well-intentioned teams. Depending on the project, P0 often ends up paging someone, which is rarely what you want, so you usually don’t use P0. P1 often has a stupid bot attached, which pings the bug if you stop responding, trying to enforce some kind of short SLO, so the pattern is often that you file a bug, then someone looks at it for a while, makes little progress, gets annoyed by the bot, and lowers the priority to P2, only to be interrupted by the next round of new P1 bugs. It maximizes distraction without necessarily getting more bugs resolved. Oops! P2 is the default, which is fine, but of course, almost all bugs are P2 so your bug pile is undifferentiated. And at this point everyone knows that P3 and P4 both mean “will never implement.” (Pennarun 2017)
If every bug is assigned to someone, the assignee becomes useless
Many teams try to take every incoming bug and make sure it’s assigned to someone on the team, under the assumption that the person will reassign it or fix it eventually. Of course, that doesn’t work when ingress > egress; each person’s queue will be ever-growing, not ever-shrinking, and eventually the Assignee field also loses all meaning, and you have an even bigger problem. (Pennarun 2017)
The component field is almost useless
Bug tracker “components” (aka dividing by “project” or “area”) are almost useless! They are only good for one thing: helping your end users point your bug at the right triage team. (Pennarun 2017)