Adjusting the "Triager" role's permissions

[AA-Turner]

GitHub released custom repository roles yesterday.

It might be useful if Triagers could edit issue/PR titles, edit projects from the issue page, and potentially approve Actions workflows for new contributors.

cc: @ezio-melotti @brettcannon @JelleZijlstra @CAM-Gerlach

A

[hugovk]

Here's the list of "35 fine grained permissions", but I don't see any for the things suggested.

[AA-Turner]

Well this is rather disappointing then -- reading the list it does seem a fairly mixed bag. I can't see a feedback link on the original blog post or else I'd add a note somewhere.

A

[CAM-Gerlach]

Yeah, I looked carefully thought the list and compared it with what permissions Triagers already have, and I didn't see anything there that would actually be useful or appropriate for Triagers, at least that isn't already enabled.

For example, in addition to the items @AA-Turner mentioned above, marking PRs as closing issues, or vice versa (I can close them manually and it seems like a very triage-related thing to do, so its omission is rather inexplicable). Or, one thing that could be considered is being able to edit others comments like users with Write and above can, i.e. to fix formatting/markdown issues (a particularly common and useful task when I was the primary triager of issues on the Spyder repo).

It seems pretty useless for open source projects, as opposed to specific cooperate/enterprise needs (billing managers, etc).

[ezio-melotti]

Another permissions that would be useful for triagers is the ability to add issues to projects, especially if we start using them instead of the expert-* labels.

[hugovk]

It would, but unfortunately this permission doesn't seem to be available either.

[AA-Turner]

I found three requests¹²³ for finer-grained permissions on the GitHub feedback discussions site, but no response from a representitive of GitHub.

A

Footnotes

1. https://github.com/orgs/github-community/discussions/5773 ↩

2. https://github.com/orgs/github-community/discussions/12703 ↩

3. https://github.com/orgs/github-community/discussions/14795 ↩

[hugovk]

Thanks, I gave them upvotes just in case!

[CAM-Gerlach]

I believe I might have found a way around the issue of triagers missing a number of useful, non-intrusive permissions that have been repeatedly requested here, on Discourse, Discord and elsewhere.

If you enable Restrict who can push to matching branches and Restrict pushes that create matching branches in the branch protection rules for all branches in the CPython repo (whatever branches currently have rules, plus * to cover any other branch), and add the teams that currently have write access (so there's no difference for anyone who currently has access), this allows you to give the Triage team the "Write" role, which would allow them access to the various GitHub UI capabilities that core devs and triagers have been asking for them to have, without giving them any ability to actually create, push to or delete any branch, or merge PRs.

The main issue is whether there are any other permissions that people feel are too sensitive to give to triagers that don't involve modifying the actual repository content.

[CAM-Gerlach]

The permissions this would potentially change are listed here. Looking carefully, its a lot more than I initially thought, and we'd want to ensure we're happy with it before making any such change, of course.

If not, one alternative could be an intermediate role, a "Trusted Triager", that has these permissions but not the much more critical ability to be able to push commits, merge PRs or otherwise affect the content of the repo itself.

These are the permissions that would be added, minus those that branch protect would prevent and that aren't applicable to the CPython repo (e.g. those that only apply to private repos or with features not enabled there), with commentary on them

• Create, edit, delete labels
  Could be potentially useful in some situations/workflows, but perhaps not ideal for triagers to be able to delete labels (however, that would be a pretty egregious breach of trust).
• Edit and delete comments on commits, pull requests, and issues
  When triaging on other repos, I find this invaluable to quickly fix common formatting errors in user issues that can severely impact readability, allow copying and pasting source text and linking issues in OPs. Any abuse would be immediately obvious since this is all logged and visible on issues (posts say edited by @username at the top and clicking brings up the full change history, which can be reverted, and any deleted comments leave a message stating so, who deleted it and the reason).
• Hide comments on issues
  This can be useful for dealing with spam, OT comments (including my own) and those that are out of date and make an issue/PR hard to follow. The comments are simply collapsed and state the reason for hiding them (OT, spam, out of date, etc) and anyone can uncollapse them, so it doesn't seem like there's much risk with this.
• Lock conversations
  Probably not needed for a triager, but any abuse would be obvious and easily reversible.
• Transfer issues between org repos
  Likely useful for triagers in selected cases, and otherwise low potential for damage/abuse.
• Allow being marked as a codeowner
  Can be useful to allow auto-tagging someone on PRs without making them a core dev permissions (e.g. @hauntsaninja with Tomli, and would be really useful to us on the PEPs repo), but also completely optional; only has any effect if a core dev adds them to CODEOWNERS.
• Mark PR draft or as ready for review
  Potentially quite useful for triagers, and can't do any harm on its own (without merge rights).
• Apply suggested changes to PRs
  Probably not needed, but any abuse would be obvious and reversible (just drop the commits).
• Run and re-run GitHub Actions workflows
  Very useful and has been frequently requested.
• Create and edit GitHub Releases
  Initially this one worried me the most, but since the CPython repo doesn't use releases at all, the worst that could happen is a triager randomly adds some, which would be a pretty egregious breach of trust, would be instantly obvious (anyone watching the repo would be pinged immediately) and they could simply be deleted.

[encukou]

I'm not sure who can approve that change.
If the proposal is stuck, you can open a SC ticket with a summary (and links to any previous discussion), and the SC will (eventually) find the proper people to consult and delegate to.

[CAM-Gerlach]

Thanks, will do. Though I and others have mentioned this a number of different places, IMO it is worth opening a dedicated Python-Dev discussion (at least on Discourse) to gather any additional general feedback or concerns before going ahead with a SC ticket. As such, I've gone ahead and opened one.

[ned-deily]

You should ensure that current CPython release managers are comfortable with this proposal as they are the people who typically manage branch protection rules for CPython. In case they haven't already seen this: @pablogsal @ambv @Yhg1s and @ned-deily.

[ambv]

As far as we're talking specifically about the python/cpython repo, I think the change proposed by Cam isn't controversial:

• make triagers writers to the repo, too;
• restrict them from actual pushes to protected branches by using "Restrict who can push to matching branches".

It will be a little annoyin* then to the release managers if they use branch locking to remove and re-add proper team lists. But I think it's worth it for the added capability for triagers.

time(triaging) >> time(locking_branches_during_release)

[encukou]

Just to make sure: CPython does use tag protection, right?
I don't think you can push anything but branches and tags to GitHub, but I wasn't able to verify that.