Opened 9 years ago

Last modified 9 years ago

#8883 new enhancement

Improving bug triage using "user pain" method

Reported by: david.bourguignon@… Owned by: anybody
Priority: normal Component: Request-a-Hack
Severity: normal Keywords: triaging
Cc: Trac Release: 0.11


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:

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 automatically recalculated when a new bug is entered and whenever a 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!

Attachments (0)

Change History (1)

comment:1 Changed 9 years ago by davidbourguignon

Oops! I realized my email address is not protected against harvesting by spammers... If you have admin rights, can you help preventing this? Thanks a lot!

Modify Ticket

Change Properties
Set your email in Preferences
as new The owner will remain anybody.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.