MySQL Bugs: #30723: MySQL issue tracker should track bug type versus severity separately

Bug #30723	MySQL issue tracker should track bug type versus severity separately
Submitted:	30 Aug 2007 15:26	Modified:	11 Nov 2007 12:45
Reporter:	Kevin Benton (Candidate Quality Contributor)	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Websites: bugs.mysql.com	Severity:	S4 (Feature request)
Version:	Unknown	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	qc

Description:
Within AMD, we've intentionally separated enhancement out of the Severity listing and created a separate "Bug Type" field with the vaules of "defect,enhancement,doc,question" which allow us to determine what type of bug we're dealing with and still have an associated severity assigned.  I strongly encourage MySQL issue tracking developers to do the same as it has proven to be extremely helpful in determining customer impact for non-defect issues.

How to repeat:
See Description

Suggested fix:
See Description

I wasn't clear enough - we separated out enhancement from severity in our Bugzilla installation.

Thank you for the interesting feature request. Note that, besides public severity, we do have internal priority and several flags to determine customer impact. We have separate subcategoies for "docs". 

As for questions, bugs database is not considered a proper place for asking them. People should either use forums, mailing lists or just our paid support for asking MySQL-related questions.

Does the above sound reasonable to you?

FYI - the reason we split out feature request as a severity was simple - how urgent is the feature request?  Some feature requests are more urgent than others and without having a way to track that separately, data is inevitably lost.  On the other hand, by tracking different types of bugs (defects versus enhancements), we can assign a severity level according to customer impact.

As I mentioned in my original request, this is a process change feature request, and in my mind, this one ought to be an S2 on the list of enhancements for this issue tracking system. :-)

Kevin

We have internal priority feild for this. If I set it to P2, it will become an important enough feature request. We may have S1 (crash), but P3 bug at the same time, as, for example, crash is repeatable only with 1999 concurrent connections calling the same SP (hypothetic example, surely) and is prevented easily by some setting in my.cnf.

I do not see anything that additional bug type will add to this picture. Do you have "priority" as separate property?

Hi Valeriy,

We chose to remove Priority from Bugzilla because the combinations of both severity and priority didn't add enough value to overcome the 35 different possibilities that Bugzilla offers (and the confusion surrounding those combinations), but we agreed that we would only do that if we had a way to differentiate different classes of bugs (most commonly defects versus enhancements).  This drastically simplified the settings "customers" could choose from and added a customer-driven sense of urgency to enhancements.

As a software developer (more specifically, developing Bugzilla for AMD), I understand that desire to have a priority setting in development trackers so developers can sequence work-order.  We have overcome that as well by setting target milestones and deadlines for projects so we know how soon something must be completed (thus giving us a sense of priority).

I'm not saying the way that MySQL has implemented bugs.mysql.com is wrong, rather suggesting change as a result of the dramatic improvements over issue classification by simply adding one field - bug type.  BTW - that field also gives us other abilities to selectively display fields (i.e. how to reproduce is displayed when the bug_type "defect", but not for "enhancement").

Kevin

This bug is not scheduled to be fixed at this time.