Permissions for the Python triage team

Recently, I became a member of the new Python triage team on GitHub. The majority of the permissions have been set correctly, but I think there’s some that may be missing (based on the devguide section):

  1. Ability to modify PR titles

Currently, I am unable to modify PR titles. Frequently, PR authors (especially those who are first-time contributors) will have a title that does not succinctly cover what the PR is addressing. Improving the title can help core devs find PRs in their respective areas of expertise and interest.

My alternative for now is to recommend for the author to adjust the title in the comments, but it would definitely be easier if we could directly edit PR titles. Most authors will eventually follow the recommendation in my experience (from before I became a triager), but there’s frequently a significant delay.

  1. Ability to assign organization members to PRs (Assignees).

As far as I’m aware, this was not a permission that was directly discussed. As a result, I’m not certain if it’s something that we should try to utilize productively, or if it’s simply an extra feature included with GitHub’s “Triage” permissions. For clarification, this is a permission we currently have that I wasn’t aware of.

If it’s something we should try to use productively, how should it be utilized? My first guess would be to use it for assigning the appropriate experts to PRs when they are not automatically added as reviewers from CODEOWNERS. However, “Assignees” looks to be more along the lines of something that should be used only for issues, not PRs. Assigning experts to review PRs seems like it would be done through the “Reviewers” list (which we don’t have permission to do, as intended). I figured it would be worthwhile to ask before trying to use it in any way.

These are definitely not critical concerns, and from what I can tell so far, everything else seems to be working as intended. I’m not even certain that it’s possible through GitHub to allow those with the “Triage” permission to edit PR titles. If it’s not possible, the devguide section should be updated accordingly.

Thanks @Mariatta for the proposal and for setting up the team! I think this team will definitely have a positive impact on the workflow, and free up the core devs to spend more time on merges/final reviews.

We don’t control what the triage permissions give you on GitHub, so there’s nothing here for us to do (our options are literally just “read”, “triage”, “write”, “maintain”, and “admin” for permissions and it’s only available for the entire repo).

Ah, I was hoping that wasn’t the case. It would be nice if GitHub allowed further customization of the permissions on a per-team basis, and more customization for different parts of the repository. In that situation, the existing 5 options would simply be templates to expand upon.

Since the “Triage” permission is in beta currently, perhaps the GitHub team will expand upon the existing permissions to include permissions such as editing PR titles. I’ll look into submitting feedback, but it might have a bit more weight if it comes from the organization rather than a single user.

We’re lucky to finally have “Triage” in beta since many have requested over the years.

I think gently requesting that folks update their title is a good approach

As for assigning organization members to PRs, I would put that on a shelf for the short term. Personally, I would love to see momentum pick up and get into a good workflow groove (thanks Mariatta) first before we add complexity. :wink:

I would be really, really happy if each new PR gets a welcoming response within 48 hours (but that’s just my dream not a formal target).


Good point. Since the team was just recently created, it makes sense to wait a decent amount of time before adding on additional responsibilities. I may have been jumping ahead a little bit. (:

This would still be a great goal to move towards! A simple “Thanks for the PR @username”, applying a few labels, and a preliminary/surface-level review (typos, title suggestions, etc) can be quite impactful. I’ll definitely try my best to prioritize PRs that haven’t received any responses.


Update: The “triage” role permissions were recently modified globally by GitHub to allow those with the role to add specific org members to the list of reviewers in PRs. This can be seen on the GitHub repository permissions table under “Traige (beta)”, specifically the permission “Request pull request reviews”.

Should we encourage the use of this feature for triagers to add the appropriate experts to the list of reviewers for PRs? This is already some to some degree by @mentioning specific experts, but I think it would make more sense to request a review from them when the codeowners list doesn’t add them automatically.

As far as notifications go, I believe the reviewers list has a slightly lower and more configurable priority level in comparison to @mentions.

I don’t know how other feel, but I would rather encourage people to add themselves to CODEOWNERS more.

Now if there’s an odd edge case where someone rightfully isn’t in CODEOWNERS but should still be looped in, then an @ mention still makes sense if it’s just asking for an answer/opinion on something specific. Otherwise CODEOWNERS should be flagging folks who might be in a position to provide a PR review.

I agree that this should be the standard option, it’s definitely far more efficient to have the correct experts automatically added as reviewers based on codeowners rather than having to do it manually.

Would you encourage for triagers to add experts to codeowners if we notice a non-edge case where it’s missing or should it instead be specifically delegated to the core developers to add themselves to the correct areas?

I can see benefits and downsides to both options. If the triagers opened PRs to add the appropriate core devs to codeowners based on the experts index, it would likely be finished much more quickly. I suspect that if it’s up to core developers to add themselves, it’s more likely be a perpetually in-progress effort. Especially considering that the available time of many of the core devs tends to be more limited.

But, this could potentially risk adding core devs to areas they are not currently active in or do not wish to receive notifications for. If they add themselves to the list, it will be significantly more likely that they’ll actually review the PRs they’re added to. There are several core devs listed on the experts index that have not been active in the last year (including several that have not been marked as inactive), so it would probably have to be translated on a case-by-case basis if core devs didn’t add themselves.

If you’d prefer to leave it up to the core devs to add themselves to the correct codeowners areas, perhaps an announcement of some form in python-committers or in the Discuss committers section could help to bring attention to it. I notice it missing the most frequently for documentation files, but especially for the tutorial sections.

The missing gaps are a bit more clear if you compare the experts index to codeowners. It’s not exactly one to one, but it provides a general idea of the currently missing areas.

When you say “folks”, is that exclusively core devs or would you encourage for knowledgeable contributors that are active in a specific area to add themselves to codeowners? Of course, this would probably have to require explicit approval from a core dev experienced in that area.

I was under the impression that it was only for core devs, but there’s a few particularly active and knowledgeable contributors that regularly provide constructive reviews in their respective area(s). Perhaps there would be some benefit to having them automatically added as a reviewer for PRs in their area(s) of expertise.

I would encourage asking core devs if they think they should be added to CODEOWNERS.

You can’t add people who aren’t core devs to CODEOWNERS as they must have write permissions on the repo.

1 Like

Oh okay, I can try reaching out to specific core devs if I notice they weren’t added to a PR as a codeowner. There was a recent instance where I noticed nobody was added to a zipfile PR, although @storchaka was listed as an expert for the module. In your experience, is typically easier to reach out to most of the core devs through email or Discuss PM?

Ah, good to know. I wasn’t aware of that, but it’s not overly surprising. is too new to know how effective it is (plus not all core devs are on it). I personally use email for this sort of thing if I don’t already have a side channel to the specific person.

Good to know, thanks. I’ll be sure to reach out to any core developers I notice that are maintainers or have expertise in a particular module/area, but aren’t in CODEOWNERS for it. I’ll probably try to ask in the PR first when I notice they weren’t automatically added as a reviewer. If that doesn’t work I’ll try to reach out to them through email.

I wouldn’t mind opening a PR to add them myself if they don’t have time to mess around with the CODEOWNERS syntax and formatting, as long as they’re okay with it. It saves me the hassle of matching bpo names on the experts index to github user names and manually adding them as a reviewer in the future, so I’d be glad to help out.