[python-committers] Requirements to get the "bug triage" permission?

[Ezio Melotti]

On Mon, Nov 20, 2017 at 10:12 AM, R. David Murray <rdmurray at bitdance.com> wrote:
>
> On Mon, 20 Nov 2017 18:54:50 +0100, Victor Stinner <victor.stinner at gmail.com> wrote:
> > I identified some active contributors and I would like to offer them
> > to get the "bug triage" permission. What's the requirements to give
> > such permissions to someone?
>
> Currently it is "someone with the power to do it decides to give it out".
> Should we have more detailed/conscious requirements?  Perhaps so.
>
> > IMHO the requirements are quite low:
> >
> > * at least one commit merged in Python
> > * signed the CLA
>
> I have never looked for either of these when giving out triage.  I can
> see that having signed the CLA is probably a good idea, but I see no
> reason to have getting a patch merged be a requirement.
>

Both those requirements shouldn't strictly be necessary (triaging
shouldn't be covered by the CLA), however people that are interested
in triaging often made previous contributions and signed the CLA
already.  I wouldn't be against requiring the CLA to be signed as a
requirement.

> > * be nice and respectful
> > * don't close a bug if it's not well understood to not "loose"
> > information (closed bugs are ignored in search by default, and hidden
> > from the main page).
>
> Personally my criteria is heavy on "be nice and respectful", coupled
> with observing that they have posted comments on issue that demonstrate
> an understanding of our code culture...specifically, commenting that a bug
> should be closed (and why) and I agree with them, and demonstrating an
> understanding of what python versions a bug applies to (enhancement
> versus bug fix, when to backport a bug fix and when not).
>
> How it generally works for me is that I think, "this person knows
> what they are talking about, they ought to be able to close this issue
> themselves instead of my having to do it for them".  Then I pull up a
> list of all the issues they are nosy on, and look at their comments to
> see if they are consistently polite and respectful, know what they are
> talking about, and explain their reasoning well.  If I don't see any
> red flags, I give them triage.
>

+1
A good triager must be familiar with our codebase, our bug tracker,
and our "code culture", in particular:
* being able to find (or remember) duplicate and related issues, link
them to each other, and closing the duplicates as necessary;
* being able to correctly select the versions affected by the issue,
the components, the stage, and other fields;
* being able to verify if the issue can be reproduced and if the
report is valid or not;
* being able to recognize commonly reported issues and link to the
appropriate FAQ or other existing issues/explanations;
* being able to identify and specify the next step, possibly
suggesting which files should be updated to fix the issue;
* being able to locate the commits that might have introduced the
issue, and the reason for the change;
* being able to leave meaningful opinions on the issue (e.g. whether
it should be addressed or closed and why);

It usually takes some time and a few contributions before people can
do these things, and by the time they do, they usually get noticed by
other core devs.
By that time, either they ask for more power themselves, or a core dev
asks them if they would like to become triagers, but we don't have a
well defined procedure and sometimes people keep contributing for
weeks before someone realizes they could become triagers.

To avoid this, we can either:
1) let contributors know that they could ask for more power if they
think they can handle it;
2) be more proactive and check regularly if there are contributors
deserving of more power;

Best Regards,
Ezio Melotti

> > Did it happen in the past that we removed the bug triage permission to
> > someone who abused this power?
>
> Only once that I'm aware of.
>
> > Maybe we can give some guide lines on how to behave on the bug tracker?
>
> Enhance the bug triage section of the devguide, by all means :)
>
> --David