Closed Bug 488931 Opened 15 years ago Closed 15 years ago

Default Priority values are unclear

Categories

(Bugzilla :: Bugzilla-General, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 3.6

People

(Reporter: mkanat, Assigned: mkanat)

References

Details

(Keywords: ue)

Attachments

(1 file, 2 obsolete files)

Pyrzak's student researchers pointed out that P1 - P5 have no meaning, and are confusing. I agree, I was confused by them when I first started using Bugzilla.
Attached patch v1 (obsolete) — Splinter Review
Change the defaults to something sensible.
Attachment #373403 - Flags: review?(LpSolit)
This is going to break QuickSearch by default, see bug 302511.
Depends on: 302511
Status: NEW → ASSIGNED
Blocks: bz-hci2008
I agree with this bug. However, I would suggest some more meaningful terms (and one that is actually the default of the defaults: "undecided"; which indeed means the reporter didn't take care of the field, instead of a medium value):

undecided, showstopper, urgent, normal, interesting, desirable
(In reply to comment #3)
> However, I would suggest some more meaningful terms (and
> one that is actually the default of the defaults: "undecided"; which indeed
> means the reporter didn't take care of the field, instead of a medium value):
> 
> undecided, showstopper, urgent, normal, interesting, desirable

  No, Bugzilla is designed to be a generic bug-tracking tool, and those priorities are too specific. They make the priority field into a very specific thing that might not fit all situations. It's simpler to just say that something is higher or lower priority and let local administrators and managers decide how best to use it for their specific process.
(In reply to comment #4)
>   No, Bugzilla is designed to be a generic bug-tracking tool, and those
> priorities are too specific. They make the priority field into a very specific
> thing that might not fit all situations. It's simpler to just say that
> something is higher or lower priority and let local administrators and managers
> decide how best to use it for their specific process.

That's a good reasoning.
However I still see value in the field "undecided" as a default value, rather than "normal".
(In reply to comment #5)
> That's a good reasoning.

  Thanks.

> However I still see value in the field "undecided" as a default value, rather
> than "normal".

  Yeah...I kind of don't like values that mean "this hasn't been set" as defaults on bugs--I prefer that bugs are all defaulted to "normal", because that gives a baseline for what "higher" and "lower" can mean.
This is ready for review now that the QuickSearch stuff has been done.
(In reply to comment #6)
> (In reply to comment #5)
> > That's a good reasoning.
> 
>   Thanks.

No problem.

> > However I still see value in the field "undecided" as a default value, rather
> > than "normal".
> 
>   Yeah...I kind of don't like values that mean "this hasn't been set" as
> defaults on bugs--I prefer that bugs are all defaulted to "normal", because
> that gives a baseline for what "higher" and "lower" can mean.

Well, I don't buy this reasoning.
Priority is a field that in a lot of the cases is managed by a certain group of people officially, so external contributors would not be allowed to set it (I don't know if this is not yet possible with Bugzilla, but if not, the "undesirable" option is still useful for when that feature comes).

Anyway, it's not good for priorization policies either. A bug triager could finish his journey having modified X bugs to be "low", but his manager run a test some hours later (before he starts his journey again the day after) and find Y number of bugs that are marked as "normal", thinking they are already prioritized. I think we need a way to know if a bug has been, or not, prioritized. With the current proposal, "normal" may mean 2 different things depending on the context.
s/undesirable/undecided/
Furthermore, current BMO's bugzilla has a default field called "--". It's default field is not "P3".
Yeah, it might be good to have a --- as the default.
Attached patch v2 (obsolete) — Splinter Review
Okay, I added a --- which will be the default and will sort lower than prioritized bugs.
Attachment #373403 - Attachment is obsolete: true
Attachment #378686 - Flags: review?(LpSolit)
Attachment #373403 - Flags: review?(LpSolit)
Thanks for considering it.

Just wondering about the patch, shouldn't the "---" item be the first one instead of the last one, in order to have it be the default?
(In reply to comment #13)
> Just wondering about the patch, shouldn't the "---" item be the first one
> instead of the last one, in order to have it be the default?

  No, Bugzilla's default default is the last item in the list.
Attachment #378686 - Flags: review?(LpSolit) → review-
Comment on attachment 378686 [details] [diff] [review]
v2

Several files have not been updated:

template/en/default/pages/fields.html.tmpl, lines 214-219
contrib/gnats2bz.pl, lines 609-629.
contrib/bugzilla-submit/bugzilla-submit, line 161
Attached patch v3Splinter Review
Attachment #378686 - Attachment is obsolete: true
Attachment #395520 - Flags: review?(LpSolit)
Attachment #395520 - Flags: review?(LpSolit) → review?(dkl)
Attachment #395520 - Flags: review?(dkl) → review+
Comment on attachment 395520 [details] [diff] [review]
v3

This works as expect when creating a new database from scratch. I was not able to test the gnats2bz code obviously so someone may need to verify that at some point. r=dkl
Flags: approval?
Flags: approval? → approval+
Keywords: relnote
Checking in Bugzilla/DB.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB.pm,v  <--  DB.pm
new revision: 1.128; previous revision: 1.127
done
Checking in contrib/gnats2bz.pl;
/cvsroot/mozilla/webtools/bugzilla/contrib/gnats2bz.pl,v  <--  gnats2bz.pl
new revision: 1.10; previous revision: 1.9
done
Checking in contrib/bugzilla-submit/bugzilla-submit;
/cvsroot/mozilla/webtools/bugzilla/contrib/bugzilla-submit/bugzilla-submit,v  <--  bugzilla-submit
new revision: 1.7; previous revision: 1.6
done
Checking in contrib/gnatsparse/gnatsparse.py;
/cvsroot/mozilla/webtools/bugzilla/contrib/gnatsparse/gnatsparse.py,v  <--  gnatsparse.py
new revision: 1.6; previous revision: 1.5
done
Checking in template/en/default/pages/fields.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/pages/fields.html.tmpl,v  <--  fields.html.tmpl
new revision: 1.17; previous revision: 1.16
done
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Just as a note, in my installations I always customize the priorities so that they are simple HIGH, MEDIUM, and LOW which I believe correspond to how people use the concept of priorities in spoken english. 

Since I've started doing this I've never had a problem with people choosing priorities for bug reports. Also having only three priorities stops people from wasting there time trying to decide whether something is "urgent" or "showstopper" or "critical". Using simple quantitative terms seems to reduce confusion between Priority and Severity which seems to be the next most commonly misunderstood Bugzilla concept for most users.
(In reply to comment #19)
> Since I've started doing this I've never had a problem with people choosing
> priorities for bug reports. Also having only three priorities stops people from
> wasting there time trying to decide whether something is "urgent" or
> "showstopper" or "critical". Using simple quantitative terms seems to reduce
> confusion between Priority and Severity which seems to be the next most
> commonly misunderstood Bugzilla concept for most users.

  Sweet, good to know. This bug does Highest, High, Normal, Low, Lowest.
Added to the release notes in bug 547466.
Keywords: relnote
I think this fix totally missed the point.
(In reply to comment #22)
> I think this fix totally missed the point.

  I'm sorry. Could you be more clear? The specific point made in the research was that the terms "P1" through "P5" are unclear, and have no meaning to the users. We changed them to values that are clear and have a much more obvious meaning.

  I'm also curious as to why you're particularly interested, since bmo is not using the new terms.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: