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

[Victor Stinner]

2018-01-25 15:18 GMT+01:00 Jesus Cea :
> On 06/12/17 23:17, Victor Stinner wrote:
>> My problem is that we don't have a long list of "awards" in Python:
>> the triage bit and the commit bit...
>>
>> I had some ideas to create badges, but before I come with something
>> concrete, I'm trying to build something with what we already have ;-)
>
> I have been a few weeks thinking about OpenBadges and CPython
> development. Not for gamification but for recognition.
>
> In the mood to consider this?

Hi Jesus,

Which kind of badges do you suggest?

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Jesus Cea]

On 06/12/17 23:17, Victor Stinner wrote:
> My problem is that we don't have a long list of "awards" in Python:
> the triage bit and the commit bit...
> 
> I had some ideas to create badges, but before I come with something
> concrete, I'm trying to build something with what we already have ;-)

I have been a few weeks thinking about OpenBadges and CPython
development. Not for gamification but for recognition.

In the mood to consider this?

-- 
Jesús Cea Avión _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
Twitter: @jcea_/_/_/_/  _/_/_/_/_/
jabber / xmpp:j...@jabber.org  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Ezio Melotti]

On Fri, Dec 8, 2017 at 5:32 PM, Victor Stinner  wrote:
> 2017-12-08 17:19 GMT+01:00 Ezio Melotti :
>>> 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).
>
> My opinion on such statistics is that they must not be public. I don't
> want to reward the highest number of contributions. As I wrote in the
> process documentation, what matters is the quality and kind of the
> contributions, and also the commitment.
>
> But a private tool, only accessible to core dev for example, would
> easy the work of identifying active contributors.
>

It doesn't necessarily have to be based solely on number of
contribution.  Twisted uses a formula that rewards different kind of
contributions differently.  In theory there could also be different
leaderboards based on number of commits, lines of code, PR submitted,
reviews done, PR/issues closed, etc.  I trust that if we ever get
around implementing this, the contributors won't abuse it, and to
prevent that we can simply add a line saying something like "The
number of contribution doesn't take into account the quality or the
complexity of the contributions.".
I don't think it should be private, as one of its main purposes is to
recognize the work of the contributors, not only by us, but also by
themselves and other contributors.

>
>> 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.
>
> Hum, as Ned Deily wrote, some people don't want to become core
> developers and are fine to contribute as regular contributors. I
> should clarify this in the document.
>
> By the way, since the migration to Git and GitHub, contributing
> without being a core dev became simpler IMHO.
>
>
>>> 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.
>
> Ow, these are tricky questions! Maybe a poll sent to contributors, or
> to python-dev, would help?
>
> Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Victor Stinner]

2017-12-08 17:19 GMT+01:00 Ezio Melotti :
>> 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).

My opinion on such statistics is that they must not be public. I don't
want to reward the highest number of contributions. As I wrote in the
process documentation, what matters is the quality and kind of the
contributions, and also the commitment.

But a private tool, only accessible to core dev for example, would
easy the work of identifying active contributors.


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

Hum, as Ned Deily wrote, some people don't want to become core
developers and are fine to contribute as regular contributors. I
should clarify this in the document.

By the way, since the migration to Git and GitHub, contributing
without being a core dev became simpler IMHO.


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

Ow, these are tricky questions! Maybe a poll sent to contributors, or
to python-dev, would help?

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Ezio Melotti]

On Thu, Dec 7, 2017 at 11:20 PM, Victor Stinner
 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 :
>>> 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 :
>>> 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 :
>> 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 :
>> 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 :
>> 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 

Re: [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 :
>> 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 :
>> 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 :
> 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 :
> 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 :
> 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 :
> 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 :
> I wonder: is this the right question to ask?  There are 

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

[Carol Willing]

> On Dec 6, 2017, at 5:39 PM, Antoine Pitrou  wrote:
> 
> 
> 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.
> 

Some very good discussion and points are being made here.

Bravo to Victor (and Ezio as well as others) for taking the initiative to 
foster contributors and recognizing / thanking them for their contributions. I 
think what Antoine pointed out about having the tools / permissions to be 
effective at contributing in whatever capacity is also very important. 

Having recognition without the tools or tools without recognition isn't 
optimal. Having both leads to the greatest likelihood for future contributions 
from an individual. Feeling valued and being effective are both critical to 
keeping a contributor engaged in the community. 

> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Antoine Pitrou]

Le 07/12/2017 à 00:00, Victor Stinner a écrit :
> 2017-12-06 23:35 GMT+01:00 Antoine Pitrou :
>> 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.
> 
> What do you propose?

I would like to propose the following postulate: given a certain number
of contributors, only a small fraction of them (for example 10%) is
actually interested in becoming a core developer and handling the
responsibilities thereof.  We cannot really increase that fraction as it
is tied to personal factors (time, motivation).

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.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Antoine Pitrou]

