GitHub org team/member management

[justaugustus]

From https://github.com/sigstore/sigstore/issues/305:

@lukehinds:

We don't have anything defined as each project has autonomy to manage its own maintainers (codeowners).

As a general guide, I myself view a maintainer as someone who regularly helps review code, finds and resolves bugs and adds features. A good candidate is someone who has a consistent presence in the project.

I hope that helps and sorry for not being more specific. Currently a lot of your contributions (of a varied type) are towards cosign, so that looks like a good trajectory towards being a maintainer.

@dlorenc:

I kind of miss having something like peribolos to manage permissions across an org, but don't really want to have to setup prow just for that. @cpanato do you know of any way to do that easier?

cc: @cpanato @naveensrinivasan

[cpanato]

I will move this to the community repository :)

I cannot 🙃

@dlorenc can you transfer this issue ?

[dlorenc]

Transferred!

[justaugustus]

Cross-posting from https://github.com/sigstore/sigstore/issues/305#issuecomment-1057110087:

As for a contributor ladder and some context, I opened a similar issue to this a little while ago in scorecard: ossf/scorecard#1529

I haven't "figured it out" just yet, but some suggestions I'll make around it, based on previous experiences/systems/orgs I currently work in (stares at kubernetes)...

* Lightweight or heavyweight, make sure the decisions are discussed and documented: https://github.com/kubernetes/community/blob/master/github-management/new-membership-procedure.md

* At least two sponsors (at least one of which is not an employee of the candidate's): https://github.com/kubernetes/community/blob/master/github-management/new-membership-procedure.md#sponsor-requirements

* Org membership should be a low bar, elevated privileges come with higher requirements: https://github.com/kubernetes/community/blob/master/community-membership.md

* Make changes visible/auditable (non-org members cannot see behind the scenes without this): https://github.com/sigstore/sigstore/issues/308 / https://github.com/relengfam/peribolos / https://github.com/kubernetes/org

* Actively probe for changes to membership... promote or prune people based on their activity; don't wait for them to ask you (because some folks are shy/may not think they deserve it)

* Policy is living and should be actively reviewed/improved

* Contributing is NOT code; ensure you have workflows/incentives for non-code contributors: https://github.com/kubernetes/community/blob/master/contributors/guide/non-code-contributions.md

I've linked a bunch from Kubernetes, but I'd be remiss if I didn't call out the CNCF TAG Contributor Strategy body of work, a lot of which we drew from our experiences in Kubernetes and other OSS communities: https://contribute.cncf.io/maintainers/

[justaugustus]

Some suggestions from a past me in https://github.com/todogroup/governance/issues/106#issuecomment-1000962064:

I'll make some suggestions based on previous experiences with GitHub org management...

Org-level

* Enforce 2FA

* Default to `read`

* Create process for requesting repo creation

  * Disable repo creation for non-org owners

* Add Steering members as org admins

* Create process for becoming an org admin

* Enable [Allstar](https://github.com/ossf/allstar) to report compliance with the following:

  * repo has branch protection
  * repo does not have checked-in binaries
  * repo does not have outside collaborators
  * repo has a SECURITY.md

Repo permissions

* Create teams to administer repos:

  * `repo-name-admins`: has `admin` role
  * `repo-name-maintainers`: has `maintain` role

* Enable branch protection for all repos: [branch protection rules #69](https://github.com/todogroup/governance/issues/69)

* Add [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) with newly-created repo teams

* Disable outside collaborators once they have been reflected in `repo-name-maintainers` or `repo-name-admins`

Managing org membership

Use peribolos to enforce org settings and allow adding org members via pull request.

Example:

name: TODO Group
description: Org description
default_repository_permission: read
has_organization_projects: true
has_repository_projects: true
members_can_create_repositories: false
billing_email: admin@org.name
admins:
- admin1
- admin2
- admin3
- admin4
- admin5
members:
- member1
- member2
- member3
- bot1
- bot2
teams:
  bots:
    description: Bot service accounts
    maintainers:
    - bot1
    members:
    - bot2
    privacy: closed
  members:
    description: TODO Group members
    members:
    - member1
    - member2
    - member3
    privacy: closed
  steering-committee:
    description: Steering Committee members
    maintainers:
    - admin1
    - admin2
    - admin3
    - admin4
    - admin5
    privacy: closed
  repo1-admins:
    description: Admins for repo1
    members:
    - member1
    privacy: closed
  repo1-maintainers:
    description: Maintainers for repo1
    members:
    - member1
    - member2
    - member3
    privacy: closed

The Kubernetes Community manages multiple orgs with this tool --> https://github.com/kubernetes/org

I'm working on making this easier to use for non-Kubernetes orgs here: relengfam/peribolos#9

Nothing against Pulumi or @cpanato's suggestion of https://github.com/cpanato/pulumi-github-sync, but I would suggest using something that does not requiring knowledge of yet another tool.

What I really want is to turn peribolos into a GitHub Action (via https://github.com/sethvargo/go-githubactions) and run that on all of my orgs.

If someone is interested in hacking on that with me, I forked peribolos to detach it from k/test-infra: https://github.com/relengfam/peribolos

https://github.com/relengfam was created to give people access to hack projects I'm working on, so if anyone in this group wants membership, just let me know.

[dlorenc]

If peribolos can run in a github action that works for me! I love prow but don't want to have to run it just for this.

[justaugustus]

If peribolos can run in a github action that works for me! I love prow but don't want to have to run it just for this.

My sentiment exactly!

[vaikas]

I can't make a commitment right now, but I think this would be very valuable work overall so if I can find time, I'd love to help. I know for example Knative also could benefit from this, since there we do run peribolos as well :) I'm sure there are others.

I'd be happy to help, so if you want to add me that org that would be great.

[haydentherapper]

This should be complete now, we have Pulumi for managing repo settings and team memberships.