Since the introduction of the Triager role, its lacking of a number of non-sensitive but quite useful permissions that limit the use of many increasingly important GitHub workflow features has been raised as an issue by both triagers and core devs on a variety of Discord, Discourse and GitHub threads. This was as far back as shortly after the role was created, and have been increasing substantially in frequency lately with the GitHub migration and the Python dev workflow making increasingly heavy use of features that triagers have limited access to, such as projects. This has been discussed at length most recently on python/core-workflow#460 .
While GitHub did finally release custom repository roles after many years of asking; they were essentially all useful only for the enterprise contexts for which they were designed, and none of the granular permissions they offered were useful for triagers.
In particular, the most-requested missing triager permissions, all of which that users with the Write role or above posses, include:
- Edit issue/PR titles
- Add issues to projects from the issue page, and edit project-related issue metadata
- Approve actions workflows for new contributors
- Run/re-run Actions workflows
- Edit issue/PR metadata before submitting
Other potentially useful permissions include:
- Transfer issues between repositories in the org
- Fix formatting in issues/comments
- Collapse specific comments by default as spam/OT/outdated/etc.
- Mark a PR as draft/non-draft
- Allow core devs to mark them as a codeowner and auto-pinged for review (useful for triagers helping maintain specific modules, e.g.
tomllib, without making them a core dev)
Ideally, GitHub would add support for these types of granular permissions, but given how long it took them just to do so for the enterprise facing ones, and given those above are unlikely to be useful for most corporate internal projects that pay GitHub’s bills, I don’t think we should hold our breath for that in the meantime.
However, we’ve found what appears to be a viable workaround, as we propose on the issue: Tweak branch protection to only allow teams that currently have write access to actually touch (push, merge or create) any branches on the repo itself, and then give triagers the “write” role. This grants triagers the ability to use all of the above GitHub features (and a few others), while otherwise preserving the status quo as it is now:
- Triagers cannot alter the actual Git repo itself in any way with this, as they cannot push new branches, delete existing ones, merge PRs or push commits any branches either on the repo or on other people’s PRs
- Users/teams that already have write access have exactly the same permissions as before
- Bedevere should still work correctly in labeling and commenting on PRs wrt whether core devs have reviewed, as it is based on teams rather than nominal permission levels
It isn’t perfect—it does enable a number of new permissions, including some others that are not really necessarily for triagers. However, none of them are permanently destructive or affect the repo directly, and of the latter group, and in the unlikely event of any undesired use of the latter group by one of the limited number of triagers, the latter group are all very visible, revertible and could be swiftly and permanently dealt with e.g. by advising, warning or removing the triager as appropriate (particularly since misuse of the more sensitive of which would represent a very clear and obvious breach of trust).
Though it was supported by the triagers, core devs and SC members involved so far, and we’ve brought it up a number of different relevant places, since this is not a completely trivial change I wanted to post here to ensure maximum visibility and gather any additional feedback before proposing it to the SC for further consideration. (And of course, it would be fully tested and discussed further before any deployment). Questions? Thoughts? Concerns?