Improving bug triage using "user pain" method

[davidbourguignon <david.bourguignon@…>]

Bug triage is a difficult process, and a method using "user pain" criteria could improve it a lot…

This method is described with full details on: ​http://www.lostgarden.com/2008/05/improving-bug-triage-with-user-pain.html

It uses the following inputs for each bug report:

• Type (What type of bug is this?)

7: Crash: Bug causes crash or data loss. Asserts in the Debug release. 6: Major usability: Impairs usability in key scenarios. 5: Minor usability: Impairs usability in secondary scenarios. 4: Balancing: Enables degenerate usage strategies that harm the experience. 3: Visual and Sound Polish: Aesthetic issues 2: Localization: 1: Documentation: A documentation issue

• Priority (How will those affected feel about the bug?)

5: Blocking further progress on the daily build. 4: A User would return the product. Cannot RTM. The Team would hold the release for this bug. 3: A User would likely not purchase the product. Will show up in review. Clearly a noticeable issue. 2: A Pain – users won’t like this once they notice it. A moderate number of users won’t buy. 1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect sales.

• Likelihood (Who will be affected by this bug?)

5: Will affect all users. 4: Will affect most users. 3: Will affect average number of users. 2: Will only affect a few users. 1: Will affect almost no one.

The basic equation for calculating User Pain is as follows:

User Pain = (Type * Likelihood * Priority) / Max Possible Score

User pain is auto calculated when the bug is entered and whenever the bug changes.

Implementing it with Trac would basically mean:

• Use the three existing scoring fields for tickets to provide for Type, Priority, Likelihood scales.
• Create a dynamic "user pain" score for each ticket that would be computed each time one enters a new bug in the database (only the "Max Possible Score" changes, therefore it shouldn't be too resource intensive).

There are at least three benefits to this approach:

• Developers always know what to fix.
• It promotes shared code ownership.
• Bugs that prevent you from shipping don't accumulate.

As a conclusion: read this article! This is a treasure trove of great ideas about bug management (and software development in general). I did a summary, but it has great ways to be more subtle: increase pain slightly over time to avoid small bugs to be never fixed, etc.

If anyone knows how to develop a plugin for Trac that does this, I will be glad to test it! Thanks in advance for your help.

[Christian Boos]

Like you said, this should be done in a plugin. You should know that such "plugin request" ticket should actually be created on ​trac-hacks, not here. Alternatively, you're also welcome to post such an idea on the Trac-users MailingList.

Note that even if done as a plugin, if anything needs to be done in Trac to make such a plugin possible, we'll gladly take patches, and in this case feel free to reopen and discuss the specific needs here.

[davidbourguignon <david.bourguignon@…>]

Thanks a lot for your answer. My apologies for this mistake. In fact, when reading the ​http://trac.edgewall.org/wiki/NewTicket page I saw no mention of enhancement reports, only bugs concerning plugins, therefore I thought this was the right place.

I have created a plugin request on ​http://trac-hacks.org/ticket/8883 : could you confirm I did everything right? (In particular, I have a small issue with my email address…) Thanks in advance ! Have a good week-end.

[Christian Boos]

Replying to davidbourguignon <david.bourguignon@…>:

Thanks a lot for your answer. My apologies for this mistake. In fact, when reading the ​http://trac.edgewall.org/wiki/NewTicket page I saw no mention of enhancement reports, only bugs concerning plugins, therefore I thought this was the right place.

Good point, I'll add some more hints there.

In particular, I have a small issue with my email address…

Unfortunately, there's not much we can do about this, as we're not running the trac-hacks.org site and that one still uses an old version of Trac, which doesn't have e-mail obfuscation. Sorry about this.