bevyengine · cart · Jan 5, 2023 · Jan 14, 2023 · Jan 14, 2023 · Jan 14, 2023
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -66,41 +66,19 @@ Bevy also currently has the following "development process" goals:
   * Most new features should have at least one minimal [example](https://github.com/bevyengine/bevy/tree/main/examples). These also serve as simple integration tests, as they are run as part of our CI process.
   * The more complex or "core" a feature is, the more strict we are about unit tests. Use your best judgement here. We will let you know if your pull request needs more tests. We use [Rust's built in testing framework](https://doc.rust-lang.org/book/ch11-01-writing-tests.html).
 
-## How we're organized
+## The Bevy Organization
 
-@cart is, for now, our singular Benevolent Dictator and project lead.
-He makes the final decision on both design and code changes within Bevy in order to ensure a coherent vision and consistent quality of code.
+The Bevy Organization is the group of people responsible for stewarding the Bevy project. It handles things like merging pull requests, choosing project direction, managing bugs / issues / feature requests, running the Bevy website, controlling access to secrets, defining and enforcing best practices, etc.
 
-In practice, @cart serves as a shockingly accountable dictator: open to new ideas and to changing his mind in the face of compelling arguments or community consensus.
-Check out the next section for details on how this plays out.
+Note that you _do not_ need to be a member of the Bevy Organization to contribute to Bevy. Community contributors (this means you) can freely open issues, submit pull requests, and review pull requests.
 
-[Bevy Org members](https://github.com/orgs/bevyengine/people) are contributors who:
-
-1. Have actively engaged with Bevy development.
-2. Have demonstrated themselves to be polite and welcoming representatives of the project with an understanding of our goals and direction.
-3. Have asked to join the Bevy Org. Reach out to @cart on [Discord] or email us at bevyengine@gmail.com if you are interested. Everyone is welcome to do this. We generally accept membership requests, so don't hesitate if you are interested!
-
-All Bevy Org members are also Triage Team members. These people can label and close issues and PRs but do not have merge rights or any special authority within the community.
-
-Merge rights within the org are relatively centralized: this requires a large amount of trust when it comes to ethics, technical ability, and ability to enforce consistent project direction.
-
-The current structure is as follows:
-
-* @cart is our project lead, and has final say on controversial decisions
-* There is a small group of other maintainers (@alice-i-cecile, @mockersf and @superdump), who have merge rights but abide by the following rules:
-  * Trivial PRs can be merged without approvals.
-  * Relatively uncontroversial PRs can be merged following approval from at least two other community members with appropriate expertise.
-  * Controversial PRs are added to a backlog for @cart to address once two maintainers agree that they are ready.
-  * If 45 days elapse without action on a controversial PR (approval, feedback or an explicit request to defer), they can be merged without project lead approval.
-* The Bevy org is made up of trusted community contributors: this is a relatively low bar, and org members help triage and maintain the project.
-* Community contributors (this means you!) can freely open issues, submit PRs and review PRs to improve Bevy.
-  * As discussed above, community reviews on PRs are incredibly helpful to enable maintainers to merge in uncontroversial PRs in a timely fashion.
+Check out our dedicated [Bevy Organization document](/docs/the_bevy_organization.md) to learn more about how we're organized.
 
 ### Classifying PRs
 
-This strategy relies on a classification of PRs into three categories: **trivial**, **uncontroversial** and **controversial**.
+Our merge strategy relies on the classification of PRs into three categories: **trivial**, **uncontroversial** and **controversial**.
 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.
-PRs that are deemed controversial will receive the `S-Controversial` label, and will have to go through the more thorough review process.
+PRs that are deemed controversial will receive the [`S-Controversial`](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Controversial) label, and will have to go through the more thorough review process.
 
 PRs are trivial if there is no reasonable argument against them. This might include:
 
@@ -125,13 +103,16 @@ PRs are controversial if there is serious design discussion required, or a large
 Finally, changes are "relatively uncontroversial" if they are neither trivial or controversial.
 Most PRs should fall into this category.
 
-## How we work together
+Here are some useful pull request queries:
+
+* [Uncontroversial pull requests which have been reviewed and are ready for maintainers to merge](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+-label%3AS-Controversial+-label%3AS-Blocked+-label%3AS-Adopt-Me+)
+* [Controversial pull requests which have been reviewed and are ready for final input from a Project Lead or SME](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+label%3AS-Controversial+)
+
+### Preparing Releases
 
-Making a game engine is a huge project and facilitating collaboration is a lot of work.
-At the moment @cart is our only paid contributor, so [go sponsor him!](https://github.com/sponsors/cart)
 We track issues and pull requests that must be included in releases using [Milestones](https://github.com/bevyengine/bevy/milestones).
 
-### Making changes to Bevy
+## Making changes to Bevy
 
 Most changes don't require much "process". If your change is relatively straightforward, just do the following:
 
@@ -180,7 +161,7 @@ If you release a game on [itch.io](https://itch.io/games/tag-bevy) we'd be thril
 
 ### Teaching others
 
-Bevy is still very young, and light on documentation, tutorials and accumulated expertise.
+Bevy is still very young, and light on documentation, tutorials, and accumulated expertise.
 By helping others with their issues, and teaching them about Bevy, you will naturally learn the engine and codebase in greater depth while also making our community better!
 
 Some of the best ways to do this are:
@@ -295,15 +276,6 @@ Then notify org members to close the original.
 
 `Adopted #number-original-pull-request`
 
-### Maintaining code
-
-Maintainers can merge uncontroversial pull requests that have at least two approvals (or at least one for trivial changes).
-
-These search filters show the requests that can be merged by maintainers, and those which need a final approval from @cart.
-
-1. Pulls requests which are ready for maintainers to merge without consultation: [requests to pull](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+-label%3AS-Controversial+-label%3AS-Blocked+-label%3AS-Adopt-Me+)
-2. Pull requests which need final input from @cart: [requests to verify](https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+label%3AS-Ready-For-Final-Review+label%3AS-Controversial+)
-
 ### Contributing code
 
 Bevy is actively open to code contributions from community members.

diff --git a/docs/the_bevy_organization.md b/docs/the_bevy_organization.md
@@ -0,0 +1,78 @@
+## The Bevy Organization
+
+The Bevy Organization is the group of people responsible for stewarding the Bevy project. It handles things like merging pull requests, choosing project direction, managing bugs / issues / feature requests, running the Bevy website, controlling access to secrets, defining and enforcing best practices, etc.
+
+Note that you _do not_ need to be a member of the Bevy Organization to contribute to Bevy. Community contributors (this means you) can freely open issues, submit pull requests, and review pull requests.
+
+The Bevy Organization is currently broken up into the following roles:
+
+### Project Lead
+
+Project Leads have the final call on all design and code changes within Bevy. This is to ensure a coherent vision and consistent quality of code. They are responsible for representing the project publicly and interacting with other entities (companies, organizations, etc) on behalf of the project. They choose how the project is organized, which includes how responsibility is delegated. Project Leads implicitly have the power of other roles (Maintainer, Subject Matter Expert, etc).
+
+@cart is, for now, our singular project lead. @cart tries to be accountable: open to new ideas and to changing his mind in the face of compelling arguments or community consensus.
+
+### Maintainer
+
+Maintainers have merge rights in Bevy repos. 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 Leads in moderating the community, handling administrative tasks, defining best practices, choosing project direction, and deciding how the project is organized.
+
+Maintainers abide by the following rules when merging pull requests:
+
+1. Trivial PRs can be merged without approvals.
+2. Relatively uncontroversial PRs can be merged following approval from at least two other community members with appropriate expertise.
+3. Controversial PRs cannot be merged unless they have the approval of a 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.
+
+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:
+
+1. **A strong understanding of the Bevy project as a whole**: our vision, our development process, and our community
+2. **Solid technical skills and code contributions across most engine areas**: Maintainers must be able to evaluate the scope of pull requests, provide complete code reviews, ensure the appropriate people have signed off on a PR, and decide if changes align with our vision for Bevy. This can only be done if Maintainers are technical experts, both generically across engine subject areas, and more specifically in the Bevy codebase.
+3. **Great social skills**: Maintainers regularly deal with and resolve "community issues". They must always present a professional and friendly face. They are representatives of the project and their actions directly reflect our goals and values. Working with them should not be painful.
+4. **Thorough reviews of other peoples' PRs**: Maintainers are the last line of defense when protecting project vision and code quality. They are also often the first people new contributors interact with. They must have a history of leaving thorough and helpful code reviews.
+5. **Ethical and trustworthy behavior**: Maintainers are granted significant administrative permissions. They must be trustable.
+
+To make it easy to reach consensus, hold a high quality bar, and synchronize vision, we intentionally keep the Maintainer team small. We choose new maintainers carefully and only after they have proven themselves in the Bevy community.
+
+If you are interested in a Maintainer role and believe you meet these criteria, reach out to one of our Project Leads or Maintainers. One month after every Bevy release Maintainers and Project Leads will evaluate the need for new roles, review candidates, and vote. Bringing in a new Maintainer requires unanimous support from all Project Leads and Maintainers.
+
+Our current Maintainers:
+
+* Alice Cecile (@alice-i-cecile)
+* François Mockers (@mockersf)
+* Rob Swain (@superdump)
+
+### Subject Matter Expert (SME)
+
+Subject Matter Experts are members of the Bevy Organization that have proven themselves to be experts in a given development area (Rendering, Assets, ECS, UI, etc) and have a solid understanding of the Bevy Organization's vision for that area. They are great people to reach out to if you have questions about a given area of Bevy.
+
+SME approvals count as "votes" on controversial PRs (provided the PR is in their "subject area"). This includes [RFCs](https://github.com/bevyengine/rfcs). If a controversial PR has two votes from Subject Matter Experts in that PR's area, it can be merged without Project Lead approval. If a SME creates a PR in their subject area, this does count as a vote. However, Project Leads have the right to revert changes merged this way, so it is each SME's responsibility to ensure they have synced up with the Project Lead's vision. Additionally, when approving a design, consensus between SMEs and Project Leads (and ideally most of the wider Bevy community) is heavily encouraged. Merging without consensus risks fractured project vision and/or ping-ponging between designs. The "larger" the impact of a design, the more critical it is to establish consensus.
+
+We choose new SMEs carefully and only after they have proven themselves in the Bevy community. SMEs must have a proven track record of the following:
+
+1. **Designing and contributing to foundational pieces in their subject area**: SMEs are responsible for building and extending the foundations of a given subject area. They must have a history of doing this before becoming an SME.
+2. **Thorough reviews of other peoples' PRs in their subject area**: Within a subject area, SMEs are responsible for guiding people in the correct technical direction and only approving things aligned with that vision. They must have a history of doing this before becoming an SME.
+3. **Great social skills**: Within a subject area, SMEs are responsible for reviewing peoples' code, communicating project vision, and establishing consensus. They are representatives of the project and their actions directly reflect our goals and values. Working with them should not be painful.
+
+To make it easy to reach consensus, hold a high quality bar, and synchronize vision, we intentionally keep the number of SMEs in a given area small: 2 is the absolute minimum (to allow voting to occur), 3 is preferred, and 4 will be allowed in some cases. Bevy Organization members can be SMEs in more than one area, and Maintainers can also be SMEs.
+
+If you are interested in a SME role and believe you meet these criteria, reach out to one of our Project Leads or Maintainers. One month after every Bevy release Maintainers and Project Leads will evaluate the need for new roles, review candidates, and vote. Bringing in a new SME requires the support of the Project Leads and half of the Maintainers (however unanimous support is preferred).
+
+Our current Subject Matter Experts:
+
+(Finalizing this list now)
+
+### Bevy Org Member / Triage Team
+
+[Bevy Org members](https://github.com/orgs/bevyengine/people) are contributors who:
+
+1. Have actively engaged with Bevy development.
+2. Have demonstrated themselves to be polite and welcoming representatives of the project with an understanding of our goals and direction.
+3. Have asked to join the Bevy Org. Reach out to @cart on [Discord] or email us at bevyengine@gmail.com if you are interested. Everyone is welcome to do this. We generally accept membership requests, so don't hesitate if you are interested!
+
+All Bevy Org members are also Triage Team members. The Triage Team can label and close issues and PRs but do not have merge rights or any special authority within the community.
+
+### Role Rotation
+
+All Bevy Organization roles (excluding the Triage Team) have the potential for "role rotation". Roles like Project Lead, Maintainer, and SME are intentionally kept in limited supply to ensure a cohesive project vision. However these roles can be taxing, and qualified motivated people deserve a chance to lead. To resolve these issues, we plan on building in "role rotation". What this looks like hasn't yet been determined (as this issue hasn't come up yet and we are still in the process of scaling out our team), but we will try to appropriately balance the needs and desires of both current and future leaders, while also ensuring consistent vision and continuity for Bevy.
+
+Additionally, if you are currently holding a role that you can no longer "meaningfully engage with", please reach out to the Project Leads and Maintainers about rotating out. We intentionally keep leadership roles in short supply to make it easier to establish consensus and encourage a cohesive project vision. If you hold a role but don't engage with it, you are preventing other qualified people from driving the project forward. Note that leaving a role doesn't need to be permanent. If you need to rotate out because your life is currently busy with work / life / school / etc, but later you find more time, we can discuss rotating back in!