DOC Document new community roles

en/06_Project_Governance/03_Maintainer_Guidelines.md

@@ -21,6 +21,10 @@ Refer to the [triage and peer review](/contributing/triage_resources/) for infor
 
 ## Maintainer Roles
 
+Note that these roles are specifically for maintaining [supported modules](./supported_modules/). Unsupported modules in the `silverstripe` GitHub organisation are not necessarily maintained by these roles. If there is an unsupported module in the `silverstripe` GitHub organisation that you would like to maintain, please email <community@silverstripe.org>.
+
+All maintainers must follow the [house rules](#house-rules).
+
 ### Core Committers
 
 The people looking after the Silverstripe Core modules.
@@ -36,23 +40,76 @@ often working alongside Core Committers.
 
 CMS Squad members have write access to core repositories in order to work effectively with GitHub issues. They are expected to use those permissions with good judgement for merging pull requests.
 
+### Peer Reviewers
+
+[info]
+This is a new role, and is currently in a trial period. It is likely to change over time as we learn what works and what doesn't.
+[/info]
+
+This role is made up of community members who have demonstrated a willingness to improve Silverstripe CMS through their contributions to the open source supported modules. It empowers community members to have a more active role in ensuring pull requests get merged, and builds more momentum for community-created pull requests.
+
+While anyone in the community can review a pull request, only reviews from maintainers have weight of authority - and only maintainers can meaningfully approve changes. The Peer Reviewer role ensures members of the community have that authority.
+
+#### Responsibilities {#peer-reviewer-responsibilities}
+
+* Review pull requests, ensuring documented processes and best practices are being followed
+  * Refer to [how to review pull requests](/contributing/triage_resources/#how-to-review-pull-requests) and [contributing code](/contributing/code/)
+* Escalate pull requests to Core Committers if the contributor is rude/argumentative/hard to deal with
+  * If you feel confident doing so, politely request the contributor behave in accordance with our [code of conduct](./code_of_conduct), and close the pull request if they refuse to do so
+* Escalate pull requests to Core Committers if the PR is very complex and you don't feel confident reviewing it
+  * If another reviewer feels confident, they can offer to review it instead
+* After two maintainers have approved the pull request, merge it
+  * The person who merges the PR must also understand and approve the changes
+  * The person who contributed the PR must not be included as one of the two approving reviewers
+* If you don't feel confident clicking merge, ask for a second opinion. Don’t approve the pull request if you wouldn’t feel confident merging it - instead, say where you got to with it (e.g. tested, worked well locally couldn’t find any problems but want another opinion) and get another reviewer to check it
+  * If no other reviewer feels confident about it, but it seems like it’s probably a good change in general, escalate to Core Committers
+
+In addition to the above responsibilities, if a reviewer doesn’t review any pull requests in a 12 month period, a member of the Core Committers or the CMS Squad team leader will reach out and ask if they want to continue being a reviewer. If they don’t respond within a month (or they respond saying they don’t want to be a reviewer anymore), their permissions will be revoked and they will be removed from the team.
+
+If the reviewer fails to contribute for 24 months in a row, they will be removed from the team until such a time as they can commit to performing the responsibilities of the role.
+
+#### Onboarding new peer reviewers
+
+Members of the community who have shown an interest in helping to maintain Silverstripe CMS, who have shown themselves to be trustworthy, who follow the code of conduct, and who have provided good contributions may be invited by a Core Committer or the CMS Squad team leader to join the peer review team.
+
+Those contributions could be good quality bug reports, good quality pull requests, help refining issues and PRs, and unofficial pull request reviews. These contributions must demonstrate clear communication, adherence to our contribution guidelines, and good collaboration skills.
+
+Anyone in the Core Committers or Peer Reviewers teams plus the CMS Squad team leader can put a name forward of someone they think would be a good fit. All core committers and reviewers and the CMS Squad team leader will have a (timeboxed) chance to object. Then if there’s no objections, the prospective member is invited to join the team.
+
+### Contribution Refiners
+
+[info]
+This is a new role, and is currently in a trial period. It is likely to change over time as we learn what works and what doesn't.
+[/info]
+
+Blah blah refine issue and pull request descriptions
+
+@TODO Documentation includes process for how to identify, invite, and onboard people to the new roles
+
 ## Guidelines
 
 With great power (write access) comes great responsibility.
 
 First and foremost rule of a maintainer is to collaborate with other maintainers. Follow the house rules and remember that others also care about the modules they maintain.
 
-### House rules overview
+### House rules
 
 * Be friendly, encouraging and constructive towards other community members
+* Be familiar with our contribution guidelines, especially the [definition of public API](./public_api/) and how that ties into our branching and release strategies
+* If you have any questions or doubts, always ask - there's a lot of process and domain knowledge, and it is important that you feel confident to fulfil your role
 * Frequently review pull requests and new issues (in particular, respond quickly to @mentions)
 * Treat issues according to our [issue guidelines](/contributing/issues_and_bugs/), and use the [triage resources](/contributing/triage_resources/)
 * Don't commit directly to existing branches, raise pull requests instead
 * Use forks to create feature branches for pull requests
 * Only merge code you have tested and fully understand. If in doubt, ask for a second opinion.
 * Follow the [Supported Modules Standard](https://www.silverstripe.org/software/addons/supported-modules-definition/)
 * Ensure contributions have appropriate [test coverage](/developer_guides/testing/), are documented, and adhere to our [coding conventions](/getting_started/coding_conventions/)
-* Keep the codebase "releasable" at all times (check our [release process](/contributing/release_process/))
-* Follow [Semantic Versioning](/contributing/code/#picking-the-right-version) by putting any changes into the correct branch
+  * If the contributor has trouble adding tests or documentation, you can raise your own pull requests that adds tests or documentation for the change and then merge their change
+* Keep the codebase stable at all times (check our [release process](/contributing/release_process/))
+  * If there are CI failures which are unrelated to the changes a given pull request, you can merge the pull request if all relevant tests are being run and passing
+* Changes must be merged into the appropriate branches and follow semantic versioning (see [picking the right version](/contributing/code/#picking-the-right-version))
 * Be inclusive. Ensure a wide range of Silverstripe CMS developers can obtain an understanding of your code and docs, and you're not the only one who can maintain it.
 * Avoid `git push --force`, and be careful with your git remotes (no accidental pushes)
+* Assign yourself to the issue(s) you are reviewing. If you’re reviewing one pull request in that issue, you’re reviewing them all.
+* Before merging a pull request, check the linked issue for related pull requests which should be reviewed and merged together.
+* Don’t merge documentation for code changes until the code changes have been merged.