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 <aeros...@gmail.com> 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 <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/C5RIPUXTYB6P5XPKJ2KCLPTVLLORHER7/
