Issues, Tags, and Milestones

Pascal Deschênes
Essays: On Product Development
3 min readAug 7, 2015

How do one perform triage on a list of issues? If you’re in bug creep with hundreds of items in your bug bucket then you probably have a bigger problem to deal with and should move along for the time being and use your time squashing bugs, hiring people and/or firing some.

tl;dr:

Issue tags: feature, chore, bug, critical, and optionally component membership. Issue milestone: user stories, backlog, and icebox.

Traditionally, within Bugzilla (and other bug tracking systems such as Jira), we have bug status, where a bug is either new, assigned, or resolved and where resolved is actually one of fixed, invalid, wontfix, later, remind, duplicate, or worksforme. Then we have bug importance using two axes: P1–5, and a set of blocker, critical, major, normal, minor, trivial, enhancement. And finally, a bug is associated to a project/product and a component. Too much information and pain, without real benefits.

The lifecycle of an issue boils down to the following: issue is reported (unassigned), every once in a while, someone jumps in and perform bug triage where an issue is marked as either a feature request, or an actual bug, which is in turn either critical or not, that is, said bug needs to be urgently addressed or not. Depending on the issue count, an intermediary level (major) could be used. Potential variation on the project/product size, an issue could also be categorized into (a well-known and closed set of) components such as dashboard, service, api, cli, and such to hint on membership. Then come those nasty little refactoring, technical debts or housekeeping aspects which, while unpleasant, should be dealt with, and marked as chore or ♥.

The lifecycle would not be completed without taking into account temporal aspects (hello product/project manager/owner!) As part of the triage, one should determine whether this issue would be addressed for some current user story milestone or considered for some near or distant future release. The distinction between near and distant essentially convey enthusiasm (ok, priority) about a given issue: will definitely make it soon or worth considering but currently on the side track. There’s obviously some relation with issue status: if an issue is marked as critical, it is most likely to be in a given user story milestone. Obviously, same goes if you commit to Joel Test rule #5.

Hence, in other words, issues are either tagged as a feature or a bug, where a bug is potentially bumped as critical, and potentially categorized as part of one of n components. Issues are either planned for given user story, part of a backlog to shortly be fed to another specific milestone, or should be worth considering some time later.

Closing an issue consolidates it. Closing an issue shouldn’t be plainly dismissed. Why is this issue closed? Is it resolved? A duplicate? an invalid? Something we don’t actually care for? There’s a human aspect in closing an issue: dismissing without any explanation sometimes feels like a big fuck off.

Note that the bug triage operation shouldn’t be reserved to project lead: anyone can typically contribute to bug triage, and should be done so continuously. When in doubt, just leave issue aside, where someone else can take over. Have some free time to spare?

In-between two projects or bored during the weekend and want to perform some bug squashing kung fu fighting? Dive in, browse issues, and find one you can tackle, that ideally meet those high-level criteria: unassigned, triaged, within a user story milestone.

--

--

Pascal Deschênes
Essays: On Product Development

Tech Thinker. Co-Founder & Chief Product Architect @nuecho. Speech Recognition & Telephony Industry. Hike. Code. Read. Build. Garden.