Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Formally track aspiring approvers as reviewers #333

Merged
merged 3 commits into from
Aug 2, 2022
Merged

[RFC] Formally track aspiring approvers as reviewers #333

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
7ae9e1c
[RFC] Formally track aspiring approvers as reviewers
rkoster Jul 5, 2022
65ec680
More precise description of reviewers teams
stephanme Jul 25, 2022
0400a1b
Role change process for reviewers
stephanme Jul 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions toc/rfc/rfc-formal-aspiring-approvers-as-reviewers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Meta
[meta]: #meta
- Name: Formally track aspiring approvers as reviewers
- Start Date: 2022-07-05
- Author(s): @rkoster, @stephanme
- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded -->
- RFC Pull Request: https://github.com/cloudfoundry/community/pull/333


## Summary

Extend the working group yaml definitions to optionally include a `reviewers` key per area with a list of contributors who like to become approvers.
The github org automation should use this information to create a github team for the area with `-reviewers` suffix and __read__ permissions.

This will later allow automatic assignment of PRs to be reviewed, which will help these contributors more easily satisfy the requirements to become approvers. An additional use case might be granting read access to non-public CI pipelines.

## Problem

Due to the way to cloudfoundy github organization is setup, contributors gain no additional access rights within the organization.
This prevents PRs to be assigned to them to be reviewed.

In addition, the current process for getting people approver status relies a lot on the discipline of contributors to rack up the [needed contribution points](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0006-approver-requirements.md).
Ideally we create an opt-in low resistance path, to help contributors get to approver status quicker.
A lack of enough approvers hinders our ability as a community to review and approve PRs in a timely manner.
Improving the number of approvers should be the top priority of working group leads.

## Proposal

Allow tracking aspiring approvers as `reviewers` per working group area. Create a `*-reviewers` team per area that includes a `reviewers` key with read access to the area's repos.

stephanme marked this conversation as resolved.
Show resolved Hide resolved
This extends [RFC-005 Standardizing Github Teams and Access](https://github.com/cloudfoundry/community/blob/main/toc/rfc/rfc-0005-github-teams-and-access.md):

| Name of Team | Team Membership | Permissions |
|---|---|---|
| wg-[WORKING-GROUP-NAME]-[AREA-NAME]-reviewers | Contributors who want to become approver for an area within a WG | Read access for all repos in the area, so that PRs can be assigned for review |

`reviewers` are not included in the overall working group team `wg-[WORKING-GROUP-NAME]`.

Where:
* `WORKING-GROUP-NAME` is the name of the Working Group, converted to kebab case,
* `AREA-NAME` is the name of the area, also converted to kebab case, or a suitable short name that identifies it clearly and uniquely within the Working Group.