Bug 91306 - RFE: Private field for setting developer priority
RFE: Private field for setting developer priority
Product: Bugzilla
Classification: Community
Component: Bugzilla General (Show other bugs)
All Linux
medium Severity medium (vote)
: ---
: ---
Assigned To: David Lawrence
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2003-05-21 02:14 EDT by Mike A. Harris
Modified: 2013-01-10 16:40 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-27 14:48:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mike A. Harris 2003-05-21 02:14:08 EDT
It'd be kind of useful to have a new bugilla field like "Priority", which
is only visible by people in the Red Hat Development category.  With either
a combo box scale from 1 to 5 (1 being high priority, or a text box.  I ignore
the Priority field entirely, as end users are setting "the priority they would
like Red Hat to give this problem" rather than "the priority Red Hat or a
developer at Red Hat assigns to this problem".

We've all played the fight user over priority field enough times that nobody
at all in development likely ever looks at or cares what a reporter has set
the priority field to.

Perhaps even just removing Priority from user visibility and making it private
would be ok.

Then again, I suppose that the Developer whiteboard could sortof be used
for this though without adding a new field or changing the existing Priority

I thought I'd suggest it anyway though, and see what happens.  ;o)
Comment 1 Mike A. Harris 2003-05-21 02:15:10 EDT
Version 2.17.1 actually.  bugzilla's versions are not set in bugzilla right.  ;o)
Comment 2 Paul Gampe 2006-03-06 12:50:37 EST
Dave, we intend to use Priority as part of our planning process for all Red 
Hat products from now on.  Instead of introducing a second priority attribute 
as per Mike's suggestion, could we config bugzilla to: 
a) Only let *@redhat.com set the priority field 
b) Only let *@redhat.com see the priority field 
Does this make sense? 
Comment 3 Mike A. Harris 2006-03-06 16:02:46 EST
Makes sense to me, however users may react negatively to seeing the Priority
field just vanish all of a sudden.  I'm sure there'd be lengthy flamewars on
the mailing lists about it anyway, even though in reality, the priority field
is totally meaningless and unused right now.

Perhaps we should get such a change ready, but not release it yet, and then
wait until the next major controversy kicks up on the lists.  Then make the
change while everyone is arguing about something else.  They wont even notice.

Comment 4 Paul Gampe 2006-03-24 17:38:59 EST
Perhaps it makes sense then to display priority but not allow it to be changed 
Comment 5 Mark J. Cox (Product Security) 2006-03-27 04:54:20 EST
Priority should definately be displayed to all users.
Comment 6 Mike A. Harris 2006-03-27 14:48:42 EST
The existing priority field should remain visible to all users, however if
this new field "Developer priority" is added, it should _not_ be visible
to users, or else it will just generate animosity the same way the existing
Priority field generates animosity if a developer changes the priority of
a bug and the reporter or someone on CC disagrees with it.

If developer priority were to get added, and was end user visible at all,
then I certainly wouldn't ever use the field, as it wouldn't meet the
requirements of what I'm requesting.  ;o)

At any rate, it is questionable wether such field would truly add useful
value to bugzilla even with it being private.  Bugzilla keeps growing more
and more features and fields, and becoming more complicated overall for
different departmental needs.  As such, I hereby withdraw my request for
this field to be added to bugzilla, as it is more of a quick solution to
solve the wrong problem IMHO.

The real problem is to solve the "What is a useful method for developers
to determine which bugs to work on before other bugs." problem.  That
could be stored in bugzilla, in another database, or something like MCP
perhaps.  I'm not sure what other developers do now to solve this problem,
but I generally just scan over lists of bugs every now and then, cherry
picking a handful that seem more important and adding them to a target
tracker of some sort.  That might miss bugs that are actually higher
priority perhaps, but it helps to organize things somewhat nonetheless.

I believe RELENG is tackling this type of problem in their future tools
work anyway, so it'll probably be something that solves itself within the
next year.

Note You need to log in before you can comment on or make changes to this bug.