Github project administration for WG areas

Dev teams want to use github actions for CI and PR status checks. With the current Github plan, Admin access to the repository is required at least for the maintenance of secrets. According to rfc-0014-github-teams-and-access only WG leads and TOC members have admin access for github repositories.

This blocks dev teams as they have to wait for a WG lead to apply the needed configuration. Several dev teams created temporary admin teams for their WG area as workaround (configured in https://github.com/cloudfoundry/community/blob/main/org/cloudfoundry.yml).

The following options shall be discussed to solve this problem.

1. Manually configured temporary admin teams

This is the current situation.

Pros:

• works today

Cons:

• cumbersome configuration, not well integrated in org automation
• approvers with full admin rights can delete repositories and bypass the intended access management

2. Github Custom Roles for WG area approvers

Idea is to grant WG area approvers all the necessary rights that are needed to maintain PR status checks and secrets without granting full admin access to the repositories.
The role would probably be close to Maintain with some additional selected permissions.

• Repository roles for an organization
• Managing custom repository roles for an organization

Pros:

• simple implementation, need just to assign additional permissions to the existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teams
• no additional community roles and processes needed

Cons:

• requires a more costly Github plan
• unclear if custom roles allow to fulfill the requirements (secret management), needs a POC

3. Grant all WG area approvers admin rights

The existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teams would get assigned to Admin role instead of Write role.

Pros:

• simple implementation, need just to assign Admin role to the existing wg-[WORKING-GROUP-NAME]-[AREA-NAME]-approvers teams
• no additional community roles and processes needed
• works with existing Github plan

Cons:

• approvers with full admin rights can delete repositories and bypass the intended access management

4. Additional community role 'WG area admin'

An additional community role (on top of reviewer and approver) is introduced that can be configured in the WG charter.
The org automation generates a new github teams wg-[WORKING-GROUP-NAME]-[AREA-NAME]-admins for each WG area and the members of the WG area admin teams get assigned to the github Admin role.

Pros:

• potentially dangerous admin access is granted to selected WG area members only (won't help for very small WG areas)
• works with existing Github plan

Cons:

• requires a new community role and related processes
• WG area admins can delete repositories and bypass the intended access management

Read rfc-0014-github-teams-and-access.md and the current team configuration in org/cloudfoundry.yml. Compare the four access-management options against GitHub's repository roles and secret-management requirements. Done means one option is selected, documented, and reflected in the relevant community and organization configuration.