Proposal: GitHub Management Subproject in Contributor Experience

[cblecker]

History:

The Kubernetes project uses Github extensively to store and organize code, manage issues and documentation, and provide a consistent contributor flow.

With the size and growth of the Kubernetes project, management of our Github footprint has historically been a challenge. Management and permissions are handled in an ad-hoc way.

Proposal:

I'd like to propose a subproject under Contributor Experience to handle and manage GitHub settings, permissions, security, and process.

This subproject will be responsible for:

• Establishing policies, standards, and procedures for routine GitHub management tasks, including but not limited to: org membership, org permissions, repo creation/administration
• Establishing a policy around "Org Owner" permissions, and grant/limit these privileges accordingly
• Establishing policies and best practices for bot accounts, service accounts, webooks, and third-party integrations
• Maintaining documentation related to the above
• Establishing a "GitHub Administration team" that will oversee the execution of GitHub management tasks (inviting new members to the org, creating repos, executing moderation decisions, auditing permissions)
• Working with other sigs and interested parties in the project to execute GitHub tasks where required

This subproject will explicitly not be responsible for:

• Tooling and automation for GitHub (this falls under sig-testing, and the sig-contributor-experience Contributor Workflow and Automation subproject)
• Determining policies around which repos can get created (this falls under sig-architecture and the steering committee)
• Moderation policies and escalations on GitHub (this falls under the Moderation subproject, the Code of Conduct committee, and the steering committee)
• Contributor workflow within Kubernetes repos, e.g. mandated use of labels (this falls under the guise of the subproject responsible for the repo, and the Contributor Workflow and Automation subproject)

[philips]

Make sense to me.

[spiffxp]

Good list and anti-list. Many of these seems like human bandaids for the lack of docs or automation, so part of me wonders if this couldn't be disbanded / merged away once these gaps are filled. But let's get there first and then ponder that.

[spiffxp]

Context: https://groups.google.com/a/kubernetes.io/d/msg/steering/3eiJ0Dz-1jE/efNPfouMBgAJ

[bgrant0607]

+1

Github changes available settings on a not-infrequent basis, and sometimes owners are notified and sometimes not. Having someone with the experience and bandwidth to stay on top of them would be valuable.

Additionally, some repo owners want to enable a variety of applications, but not all applications are well behaved. For example, some third-party applications ask for permission from users to do arbitrary github actions as them across all orgs to which they have access. I think we need both a whitelist of applications and a general policy about what's acceptable.

[bgrant0607]

One more detail: Much as with the security team, there needs to be a private channel to report potential security issues with our github orgs and repos, so they can be investigated and potentially acted upon prior to public disclosure.

[bgrant0607]

Re. automation: I don't think this role can ever go away. Among other issues, not all of github's admin features are accessible via APIs, someone needs to respond to requests from contributors, someone needs to evaluate notifications from github about changes, someone needs to monitor https://blog.github.com/changelog/, and so on.

[cblecker]

/area github-management

[cblecker]

On the security point: We'll be establishing a team that holds the owner powers to do things in GitHub, but I think for the reporting channel, I would suggest that go the kubernetes.io/security PST we already have. I would submit that they are in the best place to triage any incoming security reports, figure out which pieces of the project they concern, and then escalate to the appropriate team (if GitHub related, then it would be the team we are creating).

I'm open though to reasons for or against this.

(cc: @philips @jessfraz @cjcullen @tallclair @liggitt)

[philips]

I think just using the [email protected] reporting works fine.