[Python-Dev] Re: Announcing the new Python triage team on GitHub
> 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 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/UYMPA4OFWCJPFPASDUZYGXTH6ZGM6RJZ/ > > > ᐧ >>> >> ᐧ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/M3RWXJSDJJBO6P4GVAKVSSC5NKYEBIPD/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
> > 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/UYMPA4OFWCJPFPASDUZYGXTH6ZGM6RJZ/ ᐧ >> > ᐧ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/TWX6W2WS6H4TOR6YGJD66Y4G3NNXSX2D/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
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 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. > > > ᐧ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/HA5UFFO2TYKLPEKSQL5FIK3WC26NWN6Y/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
> > 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. ᐧ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/XC5IBYYSV3S3VLRB5Y23EBCCZJRB2CMA/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
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 wrote: > Abhilash Raj 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 > 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-organization#repository-access-for-each-permission-level > 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 wrote: > >> 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-committ...@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
[Python-Dev] Re: Announcing the new Python triage team on GitHub
Abhilash Raj 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 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-organization#repository-access-for-each-permission-level 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 wrote: > 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-committ...@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"
[Python-Dev] Re: Announcing the new Python triage team on GitHub
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-committ...@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 > 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-le...@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-le...@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/TCV2FLY6M4ZR3SBMOK5NI73QIKP7SVX4/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
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-committ...@python.org/message/53K5MJAKLRGY2F34ZCYGL3WPWSJ4C5M2/ > > 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-le...@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/ADUP3UDMKOGCZ6MSUIMRZRY6M7VHBW62/ > -- thanks, Abhilash Raj (maxking) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/PBVT6Y5PHXDGT2VE7Z4SEBGWZZABIHEY/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
On Wed, 21 Aug 2019 at 22:17, Raymond Hettinger 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/STV4WIJJ3LBTKQSOOWPLS6EAAUKWN75M/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
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-committ...@python.org/message/53K5MJAKLRGY2F34ZCYGL3WPWSJ4C5M2/ > > > 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 signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/HVLB2VIGOWFFTGVKEYYHEL7PQ337Q53K/
[Python-Dev] Re: Announcing the new Python triage team on GitHub
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-committ...@python.org/message/53K5MJAKLRGY2F34ZCYGL3WPWSJ4C5M2/ 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. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/ADUP3UDMKOGCZ6MSUIMRZRY6M7VHBW62/
