-
Notifications
You must be signed in to change notification settings - Fork 17
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
Comments
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). |
/sig devops |
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 I'd say the rest of the teams and folks should have triage access + should be grouped into:
|
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 IIUC this issue is only about team communication and organization - not about approval and merge process |
"core contributors" would have admin/force-push access to all repos? |
... lets have a look if prow can manage all that for us ;) |
@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. |
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.) |
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.
I feel like this is overkill for our team size, but then again creating teams cost nothing. Who goes where? |
Assuming folks are happy with this setup, closing for now. Feel free to re-open. |
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:
Let's clean this up and re-organize. So we need:
The text was updated successfully, but these errors were encountered: