**aklapper** wrote on `2014-07-15 23:51:33 (UTC)`

**<tl;dr>:** My current position is that we do not need a general Severity or Impact field, but I'm welcome to hear more arguments, and I'd be fine with defining clear, isolated usecases for queries (and how they support our software development processes) that we might want to implement in some way (e.g. a "crasher" project, or via defining tokens as mentioned by Mukunda).

**Long version:**

Severity is only objective and informative if its values are clearly defined (see https://www.mediawiki.org/wiki/Bugzilla/Fields#Severity for our attempt which isn't too great) **and** if it is consistently used. Both is often not the case.

Currently in Bugzilla, "normal" severity can mean anything. For "major", "Major loss of function in an important area" already has two subjective terms - what's important to you and me? An issue can be "minor" or "trivial" severity (what's the difference?) to fix when it's a typo, still a typo can trigger a crasher (defined as "critical" severity in Bugzilla and hence conflicting).

While Wikimedia Bugzilla is one of those instances which set "unspecified" severity by default, it's been shown that reporters often keep the default value set by ignoring yet another field (see http://ansymo.ua.ac.be/~alamkan/wp-content/papercite-data/pdf/lamkanfi2010msr.pdf page 2), hence up to 60% of reports in some Bugzillas are misclassified as people did not find the "enhancement" value hidden in there and instead write "RFE" in the bug summary (see page 4 of https://www.st.cs.uni-saarland.de/softevo/bugclassify/paper/icse2013-bugclassify.pdf ).

Currently I don't even believe currently that differentiating feature requests/enhancement and bugs make much sense because it's often impossible to draw the line (I won't drop the four quotes from papers now). An uncommon feature request won't happen and will be lowest priority as long as nobody works on it, and if somebody considers a feature crucial, s/he will assign it to her/him and its priority will be raised. So I guess I believe that impact (severity? frequency?) influences priority, among other things like "cost of fixing" and "risk of fixing" (which we didn't express via fields so far either in Bugzilla, but we got points in Phabricator). For the records, I stole these criteria from http://www.ericsink.com/articles/Four_Questions.html.

If you like querying for critical and blocker bugs not just for academical reasons (though again I must warn that any bug report numbers depend first on "the number of users using the software, and the convenience with which those users can register new bugs" and only to lesser extend on "the absolute number of bugs present in the software", to quote page 26-27 from Karl Fogel's "Producing Open Source Software" from 2006), I would honestly love to know the usecase, and we could for example set up a "crasher" project, cross-codebase, or play with tokens.

(PS: Yes, I like to base decisions to some extend on science as we're not the first people running into these questions.)