| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
On 02/05/2016 03:47 PM, Rich Freeman wrote: |
| 5 |
> On Fri, Feb 5, 2016 at 1:27 PM, Kent Fredric |
| 6 |
> <kentfredric@×××××.com> wrote: |
| 7 |
>> On 6 February 2016 at 07:19, Rich Freeman <rich0@g.o> |
| 8 |
>> wrote: |
| 9 |
>>> 'd be all for automated bug assignment. Usually when this |
| 10 |
>>> comes up a bunch of hero bug wranglers step up and say it isn't |
| 11 |
>>> needed, because we have hero bug wranglers. As long as people |
| 12 |
>>> keep stepping up to do that I'm not going to tell them that |
| 13 |
>>> they can't. However, if the bug queue ever does go out of |
| 14 |
>>> control I'd be all for just auto-assigning them. If they |
| 15 |
>>> rarely get assigned to the wrong people, then they can just |
| 16 |
>>> reassign them. And nothing stops us from having a bugzilla |
| 17 |
>>> query for "new bugs filed in last 24h" for people who want to |
| 18 |
>>> take a quick look at recent bugs for trends or to help clean |
| 19 |
>>> them up across projects. |
| 20 |
>> |
| 21 |
>> |
| 22 |
>> Hm, or alternatively, you could have a scheme where things |
| 23 |
>> defaulted in the bug queue, and were auto-assigned where possible |
| 24 |
>> after no feedback for a time, or maybe it would be defaulted only |
| 25 |
>> when the queue is over a certain size. |
| 26 |
>> |
| 27 |
> |
| 28 |
> That was my thought around having a query for bugs filed in the |
| 29 |
> last 24h. Basically they'd be auto-assigned, but people could |
| 30 |
> choose to review recent bugs to see if any were mis-assigned, and |
| 31 |
> no action is necessary if they're OK. |
| 32 |
> |
| 33 |
> The main problem I see with auto-assignment is that some asignees |
| 34 |
> end up being black holes for bugs. If two active devs get their |
| 35 |
> bugs crossed it isn't a big deal since they'll just reassign them |
| 36 |
> to each other. If an active dev gets their bug assigned to an |
| 37 |
> inactive dev, they might never hear about it. |
| 38 |
> |
| 39 |
|
| 40 |
As an alternative to bug assignment, which does carry the risk of |
| 41 |
"black holes," what about automatic bug CC'ing? That gives the likely |
| 42 |
party the heads up, and if they don't take it, wranglers take over and |
| 43 |
determine what to do with it. This gives us some degree of automation |
| 44 |
(automatic notification, but not sorting), and leaves in the space for |
| 45 |
the wranglers, who I believe are important to getting things where |
| 46 |
they need to be effectively. |
| 47 |
|
| 48 |
- -- |
| 49 |
NP-Hardass |
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v2 |
| 52 |
|
| 53 |
iQIcBAEBCAAGBQJWtb6SAAoJEBzZQR2yrxj7n6IQAIcEmhkIUUie4u6DsodgCRSc |
| 54 |
qnP5cqR9C/0EyXZwQwbntX6Zh18MoFS9/VqQt9kHwFiuqsJaNoxZVMaofM58dwq+ |
| 55 |
BZN5kq4qVO3TI9gp3D4Y4PlzjnYvOg7eiEPRyHy02ZTvJ/Hjhq4wC2VhIKoTF3EF |
| 56 |
L5NKqWebwOre62xCHWeCM0EJGrTj/j/ggSrTjMMrpF/iRJM880IA4j+Nqr3CwLkB |
| 57 |
jH7uM2b2fgjDiyztwKdk90yspax/CBBG0F/XGyuj2bO4BaCCHFD8xDj8lLALkneJ |
| 58 |
D/ihRjNMkgHW6gHRXhrUfABPFEGULadpXKFt/G7RWi0hcn5fjuoRpaoA8k0z/8wl |
| 59 |
YxhQFPdTtfgiQhiL2q5wogSzwXbiliWQDeonBnboC+CKqxByEumOYi05jXgGbBx7 |
| 60 |
mPUcdjKmePbbM4SW/WPbr57HTdMZ2G70EFlg5UNGNN4phvX7T2tz3fiCRLqiO1nm |
| 61 |
UTbykpwACnVTcWmNFgWD11xg4oISr8kxcoql86bwFJdT3fVGedLNwOE3f6YRryZC |
| 62 |
mxt/PbqVHiVuFsZTgLHC/NdV52DD9QQhBDaBxZnQKazPDaqVbNyM6fbwf54xDRbZ |
| 63 |
fO+ZrKix2n+n+aE8bUBmJQ66v8+upBKOSzIu741bW4eKAYdF8+9iJKRVKEhT6Mx2 |
| 64 |
efg+xYoIkEtrJTKTdKNG |
| 65 |
=iylA |
| 66 |
-----END PGP SIGNATURE----- |
Archives