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

[Ezio Melotti]

On Thu, Dec 7, 2017 at 11:20 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> (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.
>

While most of these suggestions seem to help define the process, ISTM
they are also making it more bureaucratic.

>
> 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"?
>

This can be done (e.g. the famous highscores page we have been talking about).

> 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".
>

With this I agree, and as I mentioned below, I think all core devs
should have the triage bit and know how to use it.

> 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?
>

All core devs should have the triage bit, even though many of them are
only interested in using it for the issues they are working on.
There are however other triagers that just go through the issues and
adjust fields or comment, even if they have no intention of working on
the issue itself.
While it's technically true that there might be people that want to
triage but not contribute code, most of them do contribute, and triage
while going through the issues.

>
> 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.
>

This is a good point, but indeed, how many are contributing with the
goal and hope of becoming core devs?  How many are contributing
because they like the project, and would be happy to become core devs?
 How many are just scratching a itch but otherwise have no desire to
contribute to other aspects of the project?
Finding an answer to these questions might help understanding where
are the problems that need to be addressed.

Best Regards,
Ezio Melotti

> 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
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/