This is somewhat related to PEP 581, but I’m thinking we can benefit from having a Bug triage team even now.
Proposal: Create a “Bug triage” team to Python’s GitHub repos (not just CPython, but other repos like devguide, core-workflow), and grant this permission to people who currently hold the “bug triager” permission on bpo.
Reason: Bug triagers are valuable to our workflow, they can help with applying appropriate labels, closing issues/PRs. At the moment only core developers can do this. By granting bpo bug triagers capabilities to apply labels, closing issues, marking things as “easy” etc, it will help lessen the workload of a core developer, and at the same time empowering the active contributors to continue participating in core Python development.
How:
We can grant write privileges to the “Bug Triage” team, but restrict the merging to the “CPython core developers” team (by adding branch protection)
miss-islington should only allow “ automerge” label to be added only by core developers
we’ll also want to clean up inactive “Bug Triagers” from bpo before going forward.
There is no GitHub API for “nosying”/“subscribing” someone to an issue/PR (unlike the “nosy” feature in bpo), the only way to do this is by @-mention someone on GitHub. Because of this, we will need to come up with some kind of etiquette/guideline on when people should be @-mentioned, and include it to the devguide.
This is more of a workflow question. Is there a way in which a core dev can be subscribed to the issue like nosy in bpo? At least in my workflow I generally nosy a core dev since they might have better context and also while closing the issue as duplicate so that they are aware of the resolution. GitHub doesn’t seem to have a setting where I can subscribe someone to the issue, I can cc them with GitHub username but they will be notified only about that message and not about subsequent discussions if I understand it correctly.
I’ve checked the API for this, and there is none. Only way to “subscribe” is by @-mentioning people, or for them to manually click the “subscribe” link on GitHub web UI.
Thanks for bringing this up. Perhaps we will need to come up with guidelines/etiquette on when to @-mention people, and have this written in devguide.
I would be inclined to forgo @-mentioning folks and let the core developers use their own ways of monitoring the activity on GitHub (subscribing to repo notifications; Octobox; personal GitHub API integrations, etc.).
I’m thinking that the auto-nosy should not be through @-mention but instead be an opt in by the core dev of what they wish to follow using existing GitHub notification options or 3rd party tools like Octobox or things like https://app.github-file-watcher.com/
I’m just worried we’re going to require N # of individual core devs to have to figure out what to do on their own. Current bpo nosy lists work so well and you don’t even have to think about it.
Well the good thing is we’re not moving over from bpo yet, so you’re not losing any functionality from bpo. You will still get nosied and all that from bpo.
With this proposal it will mainly help with triaging the pull requests on GitHub more than anything.
This is an existing issue with pull requests on GitHub, not something that will be made worse or anything if we do create a “bug triage” team right now. (even without PEP 581’s acceptance).
One thing that simplifies it is that there can be a CODEOWNERS file https://help.github.com/en/articles/about-code-owners which can be used to trigger notifications or require reviews by individuals associated with a file. It could similarly be used if issues mention a file or module.
The biggest issue with it right now is it isn’t correlated/maintained with the experts index in any way, so there’s drift and motivation issues with getting folks to think about CODEOWNERS.
The experts index is super useful because of the integration with the bpo nosy list UI: when filing a bug, it’s easy to CC “everyone who cares about windows” or “everyone who cares about asyncio”, etc. (At least if you know the trick – it’s not very discoverable. I’m talking about what happens if you go to the nosy field on bpo and start to type “asyncio”.) CODEOWNERS is useful too, but it’s solving a different problem. @willingc Do you know of anything that addresses that specific part of the workflow with Github issues?
Mariatta’s right though that this is drifting away from her original post and into a discussion of PEP 581
I’ve requested to GitHub to have the triage role enabled for Python org. They’re saying that because we’re in the legacy plan, and not in the non-profit plan, it can’t be enabled for us. I feel this is out of my domain, so I’ve emailed Ewa and Ernest, hopefully they can follow up.
I’m definitely in favor of adding more specialized roles to the GitHub repositories. At the moment, there are not any intermediate roles between someone who has made their first contribution and core developer. The “Bug triager” role is a great start, and works fantastically as a solid experiment due to the role already existing on the bug tracker.
As more of a long term process, I think it would be beneficial to add other roles as well. One I’ve specifically had in mind has been a “Reviewer” or “Moderator” role which would be able to modify/add labels on PRs, such as skip news and skip issue (which currently only core devs can do).
There’s quite a significant volume of PRs which involve rather minor fixes such as documentation typos. Allowing another role to take care of the process of adding appropriate labels would save valuable time for the core developers. This role would be reserved to those who have contributed a significant number of code reviews containing constructive feedback, but are lacking the experience and/or expertise required to become a core developer.
Other useful tasks for the role might include adding core devs to a PR based on their specialization. Currently, only the code owners are automatically assigned. This does not always work properly, especially for documentation changes. As an example of this happening, when I recently created a PR that would add a new section to the os.chdir() docs, there was no automatically assigned reviewer. Although most PRs eventually receive attention, this process of finding and adding themselves to PRs takes further time from the core devs.
automerge” label to be added only by core developers
