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)
Version 2.17.1 actually. bugzilla's versions are not set in bugzilla right. ;o)
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?
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.
Perhaps it makes sense then to display priority but not allow it to be changed
Priority should definately be displayed to all users.
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