priority values seem to mix up things, leading to misclassifications

Issue #2927 wontfix
Thomas Waldmann created an issue

considering the choices "trivial", "minor", "major", "critical", "blocker", this seems to mix up priority and difficulty somehow.

for example, if there is a some severely wrong information somewhere in a docstring, what is this?

is it "trivial", because it is easily fixed in a minute?

is it "major", because one wants to fix such easy stuff with high priority (esp. as it takes about not time to get this off one's desk)?

so, i suggest to split this:

difficulty: low, medium, high

priority: low, medium, high

when considering this, one finds that even this might not be enough.

if some issue is a lot of work to fix, but easy work, just saying difficulty low is correct, but not enough.

So we get this:

difficulty: low, medium, high

effort: low, medium, high

priority: low, medium, high

(and of course there is always some "unknown/unspecified" choice also)

Comments (4)

  1. Dylan Etkin

    Hi Thomas,

    We appreciate the feedback. However we have found that with any static issue tracker fields there is often disagreement about what they mean and what they should be.

    For some examples of the opinions that are out there you can read this and this

    The reason we have chosen these priorities is that they match the priorities you will find in JIRA. The rational is two fold. 1. We have worked with these priorities of the last 8 years and found they are able to represent a wide range of issues. 2. If users want to migrate from a BB issue tracker to JIRA the issues will map easier.

    I hope this clarifies our intentions a bit.



  2. Thomas Waldmann reporter

    Hy Dylan,

    ad 1) well, I just showed you quite "trivial" (in the original meaning of trivial, not meant as priority :) and common examples that show that your priority values are a) not "priorities" / mixing things up and b) not really usable.

    If you managed to live with that for 8 years, it doesn't necessarily mean that it can't be improved and that you / your users want to live with them for the next 8 years also. :)

    ad 2) well, if this migration is a common scenario, I agree, that's a real problem then. but it likely just means that it's wrong at both places. if you fix it at both places, you won't have to live with that forever.

    A fix for the upgrade scenario could be a mapping from the old 1-tuples to the new 3-tuples. of course that can't be perfect and without issues, but this is just because input data is unsufficient and you basically have to guess how people understood it. But, as this guessing is not limited to the upgrade scenario, but happens since 8 years according to your answer, that's not a new problem. You also have to consider that everybody might have used those things differently, so, you don't have much data there anyway.

    Thanks for the links, I'll read them soon. :)



  3. Thomas Waldmann reporter

    ok, i read the stuff from the linked issues. was a funny read with popcorn potential. :)

    now, it looks less mixed up to me. what you currently have is just mislabelled - it shouldn't be labelled priority, but rather severity (although then still "trivial" sounds strange, i would rather call it "very minor" or something like that, that does NOT sound like "difficulty to solve").

    severity (impact), difficulty (how much brain to solve), effort (how much work to solve) are basic properties of an issue and can be expressed on a scale (if known). you can just use numbers for the scale or words that represent those numbers in a non-misleading way.

    priority can be determined as a function of them and (potentially lots of) other informations and is not a direct property of the issue, but rather a project managment decision.

  4. Log in to comment