Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2016-02-14

[Andrew Savchenko <bircoph@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 4001 bytes --]

Hi all,

On Mon, 1 Feb 2016 20:25:20 +0100 Justin Lecher (jlec) wrote:
> Dear all,
> 
> the Gentoo Council will meet again on Sunday, February 14 at 19:00 UTC
> in #gentoo-council on FreeNode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.

I'd like to ask the Council on the matter of bugs assignment
automation. The issue is discussed in the following thread:

https://archives.gentoo.org/gentoo-dev/message/c9675f0359679007054b57de123c0bf3

The first question: Should we automate bugs assignment if one and
only one valid "category/package" is present in the bug's title?

1. Yes, automate assignment of all new bugs.
2. Yes, but only allow such automation for users with bug
assignment capabilities (e.g. put a button for bug-wranglers).
3. No, keep current status quo.

The second question (only if answers 1 or 2 were selected for the
first question): Should we automate assignment for bugs with
multiple maintainers?

1. Yes, assign to the first maintainer, CC all other.
2. No, leave this bugs to bug-wranglers.

The third question (only if answer 1 was selected for the first
question): For bugs that will be automated should automation be
delayed so, that bug wranglers will have an opportunity to review
such bugs?

1. Yes, delay bugs assignment for N day(s). (N is to be
determined by the Council as well.)
2. No, assign them immediately.  

***************************************************************

Summary of opinions (excuse me if I missed something) (roman
numerals stands for the question number, question/answer format):

I/1
Pros: 
  a) We save a lot of the manpower.
  b) Latency of bugs handling will be decreased.
Cons:
  a) In some corner cases it is possible that bugs will be
improperly assigned and due to inactive developers they may be never
be properly assigned.
  b) Incomplete bug reports will be occasionally assigned to
developers (e.g. with missing emerge --info or build logs), thus
developers will have to request such information themselves. 

I/2
Pros: 
  a) Human check of bugs will reduce error rate for corner cases
or incomplete bug reports which automation can't handle properly.
  b) We still save some manpower (e.g. reduce load on
bug-wranglers).
Cons:
  a) We loose a lot of man-power.
  b) Latency of bugs assignment and thus handling is increased.

I/3
Pros:
  a) Keep current well-known more-or-less working state of matters.
Cons:
  a) A huge load on bug-wranglers, most (all?) of them are devs
which can spend their time to actually fix bugs.
  b) Large latency of bugs assignment (may be more than a
week for some bugs and several days in general) is kept.

II/1
Pros:
  a) A large number of packages contains multiple maintainers, so
including them into automation process will sufficiently increase
effectiveness of the automation.
  b) This approach already works well for tinderbox ran by Toralf
Förster (we have a lot of good bug reports by this tinderbox).
Cons:
  a) It is rare but possible that first maintainer is not the
recepient where bugs should be assigned, thus real assignee will be
in the CC.

II/2
Pros:
  a) Probability of bug assignment (versus CC'ing) to the wrong
maintainer is eliminated.
Cons:
  a) A whole lot of packages is excluded from the automation
process.

III/1
Pros:
  a) Probability of catching incomplete reports or wrong bug
assignments by the human being is increased.
Cons:
  b) Burden on bug-wranglers is increased considerably.
  c) Latency of bugs assignment and handling is increased.

III/2
Pros:
  a) We save a lot of manpower for actual Gentoo development.
  b) Zero latency in assignment may lead to faster bugs resolving
and improved user experience.
Cons:
  a) In corner cases bugs may be misassigned.
  b) If bugs are not complete, developers will have to request
required information themselves.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]