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 field. 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. ;o)
Perhaps it makes sense then to display priority but not allow it to be changed then?
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 next year.