GitHub Permissions for TODO Group Repos

[gtback]

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
  • Add to SC onboarding template
• Create process for becoming an org admin
• Enable 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
• Add CODEOWNERS with newly-created repo teams
• Disable outside collaborators once they have been reflected in repo-name-maintainers or repo-name-admins

---

(Original text from @gtback)

👋🏻 Hi!

We started talking about this at the Work Day today, but these are questions best answered by the Steering Committee. I think most of these can be set here. I get a 404 error because I'm not an owner of the TODO Group org, but that matches what it is for other orgs I'm an owner of.

1. What should the "Base Permissions" be set to for all repos in the org? I'm guessing it's "Read" now, but could possibly be changed to "Write"? Are there repos that we don't want members to be able to push to (like governance, perhaps)? Or would branch protection rules (requiring a review from someone in the @todogroup/steering-committee team or via CODEOWNERS) be OK? If not, I think we'd need to create a team for "All Members" and give that team Write permissions on repos we want people to be able to edit.
2. Should anyone in the organization be able to create new repos ("Repository creation")? That seems to the be the current setting, and I think it's fine, but wanted to be explicit.
3. Should the "Owners" of the org be all the Steering committee members, or does it make sense to keep these lists separate?
4. Are there other Teams that make sense to add to manage permissions? I generally think Team permissions (either for the whole organization via Base Permissions or via teams added to specific repos) are more scalable than adding people individually to repos.

(I don't mind helping out with some of these permission/maintenance issues, once things are decided.)

[DuaneOBrien]

Thanks for the issue @gtback

Context for SC, I didn't think we should make any of these changes during Work Day without discussing in the SC.

[anajsana]

Thanks, @gtback! I'll add this topic for the upcoming SC meeting (Dec 13th)

[justaugustus]

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 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
• Add CODEOWNERS 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: uwu-tools/peribolos#9

[anajsana]

Thanks for your help @justaugustus . I've left some comments below, but I think we should take a look at this issue next week during the SC meeting, to:

1. convert this issue into small action items
2. assign people for each of them

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

Org-level

* Enforce 2FA

+1, If everyone agrees on this, I can make the required changes in settings

* Default to `read`

AFAIK, this is something we can do if we add the config.yaml document you have suggested a few lines below, right?

* Create process for requesting repo creation

This is being discussed in this issue: #111
And this is the related PR: #156

  * 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

[justaugustus]

Thanks for your help @justaugustus . I've left some comments below, but I think we should take a look at this issue next week during the SC meeting, to:

1. convert this issue into small action items

2. assign people for each of them

SGTM! I've added it to the agenda.

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

Org-level

* Enforce 2FA

+1, If everyone agrees on this, I can make the required changes in settings

Before we enforce 2FA, we need to check how many org members already have 2FA enabled.

If everyone has 2FA enabled, we can turn on enforcement immediately.

If anyone DOES NOT has 2FA enabled, we need to:

• set a consensus date for 2FA enforcement
• send notice to all TODO Group org members that this will happen on/after the consensus date

(Otherwise, the 2FA enforcement will remove org members that do not have 2FA enabled.)

* Default to `read`

AFAIK, this is something we can do if we add the config.yaml document you have suggested a few lines below, right?

Yep, but I'd have to tweak a few things in https://github.com/relengfam/peribolos to support non-Kubernetes orgs first. :)

I'd suggest enabling this manually in the meantime.

I'd also like to explore (when time allows) https://github.com/github/safe-settings (suggested by @byjrack) for org policy enforcement.

* Create process for requesting repo creation

This is being discussed in this issue: #111 And this is the related PR: #156

I think the process of proposing an idea is a little different from guidelines for repo creation.
Ideas may require a repo, but the creation of a new repo may just be to support an existing process.

A "recent" example is https://github.com/todogroup/member-shares, which may have some really awesome content, but was created as a private repo, so members are unable to see the content.

The Kubernetes project has some great guidance for their repos that we could borrow from.

[justaugustus]

1. convert this issue into small action items

Added an initial task list to the issue description.
If SC is onboard with the suggested tasks (following next week's meeting), we can break them out into individual issues.

[gtback]

Thanks @justaugustus . Let me know if I can help with any of this.