id	summary	reporter	owner	description	type	status	priority	component	severity	resolution	keywords	cc	release
8883	Improving bug triage using "user pain" method	david.bourguignon@orange.fr	anybody	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\r\n\r\nIt uses the following inputs for each bug report:\r\n\r\n * Type (What type of bug is this?)\r\n  * 7: Crash: Bug causes crash or data loss. Asserts in the Debug release.\r\n  * 6: Major usability: Impairs usability in key scenarios.\r\n  * 5: Minor usability: Impairs usability in secondary scenarios.\r\n  * 4: Balancing: Enables degenerate usage strategies that harm the experience.\r\n  * 3: Visual and Sound Polish: Aesthetic issues\r\n  * 2: Localization:\r\n  * 1: Documentation: A documentation issue\r\n\r\n * Priority (How will those affected feel about the bug?) \r\n  * 5: Blocking further progress on the daily build.\r\n  * 4: A User would return the product. Cannot RTM. The Team would hold the release for this bug.\r\n  * 3: A User would likely not purchase the product. Will show up in review. Clearly a noticeable issue.\r\n  * 2: A Pain – users won’t like this once they notice it. A moderate number of users won’t buy.\r\n  * 1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect sales.\r\n\r\n * Likelihood (Who will be affected by this bug?) \r\n  * 5: Will affect all users.\r\n  * 4: Will affect most users.\r\n  * 3: Will affect average number of users.\r\n  * 2: Will only affect a few users.\r\n  * 1: Will affect almost no one.\r\n\r\nThe basic equation for calculating User Pain is as follows:\r\n\r\n{{{ User_Pain = (Type * Likelihood * Priority) / Max_Possible_Score }}}\r\n\r\nUser pain is automatically recalculated when a new bug is entered and whenever a bug changes.\r\n\r\nImplementing it with Trac would basically mean:\r\n\r\n * Use the three existing scoring fields for tickets to provide for Type, Priority, Likelihood scales.\r\n * 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). \r\n\r\nThere are at least three benefits to this approach:\r\n\r\n * Developers always know what to fix.\r\n * It promotes shared code ownership.\r\n * Bugs that prevent you from shipping don't accumulate. \r\n\r\nAs 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.\r\n\r\nIf 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!\r\n	enhancement	new	normal	Request-a-Hack	normal		triaging		0.11