Should the Release Coordinator have more permissions on GH?

[smoya]

As the Release Coordinator of AsyncAPI Spec 2.4, I have faced few issues that blocked me from eventually progressing on my duties coordinating the release. Most of them, are related to the lack of permissions on the involved repositories.

Some examples are:

• Not able to resolve conflicts on branches my creating PR's targeting such branch due to the default merge strategy we have in place (squash). I needed to instead, do a simple merge with no fast-forward. I had to prove I coulnd't do such a task and ask a maintainer to do the conflict resolution. That was really annoying because there is nothing in UI telling you what the issue is. See feat: release for version 2.4.0 of the spec  spec#740. Another example: feat: release for version 2.4.0 of the spec parser-js#501
• Not able to re-run GH Actions that failed (due to a temporary or random error). See feat(blog): add release notes for 2.4 release website#634 (comment)
• I remember having some issues with labeling and fighting against our bots, but not sure what it was.

I do understand admin privileges on AsyncAPI org should be restricted; not only because of security matters but I guess also as a requirement for projects under the Linux Foundation.

Could we, however, add temporary permissions to the Release Coordinator to avoid the previous things? Obviously, only during the time a release happens.

If you are 👍 , permissions should be given (afaik) at the repository level. There are several permissions and all of them are explained here (including the permissions matrix): https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role

As far as I see, write permissions would be needed:

• Create, edit, run, re-run, and cancel GitHub Actions workflows: >= Write
• Merge a pull request: >= Write

cc @fmvilas @derberg

[derberg]

cc @dalelane

I'm personally reluctant as the Release Coordinator role idea is to enable anyone to run it, without any technical involvement (like solving merge conflicts). Maybe we should improve communication instead. Have better access to maintainers than through PRs/Issues only?

[jonaslagoni]

I agree with @derberg here, the one with the permissions should be the repository's maintainers, not a random person that is a release coordinator. Solving the issues you faced might be as simple as finding a way to access the maintainers.

For example for 3.0, I found the same issue. However, when I sat thinking about it, how could the maintainers know which PRs are blockers that should be focused on? If they are just part of a massive list no one reads it every weak or even every month 😆

So I started dialing down on the blockers, specifically ping maintainers with the PRs that are being blocked: asyncapi/spec#691 (comment), asyncapi/spec#691 (comment), asyncapi/spec#691 (comment). That helped a bunch with how fast things went, cause it gives the maintainers a specific list of actions to take.

Another thing I kinda start to notice is, that asking questions, and wanting to have a discussion on what to do, is rarely getting the conversation going (of course at times it's needed, but expect it to take time!). Instead, I found you get more interaction if you just take a decision, the best you can, and if it's wrong, people will definitely tell you, otherwise your decision is as good as the next 🙂 Especially if you write the different options and why you chose the way you did.

[fmvilas]

I'm also reluctant to give more permissions just for the release. I think there are two main problems to solve here:

1. Communication. We probably have to enable a better way to communicate with the maintainers during the release process. And not just communication but checking on maintainers' availability.
2. Rushing out. In every release we've done so far, we have always been rushing out, doing things on the last day or close. We should probably be more strict about it and say, for instance, no new PRs accepted after the half of the month. Just so we all have ~15 days to do all the stuff together with the release coordinator. A good side effect is that we'll also have more time to update tools.

[dalelane]

I've done stuff like this before - have a "Release Coordinators" team in github that has elevated privileges needed for release admin in multiple repos. Then an individual can be added-to/removed-from that team as a single action that impacts all repos at once. So it's do-able if we think appropriate.

But I am inclined to agree that this should be a last resort - and the release coordinator having a simpler way to make requests to repo maintainers/owners would be a good place to start. (e.g. issue templates with instructions for common tasks automatically assigned to repo owners, that a release coordinator can easily create across multiple repos at once - this could help delegate and spread the effort needed, and also give the release coordinator a way to track remaining work).