**Waldir** wrote on `2014-07-29 20:45:25 (UTC)`

**tl;dr** I stand by my proposal to have a severity/impact dual-axis priority measure, with the highest priority items at the top right of the resulting space.

I agree the current definition of severity isn't ideal, but it's certainly a good start. Nothing prevents us from working up it. For example, the "important area to whom" question can be defined, say, in terms of the WMF's strategic goals, or the Engineering team; and "trivial" could be removed since it's a measure of effort, not severity. Other improvements are certainly possible.

Then there's the issue of us actually making use of it; getting rid of the "unspecified" value and assigning a mid-range value by default (maybe "enhancement", based on the 60% number cited above?) could help here.

> So I guess I believe that impact (severity? frequency?) influences priority
I proposed impact as a measure of how many people the issue annoys. Severity can be measured separately, as mentioned above, and frequency isn't really a factor in our case: bugs that appear to occur randomly are usually just those that occur under a (yet unknown) set of conditions. Instead, a simple scale based on an rough estimation of how many users are affected could work well.

> 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.

These (mostly the first) seem to me like effects of an "impact" metric. The second scenario is true whatever the priority defined for the bug so it's irrelevant if we want a measure that's as objective as possible (i.e. predicts how soon the issue is addressed). Using the criteria that are already implicitly in use, as Quim mentions above, seems like the best way to do this.

Note that I don't mean to simply cling to my previous position; I just think two reasonably objective measures with sane defaults are better than a single, subjective priority measure that we often won't be able to agree on, and tokens which depend strongly on the number of stakeholders that actually participate on the bug tracker (which historically has been very low and biased toward the more tec).