Re: Announcing the new Python triage team on GitHub
Thanks for doing this. I hope it encourages more participation. The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue. ISTM the primary value of having triager is to tag issues appropriately, summon the appropriate experts, and make a first pass at review and/or improvements. FWIW, the definition of the word triage is "in medical use: the assignment of degrees of urgency to wounds or illnesses to decide the order of treatment of a large number of patients or casualties." That doesn't imply making a final disposition. Put another way, the only remaining distinction between a "triager" and a "core developer" is the ability to push the "commit" button. In a way, that is the least interesting part of the process and is often a foregone conclusion by the time it happens. Raymond
Hi, Oh, I just wrote a similar email to python-committers, I didn't notice that Mariatta wrote to python-dev and python-committers. https://mail.python.org/archives/list/python-committers@python.org/message/5... My worry is more about closing pull requests. Le 21/08/2019 à 22:13, Raymond Hettinger a écrit :
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue.
Closing an issue (on GitHub) is not new compared to the previous "Developer" role on bugs.python.org. When I gave the bug triage permission to a contributor, I always warned them that closing an issue is the most risky operation. I asked them to ask me before doing that. In practice, I don't recall a triagger who closed an issue, but someone else complained that the issue should be reopened. In a few specific cases, the original reporter was in disagreement with everybody else and didn't understand why their issue was not a bug and will not be fixed, but it wasn't an issue about triaggers ;-) The risk of closing an issue by mistake is quite low, since the bug remains in the database, it's trivial to reopen. Closed bugs can be found using Google for example (which doesn't care of the bug status), or using bugs.python.org search engine if you opt-in for closed issues (or ignore the open/close status in a search). The topic has been discussed previously (sorry, I don't recall where), and it was said that it's ok to give this permission (close issues) to new triaggers. Now there is the question of giving the "close pull requests" permission to new triaggers ;-) Victor -- Night gathers, and now my watch begins. It shall not end until my death.
I think it's fine for triagers to have the close permission, and there's actually a good reason to give it to them, which is that often the easiest way to trigger a new CI run is to close and re-open a PR. It will be very helpful for triagers to be able to do this to fix intermittent build problems and the like. Even without the "trigger a new CI run" justification, I think the risk we're running by giving people close privileges is pretty minimal. If a PR is erroneously closed, it can just be re-opened. If a triager is consistently misuing /any/ of the permissions they are given, their triage permissions can be removed. Best, Paul On 8/22/19 6:02 AM, Victor Stinner wrote:
Hi,
Oh, I just wrote a similar email to python-committers, I didn't notice that Mariatta wrote to python-dev and python-committers.
https://mail.python.org/archives/list/python-committers@python.org/message/5...
My worry is more about closing pull requests.
Le 21/08/2019 à 22:13, Raymond Hettinger a écrit :
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue.
Closing an issue (on GitHub) is not new compared to the previous "Developer" role on bugs.python.org. When I gave the bug triage permission to a contributor, I always warned them that closing an issue is the most risky operation. I asked them to ask me before doing that.
In practice, I don't recall a triagger who closed an issue, but someone else complained that the issue should be reopened. In a few specific cases, the original reporter was in disagreement with everybody else and didn't understand why their issue was not a bug and will not be fixed, but it wasn't an issue about triaggers ;-)
The risk of closing an issue by mistake is quite low, since the bug remains in the database, it's trivial to reopen. Closed bugs can be found using Google for example (which doesn't care of the bug status), or using bugs.python.org search engine if you opt-in for closed issues (or ignore the open/close status in a search). The topic has been discussed previously (sorry, I don't recall where), and it was said that it's ok to give this permission (close issues) to new triaggers.
Now there is the question of giving the "close pull requests" permission to new triaggers ;-)
Victor
On Thu, Aug 22, 2019, at 6:06 AM, Victor Stinner wrote:
Hi,
Oh, I just wrote a similar email to python-committers, I didn't notice that Mariatta wrote to python-dev and python-committers.
https://mail.python.org/archives/list/python-committers@python.org/message/5...
My worry is more about closing pull requests.
Le 21/08/2019 à 22:13, Raymond Hettinger a écrit :
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue.
Closing an issue (on GitHub) is not new compared to the previous "Developer" role on bugs.python.org. When I gave the bug triage permission to a contributor, I always warned them that closing an issue is the most risky operation. I asked them to ask me before doing that.
In practice, I don't recall a triagger who closed an issue, but someone else complained that the issue should be reopened. In a few specific cases, the original reporter was in disagreement with everybody else and didn't understand why their issue was not a bug and will not be fixed, but it wasn't an issue about triaggers ;-)
The risk of closing an issue by mistake is quite low, since the bug remains in the database, it's trivial to reopen. Closed bugs can be found using Google for example (which doesn't care of the bug status), or using bugs.python.org search engine if you opt-in for closed issues (or ignore the open/close status in a search). The topic has been discussed previously (sorry, I don't recall where), and it was said that it's ok to give this permission (close issues) to new triaggers.
Now there is the question of giving the "close pull requests" permission to new triaggers ;-)
But, is that really any different from being able to close issues with attached patches (in pre-github-era)? What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use them judiciously. Some possible use case of a triager having permissions to close PRs that I can think of is old PRs that are abandoned/don't apply (no replies after repeated pings on the PR). I understand that there are use cases where the abandoned PRs can use some love and be rebased/fixed, but that information links don't go away if the b.p.o issue is still open. A person interested to look for motivation from old implementations can still find the linked PRs from bpo. Or, if the issue/feature request was rejected by a Core Dev in b.p.o or the related b.p.o issue is already closed, it is okay I guess to close the PR, with proper reasoning of course. Especially given that closing an issue doesn't close all the associated PRs.
Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ADUP3UDM...
-- thanks, Abhilash Raj (maxking)
Abhilash Raj wrote:
On Thu, Aug 22, 2019, at 6:06 AM, Victor Stinner wrote:
Hi, Oh, I just wrote a similar email to python-committers, I didn't notice that Mariatta wrote to python-dev and python-committers. https://mail.python.org/archives/list/python-committers@python.org/message/5... My worry is more about closing pull requests. Le 21/08/2019 à 22:13, Raymond Hettinger a écrit : The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue. Closing an issue (on GitHub) is not new compared to the previous "Developer" role on bugs.python.org. When I gave the bug triage permission to a contributor, I always warned them that closing an issue is the most risky operation. I asked them to ask me before doing that. In practice, I don't recall a triagger who closed an issue, but someone else complained that the issue should be reopened. In a few specific cases, the original reporter was in disagreement with everybody else and didn't understand why their issue was not a bug and will not be fixed, but it wasn't an issue about triaggers ;-) The risk of closing an issue by mistake is quite low, since the bug remains in the database, it's trivial to reopen. Closed bugs can be found using Google for example (which doesn't care of the bug status), or using bugs.python.org search engine if you opt-in for closed issues (or ignore the open/close status in a search). The topic has been discussed previously (sorry, I don't recall where), and it was said that it's ok to give this permission (close issues) to new triaggers. Now there is the question of giving the "close pull requests" permission to new triaggers ;-) But, is that really any different from being able to close issues with attached patches (in pre-github-era)?
Nope.
What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use them judiciously.
Correct. I understand where the worry is coming from and I do think it is worth documenting in the devguide for triagers that they should not make design decisions on PRs to the point that they reject PRs by closing them (they can obviously leave an opinion and loop in a core dev to make a decision). But we also have not had a problem with this yet and so I'm not prepared to say we can't have triagers help with labels and closing stale PRs that have not received a timely response over a potential worry. IOW it's something to document and to watch, but I don't think it's something to prevent having triagers over based purely on technical abilities compared to social expectations for which we can remove triage access over. -Brett
Victor Night gathers, and now my watch begins. It shall not end until my death.
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ADUP3UDM... --
Some possible use case of a triager having permissions to close PRs that I can think of is old PRs that are abandoned/don't apply (no replies after repeated pings on the PR). I understand that there are use cases where the abandoned PRs can use some love and be rebased/fixed, but that information links don't go away if the b.p.o issue is still open. A person interested to look for motivation from old implementations can still find the linked PRs from bpo. Or, if the issue/feature request was rejected by a Core Dev in b.p.o or the related b.p.o issue is already closed, it is okay I guess to close the PR, with proper reasoning of course. Especially given that closing an issue doesn't close all the associated PRs. thanks, Abhilash Raj (maxking)
What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use
Abhilash Raj wrote: them
judiciously.
From my understanding, triagers should only close PRs or issues when they are entirely invalid (for non-subjective reasons, such as something that physically can't be merged) or when they are significantly outdated. Closing PRs for anything remotely subjective, such as deciding if a documentation change should be added or if a new feature is actually needed should be only determined by the core developers. Triagers can suggest the closing of those PRs, but a core dev should make the final decision. If a mistake is made (or a triager misuses their permissions), the PR could be reopened. Mistakes are bound to occur at some point, but if a single triager is repeatedly doing so or is clearly misusing their permissions, they should be removed. Also, there's not an easy way for us to customize the exact permissions to prevent triagers from being able to close issues, we are limited the template permissions that GitHub laid out in https://help.github.com/en/articles/repository-permission-levels-for-an-orga... under Triage (beta). So, it's kind of an all or nothing deal. There's also some minor things that we can't do that would be helpful, such as the ability to directly edit PR titles or adding reviewers. For more details, there was a topic on Discuss addressing this: https://discuss.python.org/t/permissions-for-the-python-traige-team/2191. Brett Cannon wrote:
closing stale PRs that have not received a timely response
Is there any existing criteria for roughly defining a "stale PR" that should be closed, or what you would personally consider to be a "timely response"? So far, I've avoided doing this as I didn't want to accidentally close anything that could still be valid or useful. My idea of a stale PR would be something that hasn't received a response or comment for 3+ months, hasn't been updated in two or more releases prior to the latest development one, or was recreated. An obvious candidate I can think of would be this one: https://github.com/python/cpython/pull/117, as it has been awaiting changes since Feb 20, 2018 and was recreated here: https://github.com/python/cpython/pull/14976. Even if it hadn't been recreated, I think it would still be a good example as of a stale PR, since it had changes requested for over a year with no response from the author since then. Regards, Kyle Stanley On Thu, Aug 22, 2019 at 2:25 PM Brett Cannon <brett@python.org> wrote:
On Thu, Aug 22, 2019, at 6:06 AM, Victor Stinner wrote:
Hi, Oh, I just wrote a similar email to python-committers, I didn't notice that Mariatta wrote to python-dev and python-committers.
https://mail.python.org/archives/list/python-committers@python.org/message/5. ..
My worry is more about closing pull requests. Le 21/08/2019 à 22:13, Raymond Hettinger a écrit : The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has
reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue. Closing an issue (on GitHub) is not new compared to the previous "Developer" role on bugs.python.org. When I gave the bug triage permission to a contributor, I always warned them that closing an issue is the most risky operation. I asked them to ask me before doing that. In practice, I don't recall a triagger who closed an issue, but someone else complained that the issue should be reopened. In a few specific cases, the original reporter was in disagreement with everybody else and didn't understand why their issue was not a bug and will not be fixed, but it wasn't an issue about triaggers ;-) The risk of closing an issue by mistake is quite low, since the bug remains in the database, it's trivial to reopen. Closed bugs can be found using Google for example (which doesn't care of the bug status), or using bugs.python.org search engine if you opt-in for closed issues (or ignore the open/close status in a search). The topic has been discussed previously (sorry, I don't recall where), and it was said
it's ok to give this permission (close issues) to new triaggers. Now there is the question of giving the "close pull requests"
Abhilash Raj wrote: traditionally been that permission
to new triaggers ;-) But, is that really any different from being able to close issues with attached patches (in pre-github-era)?
Nope.
What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use them judiciously.
Correct. I understand where the worry is coming from and I do think it is worth documenting in the devguide for triagers that they should not make design decisions on PRs to the point that they reject PRs by closing them (they can obviously leave an opinion and loop in a core dev to make a decision). But we also have not had a problem with this yet and so I'm not prepared to say we can't have triagers help with labels and closing stale PRs that have not received a timely response over a potential worry.
IOW it's something to document and to watch, but I don't think it's something to prevent having triagers over based purely on technical abilities compared to social expectations for which we can remove triage access over.
-Brett
Some possible use case of a triager having permissions to close PRs that I can think of is old PRs that are abandoned/don't apply (no replies after repeated pings on the PR). I understand that there are use cases where the abandoned PRs can use some love and be rebased/fixed, but that information links don't go away if the b.p.o issue is still open. A person interested to look for motivation from old implementations can still find the linked PRs from bpo. Or, if the issue/feature request was rejected by a Core Dev in b.p.o or the related b.p.o issue is already closed, it is okay I guess to close the PR, with proper reasoning of course. Especially given that closing an issue doesn't close all the associated PRs.
Victor Night gathers, and now my watch begins. It shall not end until my death.
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at
--
https://mail.python.org/archives/list/python-dev@python.org/message/ADUP3UDM. .. thanks, Abhilash Raj (maxking)
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TCV2FLY6...
Kyle Stanley wrote:
as it has been awaiting changes since Feb 20, 2018
Clarification: The author addressed the suggested changes on Feb 19, 2017 but had made no response after Brett added the ``awaiting changes`` label. As a related question, would it be okay for triagers to manually add the "awaiting changes" label on PRs that are suspected to be stale? I think there are some obvious cases where it wouldn't be required (no response from the author in over a year), but this might be an effective way of addressing more recently inactive PRs (2-3+ months). If the author doesn't respond within a month after the label is added, the PR could be closed. On Thu, Aug 22, 2019 at 5:56 PM Kyle Stanley <aeros167@gmail.com> wrote:
What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use
Abhilash Raj wrote: them
judiciously.
From my understanding, triagers should only close PRs or issues when they are entirely invalid (for non-subjective reasons, such as something that physically can't be merged) or when they are significantly outdated. Closing PRs for anything remotely subjective, such as deciding if a documentation change should be added or if a new feature is actually needed should be only determined by the core developers.
Triagers can suggest the closing of those PRs, but a core dev should make the final decision. If a mistake is made (or a triager misuses their permissions), the PR could be reopened. Mistakes are bound to occur at some point, but if a single triager is repeatedly doing so or is clearly misusing their permissions, they should be removed.
Also, there's not an easy way for us to customize the exact permissions to prevent triagers from being able to close issues, we are limited the template permissions that GitHub laid out in https://help.github.com/en/articles/repository-permission-levels-for-an-orga... under Triage (beta). So, it's kind of an all or nothing deal. There's also some minor things that we can't do that would be helpful, such as the ability to directly edit PR titles or adding reviewers. For more details, there was a topic on Discuss addressing this: https://discuss.python.org/t/permissions-for-the-python-traige-team/2191.
Brett Cannon wrote:
closing stale PRs that have not received a timely response
Is there any existing criteria for roughly defining a "stale PR" that should be closed, or what you would personally consider to be a "timely response"? So far, I've avoided doing this as I didn't want to accidentally close anything that could still be valid or useful.
My idea of a stale PR would be something that hasn't received a response or comment for 3+ months, hasn't been updated in two or more releases prior to the latest development one, or was recreated. An obvious candidate I can think of would be this one: https://github.com/python/cpython/pull/117, as it has been awaiting changes since Feb 20, 2018 and was recreated here: https://github.com/python/cpython/pull/14976. Even if it hadn't been recreated, I think it would still be a good example as of a stale PR, since it had changes requested for over a year with no response from the author since then.
Regards, Kyle Stanley
On Thu, Aug 22, 2019 at 2:25 PM Brett Cannon <brett@python.org> wrote:
On Thu, Aug 22, 2019, at 6:06 AM, Victor Stinner wrote:
Hi, Oh, I just wrote a similar email to python-committers, I didn't notice that Mariatta wrote to python-dev and python-committers.
https://mail.python.org/archives/list/python-committers@python.org/message/5. ..
My worry is more about closing pull requests. Le 21/08/2019 à 22:13, Raymond Hettinger a écrit : The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has
reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue. Closing an issue (on GitHub) is not new compared to the previous "Developer" role on bugs.python.org. When I gave the bug triage permission to a contributor, I always warned them that closing an issue is the most risky operation. I asked them to ask me before doing that. In practice, I don't recall a triagger who closed an issue, but someone else complained that the issue should be reopened. In a few specific cases, the original reporter was in disagreement with everybody else and didn't understand why their issue was not a bug and will not be fixed, but it wasn't an issue about triaggers ;-) The risk of closing an issue by mistake is quite low, since the bug remains in the database, it's trivial to reopen. Closed bugs can be found using Google for example (which doesn't care of the bug status), or using bugs.python.org search engine if you opt-in for closed issues (or ignore the open/close status in a search). The topic has been discussed previously (sorry, I don't recall where), and it was said
it's ok to give this permission (close issues) to new triaggers. Now there is the question of giving the "close pull requests"
Abhilash Raj wrote: traditionally been that permission
to new triaggers ;-) But, is that really any different from being able to close issues with attached patches (in pre-github-era)?
Nope.
What I am coming from is that what one has permissions to do and what one should do has been different. We caution people with permissions to use them judiciously.
Correct. I understand where the worry is coming from and I do think it is worth documenting in the devguide for triagers that they should not make design decisions on PRs to the point that they reject PRs by closing them (they can obviously leave an opinion and loop in a core dev to make a decision). But we also have not had a problem with this yet and so I'm not prepared to say we can't have triagers help with labels and closing stale PRs that have not received a timely response over a potential worry.
IOW it's something to document and to watch, but I don't think it's something to prevent having triagers over based purely on technical abilities compared to social expectations for which we can remove triage access over.
-Brett
Some possible use case of a triager having permissions to close PRs that I can think of is old PRs that are abandoned/don't apply (no replies after repeated pings on the PR). I understand that there are use cases where the abandoned PRs can use some love and be rebased/fixed, but that information links don't go away if the b.p.o issue is still open. A person interested to look for motivation from old implementations can still find the linked PRs from bpo. Or, if the issue/feature request was rejected by a Core Dev in b.p.o or the related b.p.o issue is already closed, it is okay I guess to close the PR, with proper reasoning of course. Especially given that closing an issue doesn't close all the associated PRs.
Victor Night gathers, and now my watch begins. It shall not end until my death.
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at
--
https://mail.python.org/archives/list/python-dev@python.org/message/ADUP3UDM. .. thanks, Abhilash Raj (maxking)
Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TCV2FLY6...
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration.
If most core devs prefer that triagers don't ever close PR/issue, then let's document that and let the triagers know of these boundaries. I'd like to be able to trust the triagers and let them help us, instead of restricting their movement. Personally I think it's ok for them to close PR/issue, especially invalid ones. That's why we need help. If a core dev disagree with the decision, it is easy enough to re-open the PR. Anyways, I have created a devguide issue for documenting the guidelines/ethiquette for closing PR/issue: https://github.com/python/devguide/issues/527 Our bar for becoming a triager is somewhat low, It still requires earning trust from at least one core developer who will approve their request, which I don't actually believe is an easy thing to do. is it possible to adjust permissions in
the Python project?
Nothing we can do. You can try contacting GitHub about it. My worry is that it *might* require more trust in a
contributor before giving them the triager role.
Yes, but I don't see this as a bad thing. If we want to make it more strict by saying at least 2 or more core devs approving, that's ok with me too. We could, if we really really really wanted to. Any of the bots can
be programmed to look for closed PRs from people in triage team (and not the author of the PR) and make policy decision to re-open, ping the relevant core dev, remind the person who did it not do it.
I don't think we should though do it though.
I also don't think we should do it. would it be okay for triagers to manually add the "awaiting changes" label
on PRs that are suspected to be stale?
All "awaiting ..." labels are meant to be added automatically by bedevere-bot. Even core devs should not try adding/removing them manually. The "awaiting change" is meant to be added only after core devs reviewed the PR and requested change to it, so it doesn't make sense for a triager to add this label. It requires a core dev's decision. ᐧ
Mariatta wrote:
It still requires earning trust from at least one core developer who will approve their request, which I don't actually believe is an easy > thing to do.
Agreed, it may be a low bar in comparison to the 66% approval required for becoming a core developer, but it's definitely not trivial to achieve (especially for newer contributors). I think that approval from 2 core devs would be reasonable as well though. So far, the 3 candidates who were approved to join the triage team have had support from multiple core devs. If the requirements are going to be modified, it would be easier to do so while the team is still new. It would be less fair to future candidates if those currently on the team wouldn't have met the new requirements. Mariatta wrote:
All "awaiting ..." labels are meant to be added automatically by bedevere-bot. Even core devs should not try adding/removing them > manually. The "awaiting change" is meant to be added only after core devs reviewed the PR and requested change to it, so it doesn't > make sense for a triager to add this label. It requires a core dev's decision.
That was my previous impression, but then I saw that Brett applied it manually in this older PR to check if the author was still active: https://github.com/python/cpython/pull/117#issuecomment-367187316. That's why I figured it was worthwhile to ask about it. The most common and usual case for the "awaiting changes" label is for it to be automatically applied by bedevere-bot after a core dev requests changes, but it seems like it would also be an effective means to measure whether or not a PR's author is still active (if it's been several months since the last update from them). On Thu, Aug 22, 2019 at 8:24 PM Mariatta <mariatta@python.org> wrote:
The capabilities of a triager mostly look good except for "closing PRs and
issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration.
If most core devs prefer that triagers don't ever close PR/issue, then let's document that and let the triagers know of these boundaries. I'd like to be able to trust the triagers and let them help us, instead of restricting their movement.
Personally I think it's ok for them to close PR/issue, especially invalid ones. That's why we need help. If a core dev disagree with the decision, it is easy enough to re-open the PR.
Anyways, I have created a devguide issue for documenting the guidelines/ethiquette for closing PR/issue: https://github.com/python/devguide/issues/527
Our bar for becoming a triager is somewhat low,
It still requires earning trust from at least one core developer who will approve their request, which I don't actually believe is an easy thing to do.
is it possible to adjust permissions in
the Python project?
Nothing we can do. You can try contacting GitHub about it.
My worry is that it *might* require more trust in a
contributor before giving them the triager role.
Yes, but I don't see this as a bad thing. If we want to make it more strict by saying at least 2 or more core devs approving, that's ok with me too.
We could, if we really really really wanted to. Any of the bots can
be programmed to look for closed PRs from people in triage team (and not the author of the PR) and make policy decision to re-open, ping the relevant core dev, remind the person who did it not do it.
I don't think we should though do it though.
I also don't think we should do it.
would it be okay for triagers to manually add the "awaiting changes" label
on PRs that are suspected to be stale?
All "awaiting ..." labels are meant to be added automatically by bedevere-bot. Even core devs should not try adding/removing them manually. The "awaiting change" is meant to be added only after core devs reviewed the PR and requested change to it, so it doesn't make sense for a triager to add this label. It requires a core dev's decision.
ᐧ
That was my previous impression, but then I saw that Brett applied it manually in this older PR to check if the author was still active: https://github.com/python/cpython/pull/117#issuecomment-367187316.
That was Brett's bot for backfilling the "awaiting ..." label to PRs created before we had any "awaiting .." label. A script was used to automatically determine the stage of the PR and apply appropriate label. https://mail.python.org/archives/list/python-dev@python.org/thread/UYMPA4OFW... ᐧ
ᐧ
That was Brett's bot for backfilling the "awaiting ..." label to PRs created before we had any "awaiting .." label. A script was used to automatically determine the stage of the PR and apply appropriate label.
Ah, that makes sense. I wasn't aware that personal GitHub accounts were previously used by bots before the current dedicated bots were implemented. Thanks for the clarification, feel free to disregard my earlier suggestion then. On Thu, Aug 22, 2019 at 11:02 PM Mariatta <mariatta@python.org> wrote:
That was my previous impression, but then I saw that Brett applied it
manually in this older PR to check if the author was still active: https://github.com/python/cpython/pull/117#issuecomment-367187316.
That was Brett's bot for backfilling the "awaiting ..." label to PRs created before we had any "awaiting .." label. A script was used to automatically determine the stage of the PR and apply appropriate label.
https://mail.python.org/archives/list/python-dev@python.org/thread/UYMPA4OFW...
ᐧ
ᐧ
If the concern is pruning old/stale/invalid issues/PRs, I think the proposal to add a specific "awaiting-close" (or similar) label should work. These issues can periodically be handled by a core-dev who can click on the label, then evaluate and bulk-close them in one shot if necessary. Also, it seems to me that including "devguide" and "core-workflow" repos is unnecessary since they are low-traffic administrative repos related to our internal workflow, they are attended by a small portion of the core-dev team only and labels don't play a central role as in the cpython repo. Please let's keep in mind that this role implies higher responsibilities than a usual contributor, and since the bar for being promoted is considerably lower than a core-dev's, triager permissions should reflect that and remain minimal. For instance, I don't think a triager should be able to edit other users' comments or lock conversations, but I'm afraid GitHub doesn't provide that level of granularity (correct?). -- Giampaolo - http://grodola.blogspot.com
For instance, I don't think a triager should be able to edit other users' comments or lock conversations, but I'm afraid GitHub doesn't provide that level of granularity (correct?).
You are correct in that GitHub does not allow customization of the permissions, but those with the "Triage" permission are unable to edit comments or lock conversations. In order to do either of those, the "Write" permission is required. Compared to a normal contributor, triagers are only able to add labels, close, reopen, and assign PRs/Issues. On Fri, Aug 23, 2019 at 2:01 PM Giampaolo Rodola' <g.rodola@gmail.com> wrote:
If the concern is pruning old/stale/invalid issues/PRs, I think the proposal to add a specific "awaiting-close" (or similar) label should work. These issues can periodically be handled by a core-dev who can click on the label, then evaluate and bulk-close them in one shot if necessary. Also, it seems to me that including "devguide" and "core-workflow" repos is unnecessary since they are low-traffic administrative repos related to our internal workflow, they are attended by a small portion of the core-dev team only and labels don't play a central role as in the cpython repo. Please let's keep in mind that this role implies higher responsibilities than a usual contributor, and since the bar for being promoted is considerably lower than a core-dev's, triager permissions should reflect that and remain minimal. For instance, I don't think a triager should be able to edit other users' comments or lock conversations, but I'm afraid GitHub doesn't provide that level of granularity (correct?).
-- Giampaolo - http://grodola.blogspot.com
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2YYB6MAJ...
On Wed, 21 Aug 2019 at 22:17, Raymond Hettinger <raymond.hettinger@gmail.com> wrote:
Thanks for doing this. I hope it encourages more participation.
The capabilities of a triager mostly look good except for "closing PRs and issues". This is a superpower that has traditionally been reserved for more senior developers because it grants the ability to shut-down the work of another aspiring contributor. Marking someone else's suggestion as rejected is the most perilous and least fun aspect of core development. Submitters tend to expect their idea won't be rejected without a good deal of thought and expert consideration. Our bar for becoming a triager is somewhat low, so I don't think it makes sense to give the authority to reject a PR or close an issue.
Agreed. Closing an issue basically means having the authority to reject a proposal, which really is not different than accepting it. It's probably the second highest responsibility after being able to merge a PR. The risk is to potentially reject a good proposal without having the expertise and authority to properly evaluate it, which is why we have the core-dev role.
participants (8)
-
Abhilash Raj -
Brett Cannon -
Giampaolo Rodola' -
Kyle Stanley -
Mariatta -
Paul Ganssle -
Raymond Hettinger -
Victor Stinner