How to rank "Priority"

[Maurd]

Generally when I submit something I leave the priority as "unknown" and let Darkshenron rank it, but regardless I need to ask:

Are (should) the "priority" of tracker issues be ranked by how important the issue is, or how complicated it is? I've always been aware that it was based on how important. However, in a recent tracker item, I had been told otherwise: http://tracker.vbulletin.com/browse/VBIV-13348

The item was originally prioritized as "Major". I commented by saying:

I also think it's unfair to make the priority of this "Major" when it's really far from that.

Freddie Bingham then responded in agreement, and lowered it to "Minor":

Agreed, I am not aware of any issue that would classify this as major.

Paul then comes back, changing it to "Major" saying:

Major is the correct classification. Its not a minor change.

To which I replied:

It might not be a minor change, but it's not a major priority. AFAIK, you are supposed to classify tracker items by how important they are, not how complicated.

To which He replied:

Not quite, its more the effect they will have, which you seem to agree would not be minor.

So who is correct - Freddie and myself with "Minor" or Paul with "Major"?


Thank you.

[Paul M]

Are you bored tonight ?

Btw, since you mention it, Seb would have checked the setting when he confirmed it, and he changes them if he disagrees.

[Leadcrow]

Why not add a field for complexity? There's a ton of extremely easy stuff to fix, and to see it routinely rank it as minor and left unadressed in favour of 'major' items is unoptimal.

[Wayne Luke]

Why not add a field for complexity? There's a ton of extremely easy stuff to fix, and to see it routinely rank it as minor and left unadressed in favour of 'major' items is unoptimal.

Difficult to class because the people verifying the bugs aren't the ones fixing them. A bug may seem easy but turns into a complex issue because of all the things interlinking together.

These are the priorities used:
An issue has a priority level which indicates its importance. The currently defined priorities are listed below. In addition, you can add more priority levels in the administration section.

Unknown
Issue priority is Unknown.

Blocker
Blocks development and/or testing work.

Showstopper
System is placed in unrecoverable state. Build can not be released.

Critical
Crashes, loss of data, severe memory leak, security issue, etc.

Major
Major loss of function.

Minor
Minor loss of function, or other problem where easy workaround is present.

Trivial
Cosmetic problem like misspelt words or misaligned text.

[Sebastiano Vassellatti]

The priority of requests (features, improvements, etc.) is an estimate of the entity of the request. For requests, the general piority guidelines followed are as follow:
Trivial - A visual/display improvement.
Minor - Minor feature addtion or change to existing functionality.
Major - Completely new functionality, major addition/change to existing functionality.
Critical, Showstopper and Blocker are not used for requests.

As Wayne mentions, the people Confirming issues are not the same people that perform dev work on them, so a request that looks Minor may actually turn out to be Major because of all the things it involves, or vice-versa something that looks Major may turn out to be Minor because it's more simple than it seemed. Sometimes this happens.

In the specific case of VBIV-13348. It was created by Paul, which is a developer, so I'm sure his priority classification was based on actual knowledge of what would need to be done and therefore correct, hence I left it as it was when I Confirmed the issue.

[Paul M]

As I said originally, I classed the suggestion as a major change to functionality, I stand by that choice.

[Mooff]

Given the explanation the wording "priority" is misleading.

I've allways read it as "how important is it to fix it".

Here it reads like "how much codingtime is needed to implement it".


f.e. given there is a broken sql statement which could cause the database to crash, but the problem is identified and a fix is provided. The fix also is simple, one word is missing.
I would use priority critical here. But i should use trivial?

[Sebastiano Vassellatti]

Given the explanation the wording "priority" is misleading.

I've allways read it as "how important is it to fix it".

Here it reads like "how much codingtime is needed to implement it".


f.e. given there is a broken sql statement which could cause the database to crash, but the problem is identified and a fix is provided. The fix also is simple, one word is missing.
I would use priority critical here. But i should use trivial?

What I said above applies to requests, not to bugs. Bugs are prioritized basing on their impact as per the Jira priority definitions copy-pasted above by Wayne.
Your example would be a critical bug, because (as mentioned in the priority definition) it leads to a database crash.

[Mooff]

It's also misleading for feature requests.

The priority of requests (features, improvements, etc.) is an estimate of the entity of the request. For requests, the general piority guidelines followed are as follow:

I do not think that classification is good. While the importance of a request can sometimes be linear to the complexity of a request, most times it does not.

For example a feature request could be to give the users the possibility to rearange forumhome, including sidebar, forumorder, who's online etc. as they do see fit. All beeing saved in a cookie. That would be a minor/trivial feature requets in terms of priority and importance. But it would be a major request in terms of complexity and codingtime.
Such a request getting major priority would confuse a lot of jira users.

In addition if one does have a future request which would be really awesome to have, where a lot of users will profit from, and he uses major as priority. Does this mean it moves at the end of the queue and a lot minor requests come first?

[Sebastiano Vassellatti]

The Priority of a request it's not its "importance". The importance of a request is based on the votes and feedback it gets.