Proposal: Create "Bug Triage" team on GitHub


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.


  • 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 “:robot: 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.
  • Sounds good
  • No
  • I’m concerned … (explain)
  • This needs a PEP

0 voters

1 Like
(Karthikeyan Singaravelan) #2

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.

(Brett Cannon) #3

Actually the person does get subscribed to the issue when they are @ mentioned.


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.

1 Like
(Karthikeyan Singaravelan) #5

Thanks @Mariatta and @brettcannon. I didn’t notice this earlier.

(Carol Willing) #6

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.).

1 Like
(Barry Warsaw) #7

Does that mean experts won’t get auto-nosied on issues related to their area of expertise?

1 Like
(Carol Willing) #8

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

(Barry Warsaw) #9

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.

1 Like

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).

1 Like
(Barry Warsaw) #11

No objection there!

1 Like
(Carol Willing) #12

One thing that simplifies it is that there can be a CODEOWNERS file 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.

(Brett Cannon) #13

We actually already have one:

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.

(Nathaniel J. Smith) #14

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 :slight_smile:

(Sviatoslav Sydorenko (read: /sʋʲɑtɔˈslɑw/)) #15

FTR there’s now a triage role in GitHub’s ACLs in Beta: