Closed justaugustus closed 2 months ago
I will move this to the community repository :)
I cannot 🙃
@dlorenc can you transfer this issue ?
Transferred!
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/
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.
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.
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!
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.
This should be complete now, we have Pulumi for managing repo settings and team memberships.
From https://github.com/sigstore/sigstore/issues/305:
@lukehinds:
@dlorenc:
cc: @cpanato @naveensrinivasan