Merge Severity and Priority into Importance

Well, they aren't entirely redundant. It is a bit of information that /might/ be nice to capture, but the only reasonable place to capture it is in the bug filing page, and the text would need to be carefully prepared to help the user pick the right option (as discussed in the Montreal sessions).

I am unsure whether in practice the UI can make this a useful feature or if it's hopeless. I'm okay with removing it on that basis, as I am with experimenting us using the Montreal-designed bug filing form (!)

Having a second field also makes sorting more difficult, as now you have to choose which to sort by.

Now, if we are planning to import bugs from other places, we are going to have to capture the data from them. Is there a plan for that?

Other bug databases also have fields like Type, Hardware, Flags, Depends on, Blocks, Votes, and QA contact -- not to mention values that Malone doesn't have for fields it does have. We may add one or two of those fields and values eventually, but importing bugs from elsewhere must not require Malone to have the union of the data model of all its data sources, otherwise it will be too unwieldy for people to bother.

On one hand, it seems, "severity" and "priority" mean different things. The former meaning "how big of an effect this has on the user of the software", the later meaning "how important it is for someone to fix it, as determined by a person who has the authority to make that decision." There can be factors that distance these two values from one another: a "critical" severity bug isn't necessarily "high" priority to fix, and a "high" priority fix doesn't necessarily imply the bug has a "critical" effect on end-users (causing data loss or crashing, etc.)

OTOH, I can appreciate the concerns of clutter and confusion and misuse of these fields.

What if we had a go at trying to give more clear descriptions to each of these "vocabularies"?

e.g. FogBugz calls its priorties things like:

1 - Must Fix
2 - Must Fix
3 - Must Fix
4 - Fix If Time
...

What if we tried a similar approach with our severity and priority levels (not necessarily favouring repeating names, mind you), and added restrictions on who can edit the priority? (the latter would require a bit of thought about who should actually be able to edit a priority, I think)

My main concern with us dropping severity just like that is that we'll *lose* *data*. ;) For that reason, I'd offer for us to at least give it a shot with more descriptive sev/pri level names before throwing out severity entirely.

Thoughts?

I can't really see Priority set to anything but a numeric value, unfortunately -- any words we use will have very soft distinction to them (I could suggest forget-sleeping, must-fix, wanted-fix, need-to-have, nice-to-have, fluff, maybe-one-day, couldn't-care-less, etc) that tends to blur over time (and over long buglists).

The problem with getting people to understand severity is similar: the only way to explain exactly what a severity means is to use a phrase for each level, and then the field becomes a bit unwieldy. Perhaps we could use the full phrase when filing a bug (This bug makes it utterly impossible for me to keep using this application, for instance) but the short term (critical) when displaying it. I don't really have a better solution.

Hi mdz,

Would you be happy with us collapsing priority/severity into just a
priority field, editable only by the people actually doing the work
on fixing the bug? Would this help simplify the Malone UI a bit, or
make your job more difficult?

I've attached the description of bug 886 if you need more context on
what the problem is here.

On 1-Dec-05, at 11:38 AM, Matthew Paul Thomas wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/886
>
> Description changed to:
> Malone currently includes a Severity field. In Bugzilla, this
> field
> lets the reporter of a bug suggest how important it will be to the
> programmer who ends up fixing it. In practice, however, some
> programmers like spending most of their time fixing obscure
> crasher
> bugs, while other programmers prefer fixing "trivial" UI
> embarrassments. And in Malone, the Severity field isn't present on
> the page for reporting a bug anyway. Therefore it exists mainly
> for
> the assignee to indicate how important the bug is for them
> personally -- but the programmer already has a Priority field for
> that! So there's no point in having Severity too.
>
> In Bugzilla, the presence of the Severity field also causes fun
> but
> useless and time-wasting arguments between the commenters on a bug
> about how important a bug actually is, especially since the
> reporter
> of a bug is likely to overestimate its severity (e.g. if a
> quirk of
> their system leads them to encounter the bug much more often than
> everyone else). These arguments occur far less often for the
> Priority field, because that is understood as the programmer's
> business and no-one else's.
>
> Severity + Priority as separate fields occurs in:
> * Malone
> * Bugzilla.
>
> A single field is used in:
> * Debbugs (Severity)
> * FogBuz (Priority)
> * Jira (Priority)
> * Plone Collector (Importance).

  affects /products/malone status needinfo

Cheers,

--
Brad Bollenbach

On Fri, Dec 09, 2005 at 09:46:56AM -0500, Brad Bollenbach wrote:
> Would you be happy with us collapsing priority/severity into just a
> priority field, editable only by the people actually doing the work
> on fixing the bug? Would this help simplify the Malone UI a bit, or
> make your job more difficult?
>
> I've attached the description of bug 886 if you need more context on
> what the problem is here.

Severity is an objective assessment of the impact of the bug. In practice,
this usually also determines the priority of the work involved in analyzing
and fixing the bug.

Priority is an independently assigned attribute of the bug, specifically
indicating its priority. In practice, this is a secondary sort key after
severity, and is used to prioritize certain bugs over others within a
severity category.

--
 - mdz

mdz, does your response mean that you would be happy if these two fields were collapsed into just priority? Or would it make your life more difficult?

SteveA suggested that before making such a change, we should also look at production data to get a sense of the combinations of priority/severity that exist currently.

Updated after discussion with mdz and sabdfl (though the suggested values are my own invention).