Taking suggestions on github teams / team permissions for the operate-first organization about blueprint HOT 14 CLOSED

Just a note, creating such admin teams doesn't mean the org owners won't be admins anymore. So me, @HumairAK, @durandom, @goern are always admins by definition since we are org owners, no matter if we are part of any admin team or not.

Let's have an admin team for me and @HumairAK and @4n4nd (Anand, you can be either a member of the admin team + an approver for everything or neither of those, I don't see a way for you to pick the second and not be listed in the first 🙂 ), so we can be called via @operate-first/team-name on urgent matters.

I'd say the rest of the teams and folks should have triage access + should be grouped into:

• 1 general team for all core contributors
• a team per topic/sig: ops, telemetry, support, documentation, build/cyborgs - this way we can "call for help" a team (via the @operate-first/team-name alias) and we don't have to list all the people.

from blueprint.

... lets have a look if prow can manage all that for us ;)

from blueprint.

Assuming folks are happy with this setup, closing for now. Feel free to re-open.

from blueprint.

SourceOps should stay as is, as it contains Sesheta and enables bots and tools to work on the source

We should have one group of humans that are able to push-force into all repos, this is handy to apply hotfixes (aka bypassing PR-review process).

from blueprint.

/sig devops
/sig cyborgs

from blueprint.

Split it into ops-admins and ops, perhaps? ops-admins would consist of @tumido , @4n4nd , and @HumairAK . Everyone else would be dumped into ops.

from blueprint.

I think we should just keep @tumido and @HumairAK as admins, two admins for two different timezones.

from blueprint.

let's just add the teams and see how it goes and how they're used.

given that it's not only ops stuff, would admin make more sense? Are admin granted write access for all repos and approvers are not.

IIUC this issue is only about team communication and organization - not about approval and merge process

from blueprint.

"core contributors" would have admin/force-push access to all repos?

from blueprint.

"core contributors" would have admin/force-push access to all repos?

@goern if you mean the team I've hinted in my comment above, I meant a core contrib team for all the current operate first folks (since this is our current "core", and we'd like to expand it to external community). I don't think this team should have write access to repos though.

from blueprint.

IIUC this issue is only about team communication and organization - not about approval and merge process

We also need to consider who will have manual abilities to approve in the event prow fails to merge pr's (due to downtime/slow period/etc.)

from blueprint.

Humair, thats the reasone why we have a SourceOps team that is able to manually merge and force-push, I think Kubernetes calls this team 'on-call'

from blueprint.

Humair, thats the reasone why we have a SourceOps team that is able to manually merge and force-push, I think Kubernetes calls this team 'on-call'

Ah I see, I think I've just delegated this role to the admin team for now.

a team per topic/sig: ops, telemetry, support, documentation, build/cyborgs - this way we can "call for help" a team (via the @operate-first/team-name alias) and we don't have to list all the people.

I feel like this is overkill for our team size, but then again creating teams cost nothing. Who goes where?

from blueprint.

This is what I've created thus far:

I distributed permissions as follows:

• admins have admin on all repos
• contributors have triage on all repos
• workshopers having admin access to operate-first/workshop-apps

from blueprint.