Steering committee acls on the org.

[timothysc]

Steering committee members should have admin acls on the org to move repos and add members.

[bgrant0607]

Why do SC members need to do this, as opposed to the github admins?

[timothysc]

If we delegate to this group I suppose we just route issues to here, but it makes this subproject a blocking resource on execution of things like:

• transferring repos in (kuberenetes-sigs)
• sunsetting repos (kubernetes-incubator)
  ...

[spiffxp]

That's exactly the intent of this subproject, and I feel like this was sufficiently communicated to steering ahead of time.

[spiffxp]

/committee steering
/sig contributor-experience
/area github-management

[cblecker]

Hey Tim! As Aaron said, the intent of the subproject was to delegate these responsibilities away from "someone from steering" or "someone from contribex" to a small, defined team of volunteers. This avoids tying these permissions to an unrelated role. For example, it isn't a hard requirement of someone elected to steering to be able to transfer github repos, even though many of our current sitting members would be capable of doing this.

We have defined processes and SLOs to handle the types of requests you mention.

Some background threads that included the steering committee:
https://groups.google.com/a/kubernetes.io/d/msg/steering/4hzdh3Ulggk/n-NxuaVxCgAJ
https://groups.google.com/a/kubernetes.io/d/msg/steering/dgJ_ETTRI-Y/i987N9z1AgAJ
https://groups.google.com/a/kubernetes.io/d/msg/steering/3eiJ0Dz-1jE/Yd3mLcFyBgAJ

If you have any other questions or concerns, we'd be happy to address them :)

[cblecker]

cc: @kubernetes/steering-committee @kubernetes/owners

[philips]

I am OK with delegating admin creds to this sub project. It seems @bgrant0607 and @spiffxp are comfortable as well.

@timothysc are you concerned about not having an escape hatch for the steering committee? I would be OK with always reserving one admin seat for steering committee members similar to the Gsuite situation.

[cblecker]

Another note: We have two other escape hatches via the @k8s-ci-robot and @thelinuxfoundation service accounts. The former currently resides with the Google team responsible for prow, and the latter resides with the Linux Foundation. Both those accounts have admin access across all the orgs, if we needed a safety net.

[bgrant0607]

@philips This is in line with our general direction of granting github privileges according to need to do the job as opposed to status on the project, similar to revoking direct repo write access of "maintainers". I'm also happy to not be the de facto github admin any longer. :-)

Contributor Experience is steadily automating more and more operations, which gives us more control, auditability, and consistency.

It also should help to have admins who stay on top of github feature and policy changes and to field requests from contributors for various changes or support.

[timothysc]

I'm fine with it, but the docs on repo requests should be updated to reflect a process change.
We should also define the policy for sunsetting.

[cblecker]

@timothysc We added some process documentation in kubernetes/community@d119bb1. Is there any other places you know of that we should update?

[philips]

@cblecker those are great docs and I think all of the bases are covered from who is on the team to their responsibilities.

[timothysc]

Isn't there a process doc that @brendandburns created for requesting a repo from steering?

[cblecker]

I think that document became https://git.k8s.io/community/github-management/kubernetes-repositories.md

[timothysc]

@cblecker yup that's the one, we should update that doc to link to the appropriate templates - https://github.com/kubernetes/org/issues/new?template=repo-create.md
etc.

Then close this issue once it's complete.

[cblecker]

/assign

Sounds good. Will add something to those docs 👍