Clarify PR Merging Rules in Contributing Guide

content/learn/contribute/helping-out/opening-pull-requests.md

@@ -15,8 +15,8 @@ Most changes don't require much "process". If your change is relatively straight
     * [Pull Request](https://github.com/bevyengine/bevy/pulls) (or PR for short): A request to merge code changes. This starts our "review process". You are welcome to start with a pull request, but consider starting with an Issue or Discussion for larger changes (or if you aren't certain about a design). We don't want anyone to waste their time on code that didn't have a chance to be merged! But conversely, sometimes PRs are the most efficient way to propose a change. Use your own judgment here.
 2. Other community members review and comment in an ad-hoc fashion. Active Subject Matter Experts may be pulled into a thread using `@mentions`. If your PR has been quiet for a while and is ready for review, feel free to leave a message to "bump" the thread, or bring it up on [Discord] in an appropriate engine development channel.
 3. Once they're content with the pull request (design, code quality, documentation, tests), individual reviewers leave "Approved" reviews.
-4. After consensus has been reached (typically two approvals from the community or one for extremely simple changes) and CI passes, the [S-Ready-For-Final-Review](https://github.com/bevyengine/bevy/issues?q=is%3Aopen+is%3Aissue+label%3AS-Ready-For-Final-Review) label is added.
-5. When they find time, someone with merge rights performs a final code review and queues the PR for merging.
+4. After consensus has been reached (see [Reviewing Pull Requests](@/learn/contribute/helping-out/reviewing-pull-requests.md#how-pull-requests-are-merged) for more on that) and CI passes, the [S-Ready-For-Final-Review](https://github.com/bevyengine/bevy/issues?q=is%3Aopen+is%3Aissue+label%3AS-Ready-For-Final-Review) label is added.
+5. When they find time, a Maintainer, or the Project Lead, performs a final code review and queues the PR for merging.
 
 [Discord]: https://discord.com/invite/bevy
 [GitHub Discussions]: https://github.com/bevyengine/bevy/discussions

content/learn/contribute/helping-out/reviewing-pull-requests.md

@@ -58,3 +58,18 @@ Not even our Project Lead and Maintainers are exempt from reviews and RFCs! By g
 Finally, if nothing brings you more satisfaction than seeing every last issue labeled and all resolved issues closed, feel free to message @alice-i-cecile or @cart for a Bevy Org role to help us keep things tidy.
 
 As discussed in our page on [The Bevy Organization](@/learn/contribute/project-information/bevy-organization.md), this role only requires good faith and a basic understanding of our development process.
+
+## How Pull Requests are merged
+
+
+Maintainers abide by the following rules when merging pull requests:
+
+1. Trivial PRs can be merged with approval from one community member (including Maintainers).
+2. Relatively uncontroversial PRs can be merged following approval from at least two community members (including Maintainers) with appropriate expertise.
+3. Controversial PRs cannot be merged unless they have the approval of the Project Lead, or two Subject Matter Experts (in the "area" of the PR).
+4. If two Maintainers have approved a controversial PR they can "start the clock" on a PR by adding it to [this queue](https://github.com/orgs/bevyengine/projects/6). If 45 days elapse without SME or Project Lead action (approval, feedback or an explicit request to defer), the PR can be merged by maintainers.
+
+{% callout() %}
+To read more on Maintainers, check out our section on them in our [The Bevy Organization](@/learn/contribute/project-information/bevy-organization.md#maintainer) page.
+{% end %}
+

content/learn/contribute/project-information/bevy-organization.md

@@ -25,7 +25,7 @@ The Project Lead has the final call on all design and code changes within Bevy.
 
 Maintainers have merge rights in Bevy repositories. They assess the scope of pull requests and whether they fit into the Bevy Project's vision. They also serve as representatives of the Bevy Project and are often the interface between the Bevy community and the Bevy Project. They assist the Project Lead in moderating the community, handling administrative tasks, defining best practices, choosing project direction, and deciding how the project is organized.
 
-Maintainers abide by the rules described in the section on [Reviewing Pull Requests](@/learn/contribute/helping-out/reviewing-pull-requests.md) when merging pull requests.
+Maintainers abide by the rules described in the section on [Reviewing Pull Requests](@/learn/contribute/helping-out/reviewing-pull-requests.md#how-pull-requests-are-merged) when merging pull requests.
 
 We choose new Maintainers carefully, and only after they have proven themselves in the Bevy community. Maintainers must have a proven track record of the following:
 

content/learn/contribute/reference/triage.md

@@ -46,7 +46,7 @@ Labels are our primary tool for organizing work. You can find a complete list wi
 
 You can learn more about labels on [GitHub's documentation](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels).
 
-The rules for how PRs get merged depend on their classification by controversy and difficulty. More difficult PRs will require more careful review from experts, while more controversial PRs will require rewrites to reduce the costs involved and / or sign-off from Subject Matter Experts and Maintainers.
+[The rules for how PRs get merged](@/learn/contribute/helping-out/reviewing-pull-requests.md#how-pull-requests-are-merged) depend on their classification by controversy and difficulty. More difficult PRs will require more careful review from experts, while more controversial PRs will require rewrites to reduce the costs involved and / or sign-off from Subject Matter Experts and Maintainers.
 
 When making PRs, try to split out more controversial changes from less controversial ones, in order to make your work easier to review and merge. Also consider splitting simple changes from complex ones, since the simple changes can be reviewed and merged much quicker.