What is the best way to triage JIRA bugs?

[Douglas Linder]

People keep putting bugs in the correct project, but labelling them incorrectly.

For example it's not uncommon to see something like 'Missing link to pdf' categorised as 'Critical' in the project.

It's wasting a lot of my time going through and correcting these manually.

Currently I'm leaning towards making all bugs mandatorily 'trivial' when created, and then manually triaging them up to minor / major / critical / blocker if required, and having any bug which has not been touched in 14 days closed as 'won't fix' (seriously, if the reporter of the bug isn't making noise about it and no one has touched it in 2 weeks, its irrelevant).

This still seems like it'll waste time, but at least we won't have an endless wave of unimportant stuff filling the 'major'+ bug lists.

Can anyone suggest a better work flow for this?

Are there some plugins that somehow help manage this?

[Ivar · Accepted solution]

First of all I would never not consider the issues created by the users. A bug that "the user is not making any noise about" can just as well be the first indication that you have performance issues, data inconsistency issues or any other "top of the iceberg" symptom that indicate that something is very very wrong. Or it can be user error :)

Thing is - creating bugs will always be subjective to peoples feelings there and then. From your point of view, the missing link to the pdf is minor to trivial. To the user, not getting access to the pdf there and then, especially if this was something he/she needed right now, is major (or worse).

From my point of view, all issues created in Jira needs to be considered one by one. If you are spending a lot of time on this and it is not really not in your work description, I would suggest that you take it up with your boss. You should be happy that the users actually create issues in Jira instad of you having to follow up on e-mail created issues with all of their mess (like signatures, pictures in signatures, long comments as the mail grow more and more).

If you want an easy way out to downgrade or upgrade issues - consider adding a button (transition) where you can change the category without going into "edit-mode".

... and changing default to something else than major seems like a good idea. Personally, with my understanding of english beeing norwegian and all, I feel that the default "out-of-the-box" with Major as default is a bit to much to have a default.

[Robert Jahrling]

The best way is the way that works for you!

I would start with taking a look at the information that you ask bug submitters to provide. Have you considered not allowing bug writers to prioritize issues at all? It sounds like you're going through a review anyway, so why not save yourself the headache of getting cheesed off every time a submitter's sense of priority doesn't match yours? I've found that the less you ask of a bug submitter, the better--we grab a summary and a description, ask for a build number and system info, and allow them to attach stuff. That's it. Issues are unassigned and unprioritized at submit time.

What's your bug load? 10 issues per day? 100? 1000? If it's manageable, like 10, just schedule a time in your day to review the new bugs. Use only that time to review bugs. If you're lucky enough to be getting only 10 issues a day, review every couple of days instead.

But really, what you do and how you triage depends a whole lot on the size of your operation. For example, all of our projects have regular review meetings where a PM, developer, and tester meet to review, prioritize and assign new bugs. It's the best way for us to work, we have the time and the personnel, and nothing slips through the cracks. Everything has a destination, even if it's straight to the backlog. Maybe that doesn't work for you; maybe you're just one guy doing development and testing and everything else--in which case, you have to figure out what's best for the way you work.

I'm not sure you need a plug-in. What you need, seriously, is to take a critical look at your process to see if it needs improvement. When we did that at my office, we ended up just rearranging some screens and adding a workflow step or two, rather than writing any code at all.