Le 21/08/2019 à 19:38, Mariatta a écrit :
We have a new Python triage team on GitHub to help improve our workflow.
GitHub has a nice table that shows what a triager can or cannot do in general: https://help.github.com/en/articles/repository-permission-levels-for-an-orga...
I see that GitHub triagers can "Close, reopen, and assign all issues and pull requests". When Python used patches attached to bugs.python.org, triagers basically had the "close pull request" permission: closing an issue indirectly closed a "pull request" (a patch in practice, since patches were attached to issues).
Since we moved to GitHub, GitHub pull requests are clearly separated from bugs.python.org issues. bugs.python.org triagers could not touch pull requests: only core developers had the right to close a PR for example.
Is it giving too many responsibilities to triagers to let them close and reopen pull requests? If yes, is it possible to adjust permissions in the Python project? My worry is that it *might* require more trust in a contributor before giving them the triager role.
Technically, reopening an issue is trivial, but you need to be aware that there was a pull request. Some PRs are not attached to any bugs.python.org issue (no "bpo-xxx" prefix in their title).
Maybe we should just warn new triagers than they should be careful before closing a PR. Maybe ask a core developer before doing that?
In practice, I'm not sure that it's a big deal. But since it's something new (to me at least), I take your email as an opportunity to discuss it :-) My intent is to ensure that it remains easy to give the triager permission to motivated contributors to give them more responsibilities.
Night gathers, and now my watch begins. It shall not end until my death.