Proposal: Create "Bug Triage" team on GitHub

No objection there!

1 Like

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.

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.

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:

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

1 Like

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.

The Python org is currently on one of our legacy plans, and the triage role feature is not going to be made available to orgs on legacy plans.
However, the good news is that you can move Python to a new plan by submitting a new non-profit account request:
I hope that helps and let me know if you need any further information.
GitHub Support


Just as an update: Github emailed me for information yesterday. I responded and hope to hear back from them soon.

1 Like

@Mariatta - GH responded that we now have the non-profit team plan. Let me know if what you need to enable is still not accessible.

1 Like

Thanks for the update @ewa.jodlowska!
I’m still only seeing the Read/Write/Admin permissions in CPython, not the triage permission.

I will write back to them and ask about it again.

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.

Thanks @ewa.jodlowska for the help in getting this set up.
Python org is now a non-profit org, and we’re in the “Team” plan, and we can start creating the Triagers team.

  1. Can anyone here come up with a list of people I should add as triagers on GitHub? I think we should try this with a small group of active and experienced triagers, and work out any issues that may come up.

  2. While that is happening, I will work on adjusting miss-islington and maybe bedevere to take the triage role into account.

  3. Update devguide re: the new Triage team, their role and expectations


Thanks for your input, @aeros. The role you described sounds like what I would expect from a triager.

1 Like

Created a project in core-workflow:

Here’s a list to start from:

Of 49 members of that list, 28 have set their GitHub username. If that’s more than we want to start with, there are several names in that list that have been quite active lately that could make a good starting set.

Thanks for the list @zware!

I think the following people are good candidates. I may be biased, so I’m open for other suggestions.

  • maxking
  • ammaraskar
  • CuriousLearner
  • mariocj89
  • tirkarthi
  • nanjekyejoannah
1 Like

I think that’s a reasonable starting set, but that anyone on the list should feel free to request being added to the triage team even before the full group is added; all should be added by the time PEP 588 is implemented.

1 Like

No problem, thanks for the clarification. Based on the name and my impression so far of the current triagers, I had thought they were more focused on prioritizing individuals issues and on the submission of the patches themselves rather than reviewing PRs. I have not yet seen too many triagers in the PRs of others on github assigning labels, but that might just be because the role is quite new and there’s not too many of them yet.

As someone who has recently taken a particular interest in the code reviews specifically, what would it take to become a triager? Also what is the expected experience level of the role? I’ve come to understand that the core developers should be reserved to the veterans of the Python community, who have had significant involvement across hundreds of topics in their respective areas.

Edit: I’m not at all suggesting to be on the immediate list of candidates since I’m still new to the Python dev community (had my first commit in June). I just wanted to get a rough idea of the expected experience for a triager so that I had a goal to work towards.

On the issue tracker it’s someone who has consistently shown they know how to respond to issues. I suspect the same will be done for GitHub and PRs: basically someone who has built up trust with a core dev to warrant giving them partial control of the project.

1 Like

I would recommend @eryksun, who often triages and is highly knowledgeable about Windows bugs.


Before we start giving triage permissions, shouldn’t we first define what triagers are allowed to do? For example, I suppose they should not apply the automerge label (even if they technically have permission from GitHub to do that). Should they be allowed to set needs backport labels? Should they be allowed to set awaiting merge if they agree with a PR or awaiting changes if they don’t agree? Should there be some kind of mentoring for triagers?

If self-nominations are accepted, I would like to apply for triager permission. I mostly work on the core interpreter and C API, I’m co-author of PEP 590. See my bugs, my PRs and my reviews.