GOVERNANCE: Update Reviwer role and process

Author: Rugvip

.github/ISSUE_TEMPLATE/reviewer.yaml

@@ -0,0 +1,53 @@
+name: 'Reviewer Request'
+description: 'A request to become a Backstage reviewer'
+title: 'Reviewer: <your-github-login>'
+labels:
+  - reviewer-request
+body:
+  - type: markdown
+    attributes:
+      value: >
+        ### Thank you for your interest and contributions to the Backstage project! 🙏
+
+  - type: markdown
+    attributes:
+      value: >
+        This form is used to request Reviewer status in the Backstage project,
+        as described by the [Backstage Governance](https://github.com/backstage/community/blob/master/GOVERNANCE.md#reviewer).
+        In addition to becoming a member of the `@backstage/reviewers` team, this role also
+        comes with the responsibilities and requirements that are described in the governance.
+
+  - type: markdown
+    attributes:
+      value: <br>
+
+  - type: textarea
+    id: reviewer-examples
+    validations:
+      required: true
+    attributes:
+      label: 'Reviewer examples'
+      description: 'Please link to at least two reviews you have provided as an outside collaborator in the Backstage project'
+      placeholder: 'Link to pull request reviews'
+
+  - type: textarea
+    id: other
+    attributes:
+      label: 'Any other context that you wish to share'
+
+  - type: checkboxes
+    id: read-reviewer-responsibilities
+    attributes:
+      label: 'Have you read the Reviewer responsibilities?'
+      options:
+        - label: >
+            I have read and understood the [Reviewer responsibilities](https://github.com/backstage/community/blob/master/GOVERNANCE.md#reviewer).
+          required: true
+
+  - type: checkboxes
+    id: already-org-member
+    attributes:
+      label: 'Are you already an Organization Member?'
+      options:
+        - label: 'I am already an Organization Member.'
+          required: true

GOVERNANCE.md

@@ -158,34 +158,50 @@ encouraged to review pull requests, a Reviewer is formally recognized as a
 trusted voice in the review process. This role is a great way to contribute to
 the project and can be a stepping stone towards becoming a maintainer.
 
+Reviewers are members of the `@backstage/reviewers` GitHub team. Approving
+reviews from members of this team will add the `reviewer-approved` label to the
+pull request, greatly increasing its priority for review by owners of the
+project area. The `@backstage/reviewers` group does not grant write access or
+ability to merge pull requests.
+
+Members of the `@backstage/reviewers` group that submit reviews will also have
+their own pull requests prioritized higher. Reviewers that are found to be
+submitting low-quality or spammy reviews may have their priority penalized or be
+removed from the group.
+
 #### Responsibilities
 
 - Actively review pull requests, providing constructive, kind, and helpful
   feedback.
 - Follow the project's
   [reviewing guide](https://github.com/backstage/backstage/blob/master/REVIEWING.md).
-- Help contributors get their PRs into a mergeable state.
-- Help triage issues and apply labels where appropriate.
+- Help contributors get their pull requests into a mergeable state.
 
 #### Requirements
 
-- Has a track record of providing high-quality, constructive reviews on several
-  pull requests across the project.
-- Demonstrates a good understanding of the project's coding conventions, values,
-  and best practices.
-- Is supportive of new and occasional contributors and helps get useful PRs in
-  shape to merge.
+- Is an Organization Member that has been following the requirements for that
+  role.
+- Has submitted at least two pull requests reviews in the Backstage project with helpful feedback for the author of the pull request.
+- Keeps providing constructive and helpful reviews on pull requests, with at
+  least 5 reviews per year.
+- Demonstrates an ongoing understanding of the project's coding conventions,
+  values, and best practices.
 
 #### Privileges
 
-- May be formally requested for reviews on specific PRs.
-- May be granted triage access to repositories to help manage issues and PRs.
+- Membership in the `@backstage/reviewers` GitHub team.
+- Higher priority on own pull requests, based on review activity.
+- Access to the GitHub Project
+  [Review Board](https://github.com/orgs/backstage/projects/14/views/1).
+- May be granted triage access to repositories to help manage issues and PRs
+  (separate from the reviewers team).
 
 #### Becoming a Reviewer
 
-Contributors can be nominated by any Project Area or Core Maintainer. The
-nomination is discussed and approved by the maintainers of the relevant project
-area(s).
+Open an issue towards the community repository using the [reviewer request template](https://github.com/backstage/community/issues/new?template=reviewer.yaml&title=Reviewer%3A+%3Cyour-github-login%3E).
+This request should include links to at least two reviews that have been
+provided somewhere in the Backstage project. As long as the requirements are met, a Core Maintainer
+will grant Reviewer status through an addition to the `@backstage/reviewers` GitHub team.
 
 ### Plugin Maintainer
 

project-areas/Maintainer-Guidance.md

@@ -30,63 +30,9 @@ open without having it marked as stale, you can add the `will-fix` label.
 
 ### Pull Request Management
 
-The division of pull requests among project areas is based on the GitHub reviewer
-feature, rather than labels or assignment. This is because it automatically
-works with the code owners feature, and also makes it possible for each team to
-decide if they want individual assignment of pull requests through the GitHub
-team settings.
-
-To aid in the pull request review process there is a
-[Pull Request Reviews](https://github.com/orgs/backstage/projects/2) GitHub
-project, where all incoming pull requests are automatically added. The "All" tab
-shows all pull requests, while "For Me" shows only the ones that you have been
-requested to review. The rest of the tabs show pull requests for each individual
-project area.
-
-Note that the project area tabs will not show pull requests that have been
-assigned to an individual maintainer, they will instead show up in their "For
-Me" tab.
-
-### Pull Request Reviews
-
-When reviewing pull requests you should always use the "request changes" option
-if you are leaving a review where you would not like the pull request to be
-merged as is. This is both to clarify to the author that the pull request is not
-ready to be merged, but also to update the status of the pull request in the
-pull request review board, more on that below. If you simply want to contribute
-to the discussion in a pull request you can just leave a regular comment.
-
-Even though a pull request may only change code owned by a single project area,
-it may indirectly affect other project areas or the project as a whole. If this
-is the case, reviews should be requested from the additional maintainer teams,
-and labels can be added for extra visibility. These are a few example where this
-would be applicable:
-
-1. A pull request adds a new way of using capabilities provided by a different
-   area, for example if the TechDocs plugin started utilizing the scaffolder
-   APIs in a novel way that is not already established or documented.
-1. A pull request introduces new platform level technologies such as new code
-   generation tools. In this case the core maintainers should be requested for
-   review.
-
-### Merging Pull Requests
-
-External contributions are merged by the owner of the modified code once the
-pull request has been approved and all critical status checks have passed. If
-there are multiple owners and it is not obvious that the pull request belongs to
-any particular area, then any owner may merge the pull requests as soon as it
-has been approved by all owners.
-
-Pull requests that are made by a project area maintainer within the same area
-are generally merged by the pull request author, although it is up to the
-maintainers of the area to decide if they want to use a different process.
-
-The core maintainers are able to and may occasionally merge pull requests
-without approval from all code owners. This is to be avoided, but might
-sometimes be necessary for emergency fixes. It is also done for the "Version
-Packages" pull requests that are part of our automated release process. This
-means that project area maintainers do not need to approve these pull requests
-every week.
+Project area maintainers in the main Backstage repository are responsible for reviewing pull requests towards their area, as outlined in [REVIEWING.md](https://github.com/backstage/backstage/blob/master/REVIEWING.md).
+
+Project area maintainers in other repositories are responsible for defining their own ways of working for pull request reviews.
 
 ### Release Process
 

project-areas/core/README.md

@@ -17,7 +17,4 @@ This meeting is not currently open to external participation.
 
 ### Pull Request Reviews
 
-The core maintainers use the
-[randomized pull request assignment](../Maintainer-Guidance.md#randomized-pull-request-assignment)
-pull request review strategy. All incoming pull requests are distributed
-randomly and evenly among the maintainers.
+Core maintainers coordinate pull request reviews using the process outlined in [REVIEWING.md](https://github.com/backstage/backstage/blob/master/REVIEWING.md). They should focus on high priority pull requests in the global review board, especially those without clear ownership.