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 <br...@python.org> 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" > 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 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/WXIGMYFUNZGPOIOK75BMQYEY7ZTQCUBG/