Le 06/12/2017 à 23:06, Victor Stinner a écrit :
> 
> My initial problem is the huge gap between "regular contributor" and
> "core developer". Currently, we have a single huge step which is very
> hard to climb.

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?

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.

> It's not because you give the commit bit contributors that they will
> become very active. My expectation is more than giving more priviledge
> would motive them to become move active.

I don't think the latter works any better than the former :-)

> A contributor without the triage priviledge cannot triage bugs...

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 :-)

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Victor Stinner]

2017-12-06 18:45 GMT+01:00 Ezio Melotti :
> Depends on what you exactly mean with "award".

See my reply to David.


> If the contributor knows what they are doing and they
> are helpful, we can "award" them with the triager bit, but this award
> shouldn't be given for unrelated accomplishments.

My problem is that we don't have a long list of "awards" in Python:
the triage bit and the commit bit...

I had some ideas to create badges, but before I come with something
concrete, I'm trying to build something with what we already have ;-)


> Becoming a triager is a step to becoming a committer: we bestow them
> with some responsibility and trust, and if they do well, we can give
> them even more with the committer bit.

Oh, this is exactly my intent. Sorry if I picked the wrong words :-p

I promoted Cheryl Sabella and Sanyam Khurana to encourage them to
become even more active ;-)

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Victor Stinner]

2017-12-06 18:41 GMT+01:00 R. David Murray :
> s/loose/lose/

Oops, fixed, thanks.

>> So do you think that it's bad idea to use triage as an award? Or is it
>> just a matter of adjusting requirements?
>
> Yes I think it is a bad idea to "use it" as an award.  It is not an
> award, it is a functional set of privileges.  It *can be* part of the
> on-boarding process for a contributor who eventually becomes a core dev,
> though, and in that path it functions as an award of sorts.

My initial problem is the huge gap between "regular contributor" and
"core developer". Currently, we have a single huge step which is very
hard to climb.

I'm trying to create new smaller steps and describe each step. The
goal is to have a clear path with requirements for each step.

Before becoming a core developer, I see bug triage as a first step.

I already proposed on this step to add a second step before core
developer: getting a mentor.

Newcomer => contributor => bug triage => getting a mentor => core developer

It would help to have sub-steps, but it can be adjusted later ;-)


>> I have a few people in mind that I would like to give them triage
>> permission, but I don't know that they contributed much to the bug
>> tracker. I don't expect them to be active on the bug tracker neither.
>
> It they are not going to be active on the bug tracker, why do you want
> to give them triage permissions?  If they haven't been active at least
> a little bit on the bug tracker, how do you know they are good candidate
> to be a triager?
>
> What do they need the privileges for?  I'm not necessarily saying they
> shouldn't get them, I want to explore the why in order to inform this
> discussion.  But, if you just want to give it to them as an award and
> for no other reason, I'd vote no.  If you want a badge to give them,
> maybe we make up a badge ;)

It's not because you give the commit bit contributors that they will
become very active. My expectation is more than giving more priviledge
would motive them to become move active.

A contributor without the triage priviledge cannot triage bugs...

I'm not sure that "an award" is the best word sorry. Mariatta already
corrected me when I wrote that becoming a core developer gives more
power, she replied that it gives more *responsabilities*. It's the
same here :-)

By the way, my final goal is to get more people aboard to better scale
horizontal for the Python workflow ;-) I suck at many things in
Python, and I'm very happy to see new "faces" helping on areas where
I'm unable to help. For example, Cheryl Sabella is working on the IDLE
application, whereas I don't know much about Tkinter nor IDLE. But
IDLE is a popular application since it's installed with Python, and
used by teachers. He also likes when other people help on the
documentation since it's a big task and we never have enough hands to
work on the doc!

Does it make any sense to you? :-)

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Terry Reedy]

On 12/6/2017 1:45 PM, Ned Deily wrote:

On Dec 6, 2017, at 12:45, Ezio Melotti  wrote:

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.  If the contributor knows what they are doing and they
are helpful, we can "award" them with the triager bit, but this award
shouldn't be given for unrelated accomplishments.
Becoming a triager is a step to becoming a committer: we bestow them
with some responsibility and trust, and if they do well, we can give
them even more with the committer bit.


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


tjr


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Ezio Melotti]

On Wed, Dec 6, 2017 at 6:11 PM, Victor Stinner  wrote:
> Hi,
>
> Ok, thanks Ezio and David. I completed my list:
> https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker
>
> My initial question is to know if bug triage permission can be seen as
> a first "award" / "badge" to recognize that contributions of someone
> are useful. Contributions can only be made of code pull requests, or
> another "project" tightly coupled to CPython like the documentation,
> the development workflow, etc.
>
> My problem is now that the list of requirements is very long. It's
> like you should already practice triage for weeks before being seen as
> ready to get the triage power.
>
> So do you think that it's bad idea to use triage as an award? Or is it
> just a matter of adjusting requirements?
>

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.  If the contributor knows what they are doing and they
are helpful, we can "award" them with the triager bit, but this award
shouldn't be given for unrelated accomplishments.
Becoming a triager is a step to becoming a committer: we bestow them
with some responsibility and trust, and if they do well, we can give
them even more with the committer bit.

