Update GOVERNANCE and OWNERS

Signed-off-by: Fredrik Adelöw <[email protected]>

Author: freben

GOVERNANCE.md

@@ -36,9 +36,33 @@ To become a maintainer you need to demonstrate the following:
 
 If a maintainer is no longer interested or cannot perform the maintainer duties listed above, they should volunteer to be moved to emeritus status. In extreme cases this can also occur by a vote of the sponsors and maintainers per the voting process below.
 
+# Reviewers
+
+The project also contains a team called [@backstage/reviewers](https://github.com/orgs/backstage/teams/reviewers). This is the team of people who are the fallback in [`CODEOWNERS`](./.github/CODEOWNERS). This team will typically contain the maintainers, and a small number of additional people who are permitted to approve and merge pull requests. The purpose of this group is to offload some of the review work from the maintainers, simplifying and speeding up the review process for contributors.
+
+This responsibility is distinct from the maintainer role. A reviewer must not approve and merge changes that have a level of impact that a maintainer should oversee; see below for clarification. For that class of changes, a reviewer can still review the pull request thoroughly without approving it (e.g. with a comment on the pull request), and is expected to notify `@backstage/maintainers` for final approval. Note that it is best to not use the GitHub review approve functionality for this, since that would let Hall of Fame members self-merge the pull request before maintainers get the chance to look at it.
+
+The following is a non-exhaustive list of types of change, for which a reviewer should defer final decision and merge to a maintainer:
+
+- A larger refactoring that significantly affects the structure of/between packages
+- Changes that settle or alter the trajectory of contested ongoing topics in issues or elsewhere
+- Changes that affect the [Architecture Decision Records](./docs/architecture-decisions)
+- Changes to APIs that have large customer impact, such as the core APIs in `@backstage/core-*` packages, or significant `@backstage/cli` changes.
+- Pull requests whose build checks are not passing fully
+- Additions and removals of entire packages
+- Releases (e.g. pull requests titled `Version Packages`)
+
+A maintainer may suggest an addition to the reviewers team by opening a pull request that modifies [`OWNERS.md`](./OWNERS.md) accordingly. Prospective reviewers are not expected to do this themselves, but should rather ask a maintainer to sponsor their addition. All of the maintainers and sponsors are called to vote on the addition (see the section below about voting). If the vote passes, the pull request can be approved and merged, and the corresponding addition to the GitHub team can be made.
+
+A reviewer can elect to remove themselves from the reviewers group by opening, or asking a maintainer to open, a pull request that modifies [`OWNERS.md`](./OWNERS.md) accordingly. A maintainer will approve and merge the pull request, and the corresponding removal from the GitHub team can be made.
+
+A maintainer can call on the other maintainers and sponsors for a vote to remove a reviewer (see the section below about conflict resolution and voting). If the vote passes, a maintainer creates a pull request that modifies [`OWNERS.md`](./OWNERS.md) accordingly. After approval by another maintainer, the pull request can be merged, and the corresponding removal from the GitHub team can be made.
+
 # Conflict resolution and voting
 
-In general, we prefer that technical issues and maintainer membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the sponsors and maintainers can be called in to decide an issue. If the sponsors and maintainers themselves cannot decide an issue, the issue will be resolved by voting. The voting process is a simple majority in which each sponsor receives two votes and each maintainer receives one vote.
+In general, we prefer that technical issues and membership are amicably worked out between the persons involved. If a dispute cannot be decided independently, the sponsors and maintainers can be called in to decide an issue. If the sponsors and maintainers themselves cannot decide an issue, the issue will be resolved by voting.
+
+In all cases in this document where voting is mentioned, the voting process is a simple majority in which each sponsor receives two votes and each maintainer receives one vote. If such a majority is reached, the vote is said to have _passed_.
 
 # Adding new projects to the Backstage GitHub organization
 

OWNERS.md

@@ -16,6 +16,18 @@ This page lists all active sponsors and maintainers.
 - Ben Lambert ([benjdlambert](https://github.com/benjdlambert)) (Discord: @blam)
 - Johan Haals ([jhaals](https://github.com/jhaals)) (Discord: @jhaals)
 
+# Reviewers
+
+See [`GOVERNANCE.md`](./GOVERNANCE.md) for details about how the reviewers team
+works.
+
+- Patrik Oldsberg ([rugvip](https://github.com/rugvip)) (Discord: @Rugvip)
+- Fredrik Adelöw ([freben](https://github.com/freben)) (Discord: @freben)
+- Ben Lambert ([benjdlambert](https://github.com/benjdlambert)) (Discord: @blam)
+- Johan Haals ([jhaals](https://github.com/jhaals)) (Discord: @jhaals)
+- Himanshu Mishra ([OrkoHunter](https://github.com/OrkoHunter)) (Discord: @OrkoHunter)
+- Tim Hansen ([timbonicus](https://github.com/timbonicus)) (Discord: @timbonicus)
+
 # Emeritus maintainers
 
 - Stefan Ålund ([stefanalund](https://github.com/stefanalund)) (Discord: @stalund)