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

[Victor Stinner]

(I tried to answer to all replies. Since I chose to reply in a single
email, so I chose to reply to own initial email.)

Hi,

It seems like I didn't express my ideas with the right words and so
misguided the discussion. I'm sorry about that. I wrote a full
"promotion process" document where I tried to pick better words. For
example, I replaced "award" with "responsibility" ;-)

My email:
https://mail.python.org/pipermail/python-committers/2017-December/005000.html

2017-11-20 19:12 GMT+01:00 R. David Murray <rdmurray at bitdance.com>:
>> 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.

IMHO it's ok remove permissions if we have to. Instead of making such
event abnormal, I proposed a training period of one month when the
permission can be reverted anytime if the contributor misbehaves while
being told to change their behaviour.

I hope that the removal of the permission after the training period will
be exceptional. I also added the need to get a mentor to reduce the risk
even further. The mentor is not responsible of the behaviour of the
contributor, but is here is guide and help the contributor.


R. David Murray <rdmurray at bitdance.com>:
>> 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 :)

To not forget, I created an issue in the devguide project!
https://github.com/python/devguide/issues/308


2017-11-20 19:59 GMT+01:00 Ezio Melotti <ezio.melotti at gmail.com>:
> but we don't have a well defined procedure and sometimes people keep
> contributing for weeks before someone realizes they could become
> triagers.

Aha. Maybe we need some tooling, like statistics on contributions to the
bug tracker, just to detect earlier active "bug triagers"?

On Git, it's simpler, there already many tools computing statistics on
the number of commits.


2017-12-06 18:45 GMT+01:00 Ezio Melotti <ezio.melotti at gmail.com>:
> Depends on what you exactly mean with "award".  Contributors might
> want to be able to edit more fields on the tracker, and the triage bit
> allows them to do it.  This is beneficial for both the contributor and
> the other triagers, since they have one more helping hand. (...)

Here is where I failed the most to explain myself.

If you consider that the long term goal is to train contributors to
become core developers, bug triage is just one of the task and
responsibility of a core developer.  To exagerate, you cannot become a
core developer if you don't know how to triage bugs properly.

In my point of view, giving the bug triage permission is first a new
responsibility, not a permission or an "award". The contributor becomes
able to make bigger mistakes and so must be careful. The idea is to give
permissions and responsibilities step by step to contributors, rather
than giving them as once as the "core developer package".

To come back to bug triage itself, obviously, the permission gives
access to features not available to regular contributors, and so allows
to better triage bugs.


2017-12-06 19:45 GMT+01:00 Ned Deily <nad at python.org>:
> In general, I agree with David's and Ezio's comments, in particular
> the idea that "bug triage" should not be an "award" nor a necessary
> first step towards being a committer.  I think the skills necessary to
> be a good bug triager are not the same as being a good core developer.
> While the skill sets and experience level needed can overlap, I think
> we should consider the two roles as separate "career paths".  In other
> words, some people would do a fine job as triager without wanting to
> be a core developer or contributing their own code patches, and that's
> fine.

I agree and like the idea of contributors who enjoy bug triage without
wanting to contribute to the code.

But technically, when I say "bug triage permission", I understand at
least being able to close a bug. It would be annoying if a core
developer doesn't get this permission and so would be unable to close a
bug once a fix is pushed, no?


2017-12-06 20:37 GMT+01:00 Terry Reedy <tjreedy at udel.edu>:
> I agree.  Database maintenance is a separate skill and interest from
> the 3 skills of patch writing, reviewing, and merging.  Committers
> need to be able to maintain and ultimately close the issues they work
> on, but need not engage in general tracker gardening.

While I agree that core developers are not *required* to triage bugs, I
consider that it's a responsibility shared by core developers to take
care of the bug tracker.

As I consider that core developers should review pull requests, not only
produce pull requests, and that's one of the difference I see between a
regular contributor and a core developer. Again, I wouldn't say that
it's a hard requirements, more a best effort responsibility ;-)


2017-12-06 23:35 GMT+01:00 Antoine Pitrou <antoine at python.org>:
> I wonder: is this the right question to ask?  There are contributors
> who will never become core developers.  It's not a failure.  How many
> of us actually hoped or expected to become a core developer when they
> started contributing?

My hope is that many contributors are potential core developers but were
stuck somewhere, and failed to get the right documentation or mentor to
unblock them.

Being a core developer is expensive of term of time and energy, and too
few people have time and energy for that. I am trying to increase our
chances to get more candidates by making the path smoother and simpler,
and by making the core developer sub-community a more warmly welcome
place.


2017-12-06 23:35 GMT+01:00 Antoine Pitrou <antoine at python.org>:
> The real issue is not that the step is hard to climb, but that it is
> hard to get people interested in climbing that step (and continue
> being active afterwards, even though the step has been climbed).  It
> is to get people interested in the tasks and responsibilities
> (sometimes annoyances) of being a core developer.

In the "promotion process" documentation that I wrote, I now tried to
insist on responsibilities over "additional permissions". Some people
coming to me want to become a core developer without being aware of the
disadvantages like the list of responsibilities. I am not sure that they
have enough "free time" nor be ready to take these responsibilities.


> Yes, so it's more a question of giving them the tools necessary to do
> what they want to do.  Not of giving them an award or a privilege :-)

I'm not sure that I got your point. For example, for the bug tracker, do
you mean that we should allow anyone to close bugs to let regular
contributors triage bugs?


2017-12-07 0:39 GMT+01:00 Antoine Pitrou <antoine at python.org>:
> Therefore, we should strive to attract more contributors in the hope
> that the number of core developers selected out of those contributors
> will also increase.

Over the last 9 months, Stéphane Wirtel accounted 586 different
contributors (who got pull requests merged). I'm not sure that we have a
real issue with the number of contributors.


2017-12-07 4:36 GMT+01:00 Berker Peksağ <berker.peksag at gmail.com>:
> Giving people an 'award' early may risk introducing unnecessary noise
> on tracker. I understand that it's not end of the world, but note that
> every wrong action needs to be reverted by another volunteer.

I understand and agree with your point. There is a real risk of giving
permissions without any kind of control. I adjusted my proposal by now
requiring a mentor when someone gets the bug triage permission.

Moreover, as I wrote previously, the permission will come with a
training periof of 1 month when the permission can be reverted anytime
if the contributor continue to mishave after having been told to change
their behaviour.

Would you feel more confortable with these two guards? A mentor and the
ability to quickly revert the permission if needed.

See my full "promotion process" for the details of the role of the
mentor in that case.


Victor