Best Regards,
Ezio Melotti

> I have a few people in mind that I would like to give them triage
> permission, but I don't know that they contributed much to the bug
> tracker. I don't expect them to be active on the bug tracker neither.
>
> Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[R. David Murray]

On Wed, 06 Dec 2017 18:11:44 +0100, Victor Stinner  
wrote:
> Ok, thanks Ezio and David. I completed my list:
> https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker

s/loose/lose/

I would say your list comprises the skills for the "ideal triager" rather
than "good triager", since I think someone can be a good triager without
being and expert in a *all* of the skills you list in that section.
I would expect a triager to develop facility with all those skills,
but not necessarily to have them before they get granted privileges.
(I'd say the second, fourth, fifth, and last are more or less
the minimum to start with, although I'd drop the "which files should
be updated to fix the issue" for that minimum set.)

> My initial question is to know if bug triage permission can be seen as
> a first "award" / "badge" to recognize that contributions of someone
> are useful. Contributions can only be made of code pull requests, or
> another "project" tightly coupled to CPython like the documentation,
> the development workflow, etc.
> 
> My problem is now that the list of requirements is very long. It's
> like you should already practice triage for weeks before being seen as
> ready to get the triage power.
> 
> So do you think that it's bad idea to use triage as an award? Or is it
> just a matter of adjusting requirements?

Yes I think it is a bad idea to "use it" as an award.  It is not an
award, it is a functional set of privileges.  It *can be* part of the
on-boarding process for a contributor who eventually becomes a core dev,
though, and in that path it functions as an award of sorts.

> I have a few people in mind that I would like to give them triage
> permission, but I don't know that they contributed much to the bug
> tracker. I don't expect them to be active on the bug tracker neither.

It they are not going to be active on the bug tracker, why do you want
to give them triage permissions?  If they haven't been active at least
a little bit on the bug tracker, how do you know they are good candidate
to be a triager?

What do they need the privileges for?  I'm not necessarily saying they
shouldn't get them, I want to explore the why in order to inform this
discussion.  But, if you just want to give it to them as an award and
for no other reason, I'd vote no.  If you want a badge to give them,
maybe we make up a badge ;)

--David
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Victor Stinner]

Hi,

Ok, thanks Ezio and David. I completed my list:
https://github.com/vstinner/cpython_core_tutorial/blob/master/core_developer.rst#bug-tracker

My initial question is to know if bug triage permission can be seen as
a first "award" / "badge" to recognize that contributions of someone
are useful. Contributions can only be made of code pull requests, or
another "project" tightly coupled to CPython like the documentation,
the development workflow, etc.

My problem is now that the list of requirements is very long. It's
like you should already practice triage for weeks before being seen as
ready to get the triage power.

So do you think that it's bad idea to use triage as an award? Or is it
just a matter of adjusting requirements?

I have a few people in mind that I would like to give them triage
permission, but I don't know that they contributed much to the bug
tracker. I don't expect them to be active on the bug tracker neither.

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Ezio Melotti]

On Mon, Nov 20, 2017 at 10:12 AM, R. David Murray  wrote:
>
> On Mon, 20 Nov 2017 18:54:50 +0100, Victor Stinner  
> 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
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[R. David Murray]

On Mon, 20 Nov 2017 18:54:50 +0100, Victor Stinner  
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.

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

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

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

[Victor Stinner]

Hi,

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?

On my "Different stages of core developers" "lader", it's the 3rd
stage ("step"?):

http://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_core_developer.html#different-stages-of-core-developers

Requirements to become a core developer (get the "commit bit") are now
written down:

http://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_core_developer.html#requirements-to-become-a-core-developer

It would be nice to write down requirements to get the bug triage permission.


IMHO the requirements are quite low:

* at least one commit merged in Python
* signed the CLA
* 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).

Did it happen in the past that we removed the bug triage permission to
someone who abused this power?

Maybe we can give some guide lines on how to behave on the bug tracker?

Responsability for bug tracker:

* Request more information if a report is incomplete
* Ping original reporters if they don't reply
* Adjust Python version, component, bug type, etc.
* Rewrite the issue title if needed
* Close duplicated bugs as DUPLICATE
* Close irrevelant bugs as NOTABUG

The exact behaviour on the bug tracker is not specified. For example,
when someone asks for help on code, I close the issue and suggest to
use a different forum to get help, without giving examples of forums
(since I simply don't know them :-)).

When the reported issue described a legit Python behaviour, I try to
explain the rationale of the behaviour before closing the issue as
"not a bug".

Sometimes I'm just tired of the 4th bug report on "floating point
rouding issue" and just give the link to the FAQ without explaining
anything.

Devguide §Helping Triage Issues
https://devguide.python.org/tracker/#helptriage

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/