Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Taking suggestions on github teams / team permissions for the operate-first organization #31

Closed
HumairAK opened this issue Feb 5, 2021 · 14 comments
Assignees
Labels
sig/cyborgs Categorizes an issue or PR as relevant to SIG Cyborgs and Bots. sig/devops Categorizes an issue or PR as relevant to SIG DevOps.

Comments

@HumairAK
Copy link
Member

HumairAK commented Feb 5, 2021

We never properly discussed what github teams we should have, and who should be in which team, and which team needs what permissions. Currently we have an OPs team where I just threw everyone into in the beginning and gave them all admin to every repo. This was to just get us going, but now I think we could use a bit more structure (especially since using github to do auth for our apps is still yet a possibility and not off the table). This is the current set up:

image

Let's clean this up and re-organize. So we need:

  1. list of teams, who should be in each team
  2. team permissions per repo
@goern
Copy link
Member

goern commented Feb 5, 2021

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).

@goern
Copy link
Member

goern commented Feb 5, 2021

/sig devops
/sig cyborgs

@sesheta sesheta added sig/devops Categorizes an issue or PR as relevant to SIG DevOps. sig/cyborgs Categorizes an issue or PR as relevant to SIG Cyborgs and Bots. labels Feb 5, 2021
@goern goern removed their assignment Feb 5, 2021
@anishasthana
Copy link
Member

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

@4n4nd
Copy link

4n4nd commented Feb 5, 2021

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

@tumido
Copy link
Member

tumido commented Feb 8, 2021

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.

@durandom
Copy link
Member

durandom commented Feb 8, 2021

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

@goern
Copy link
Member

goern commented Feb 8, 2021

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

@goern
Copy link
Member

goern commented Feb 8, 2021

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

@tumido
Copy link
Member

tumido commented Feb 8, 2021

"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.

@HumairAK
Copy link
Member Author

HumairAK commented Feb 8, 2021

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.)

@goern
Copy link
Member

goern commented Feb 8, 2021

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'

@HumairAK
Copy link
Member Author

HumairAK commented Feb 8, 2021

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?

@HumairAK
Copy link
Member Author

HumairAK commented Feb 8, 2021

This is what I've created thus far:

image

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

@HumairAK
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig/cyborgs Categorizes an issue or PR as relevant to SIG Cyborgs and Bots. sig/devops Categorizes an issue or PR as relevant to SIG DevOps.
Projects
None yet
Development

No branches or pull requests

10 participants