| 1 |
On Fri, Feb 5, 2016 at 1:27 PM, Kent Fredric <kentfredric@×××××.com> wrote: |
| 2 |
> On 6 February 2016 at 07:19, Rich Freeman <rich0@g.o> wrote: |
| 3 |
>> 'd be all for automated bug assignment. Usually when this comes up a |
| 4 |
>> bunch of hero bug wranglers step up and say it isn't needed, because |
| 5 |
>> we have hero bug wranglers. As long as people keep stepping up to do |
| 6 |
>> that I'm not going to tell them that they can't. However, if the bug |
| 7 |
>> queue ever does go out of control I'd be all for just auto-assigning |
| 8 |
>> them. If they rarely get assigned to the wrong people, then they can |
| 9 |
>> just reassign them. And nothing stops us from having a bugzilla query |
| 10 |
>> for "new bugs filed in last 24h" for people who want to take a quick |
| 11 |
>> look at recent bugs for trends or to help clean them up across |
| 12 |
>> projects. |
| 13 |
> |
| 14 |
> |
| 15 |
> Hm, or alternatively, you could have a scheme where things defaulted |
| 16 |
> in the bug queue, and were auto-assigned where possible after no |
| 17 |
> feedback for a time, or maybe it would be defaulted only when the |
| 18 |
> queue is over a certain size. |
| 19 |
> |
| 20 |
|
| 21 |
That was my thought around having a query for bugs filed in the last |
| 22 |
24h. Basically they'd be auto-assigned, but people could choose to |
| 23 |
review recent bugs to see if any were mis-assigned, and no action is |
| 24 |
necessary if they're OK. |
| 25 |
|
| 26 |
The main problem I see with auto-assignment is that some asignees end |
| 27 |
up being black holes for bugs. If two active devs get their bugs |
| 28 |
crossed it isn't a big deal since they'll just reassign them to each |
| 29 |
other. If an active dev gets their bug assigned to an inactive dev, |
| 30 |
they might never hear about it. |
| 31 |
|
| 32 |
-- |
| 33 |
Rich |
Archives