Announcing the new Python triage team on GitHub

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...
More specific roles and responsibilities of the Python triage team are described in devguide: https://devguide.python.org/triaging/#python-triage-team
The responsibilities are a little different than the Developer role that we currently have on b.p.o. On GitHub, triage team members have access to triage issues and pull requests not only in CPython repo, but also all the repositories owned by Python core team, including: devguide repo and all the bots' repos.
Existing b.p.o Developers are not automatically added to Python triage team, but they can opt-in and request membership. Several reasons:
- we don't know if the triager is still active or not
- we don't know if the triager wants the added responsibilities or not
Other contributors are also welcome to request the Python triage membership. All it takes is one core developer to approve the request.
The process is fully documented in https://devguide.python.org/triaging/#becoming-a-member-of-the-python-triage..., and there is an issue template for requesting membership in core-workflow https://github.com/python/core-workflow/issues/new/choose
The first two triage team members are Kyle Stanley and Jeroen Demeyer. Their requests were handled in: https://github.com/python/core-workflow/issues/353 https://github.com/python/core-workflow/issues/354
If you'd like more background on Python triage team and how we came to this stage, all of these have been discussed in discourse:
- https://discuss.python.org/t/proposal-create-bug-triage-team-on-github/
- https://discuss.python.org/t/creating-the-python-triage-team-on-github/
https://discuss.python.org/t/criteria-for-promoting-people-to-the-python-tri...
https://discuss.python.org/t/who-should-be-able-to-change-what-labels-on-git...
We also have a project board in core-workflow: https://github.com/python/core-workflow/projects/3
This is a new thing for us, and we're all still learning and getting use to it. Suggestions and ideas for improving the workflow can be discussed in Core Workflow category in discourse. Devguide improvements are also welcome.
Thanks contributors, core devs, and The PSF infra team for all the help in getting this off the ground. And also thanks GitHub for giving us early access to the beta triage role!
ᐧ

Hi,
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.
Victor
Night gathers, and now my watch begins. It shall not end until my death.

The permission that are available to us are specified at https://help.github.com/en/articles/repository-permission-levels-for-an-orga.... So to answer the question of "can we adjust permissions?", the answer is "no".

On Thu, Aug 22, 2019, at 11:07 AM, Brett Cannon wrote:
The permission that are available to us are specified at https://help.github.com/en/articles/repository-permission-levels-for-an-orga.... So to answer the question of "can we adjust permissions?", the answer is "no".
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.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/V... Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (4)
-
Abhilash Raj
-
Brett Cannon
-
Mariatta
-
Victor Stinner