[RFC]: GitHub Organization Management

[GMNGeoffrey]

This proposes a way to manage the OpenXLA GitHub organization while it's under the Google GitHub Enterprise account.

[joker-eph]

This is a really nice write up, and thanks for pushing on a solution that allows to empower the community here! This REST proxy thing is pretty neat, I am impressed you got something like that through security review, kudos.

[GMNGeoffrey]

I am impressed you got something like that through security review, kudos.

Oh no I'm doing this in the other order :-) I'm proposing what we should do. Assuming people are in agreement, I'll do my best to make it happen with security policies. I didn't want to have this fully baked before proposing it to the community. But I do think I'll be able to get this through security review. It will just take a minute...

[stellaraccident]

I propose landing with notes at the bottom for ongoing/followup discussions.

[GMNGeoffrey]

I propose landing with notes at the bottom for ongoing/followup discussions.

I'd like @theadactyl to weigh in. Desire to manage things at the org level is mostly coming from her experience with TensorFlow

[theadactyl]

I'm having a hard time visualizing the different options we have on the table at this point.

I'm fairly flexible on where we land, but do have some requirements:

• is in line with openxla governance model
• minimizes manual permission management
• makes it relatively easy to audit permissions
• doesn't make it too hard to onboarding contributors

[theadactyl]

Wherever I've seen access managed at the repo level, i've seen the following happen:

• more arbitrary granting of permissions / less conformance to overall permission policy
• unless the repo admins are auditing regularly, access is very rarely modified downward
• when an org-wide audit is needed, it is more laborious (ie, you have to remove a lapsed contributor/maintainer from 6 repos instead of from one team)
• harder to deduce how/why an individual was given write/maintain/admin access

Maybe the cumulative cost of maintaining access at the org level is ultimately more expensive than a federated approach.

On Wed, Jun 7, 2023 at 2:47 PM Geoffrey Martin-Noble < @.***> wrote:

@.**** commented on this pull request.

In rfcs/20230516-github-organization.md https://github.com/openxla/community/pull/80#discussion_r1222208910:

+Write access and above, however, will continue to be administered manually. +Module Maintainers, with the guidance of Core Maintainers, will determine who +has write access to the repositories they maintain (the Interim Steering +Committee will decide in the meantime). For each repository, we will create 3 +teams: <repo>-admin, <repo>-maintain, and <repo>-write, corresponding to +the admin, maintain, and write privileges in the GitHub repository access model.

I think that somewhere we should document module maintainers and which repos fall under their module.

Definitely agreed.

IMO, GitHub teams for module maintainers with access managed there kills two birds with one stone.

I'm not sure it does really. I think a module could easily be a directory of a repo, for instance, so we'd need to document it some other way. Also, GitHub teams are a lot more work to navigate than a text file, for instance.

I'm having a hard time visualizing the different options we have on the table at this point.

I'm fairly flexible on where we land, but do have some requirements:

• is in line with openxla governance model
• minimizes manual permission management

I think right now we're thinking that triage access would be almost entirely automated or at least federated with the option to automate. Write access and above would be manually managed.

• makes it relatively easy to audit permissions

This is the bit that I'd like to understand better your needs/experience. Putting things at the org level has mostly stemmed from that. What are the questions you want to be able to ask?

• doesn't make it too hard to onboarding contributors

I think this is one place where making things managed at the repo level would reduce friction by federating that process, though potentially mean someone has to ask for permissions for each repo. Blanket triage permissions seems useful to avoid the latter problem. Having teams at the org level for write/maintain/admin access makes that a bit more complicated too, I think, just because it's harder to sift through all the teams

— Reply to this email directly, view it on GitHub https://github.com/openxla/community/pull/80#discussion_r1222208910, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABREJVPCWR6KUNQEVN723STXKDZI7ANCNFSM6AAAAAAYDZKBVE . You are receiving this because you were mentioned.Message ID: @.***>

[GMNGeoffrey]

Ok yeah that all makes sense. I think the current proposal (as described in my comment above), which makes write access managed in org-level teams, but maintain and admin access at the repo level might strike the right balance here. I proposed a couple features here that I think might help:

• we diff between a GitHub team for all admins/maintainers and the admins/maintainers of each repo. We can automatically remove people if there's a diff, or trigger an alert, or whatever.
• we similarly automatically remove any repo-level access that isn't admin/maintain.
• we continue to disallow outside collaborators outside collaborators setting
• for managing the permissions of an individual, there's a single page you can go to (e.g. https://github.com/orgs/openxla/people/ScottTodd), so I don't think that should be hard, but it also wouldn't be hard to script it. If they're completely leaving the project, removing them from the organization would also remove them from all repos, I think? Or at least it would in an eventually consistent way with the automation described above.

How does that sound? I'm still OK with teams for writers and maintainers (and admins?) as well, but Scott expressed concern about having a bazillion teams, which I think is fair.

[theadactyl]

+1 sounds like a good middle ground to me.

On Wed, Jun 7, 2023 at 3:54 PM Geoffrey Martin-Noble < @.***> wrote:

Ok yeah that all makes sense. I think the current proposal (as described in my comment above), which makes write access managed in org-level teams, but maintain and admin access at the repo level might strike the right balance here. I proposed a couple features here that I think might help:

• we diff between a GitHub team for all admins/maintainers and the admins/maintainers of each repo. We can automatically remove people if there's a diff, or trigger an alert, or whatever.
• we similarly automatically remove any repo-level access that isn't admin/maintain.
• we continue to disallow outside collaborators outside collaborators setting https://user-images.githubusercontent.com/5732088/239015839-82915386-c1ae-4b66-8239-4e38ebdc8b46.png
• for managing the permissions of an individual, there's a single page you can go to (e.g. https://github.com/orgs/openxla/people/ScottTodd), so I don't think that should be hard, but it also wouldn't be hard to script it. If they're completely leaving the project, removing them from the organization would also remove them from all repos, I think? Or at least it would in an eventually consistent way with the automation described above.

How does that sound? I'm still OK with teams for writers and maintainers (and admins?) as well, but Scott expressed concern about having a bazillion teams, which I think is fair.

— Reply to this email directly, view it on GitHub https://github.com/openxla/community/pull/80#issuecomment-1581614586, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABREJVNPTG2MGRJT2MC2AVDXKEBDPANCNFSM6AAAAAAYDZKBVE . You are receiving this because you were mentioned.Message ID: @.***>

[GMNGeoffrey]

Pushed new draft. PTAL. Also, what do we actually do about the dates here? Should I leave it as the date proposed, or update to the date when it's merged?

[theadactyl]

Proposed date is easiest IMO. Ty for these edits and LGTM!