Open Code Review | Shaping Systems<br>Bevy had a problem.<br>It was a good problem to have, but still very much a problem.<br>Bevy had grown too popular, too quickly.

Our sole maintainer was stretched impossibly thin,<br>and contributor PRs withered in review limbo as the queue grew and grew.<br>People would pour hours of work into something only to wait weeks for any feedback at all.<br>Many of them gave up, walking away as merge conflicts grew like weeds on their PRs.

But as the backlog grew, I noticed something interesting.<br>Even without formal authority, people were already doing useful review work.<br>They were asking good questions, catching bugs, suggesting small fixes, testing things on their own machines.

Coming from a background in science, this made a lot of sense to me!<br>Peer review centers around the idea that experts, regardless of their affiliation with a particular project or tiny subdomain,<br>are generally pretty good judges of quality, and, with some asterisks, generally trustworthy.<br>We let anyone submit PRs without vetting: why is the bar higher for reviewing?

The community kept reviewing the PRs, and I kept asking these questions.<br>Eventually, I suggested giving some formal weight to these community reviews: tag the PRs based on community sentiment<br>to make it visible to the maintainer at a glance for when they want to make the dreaded open PR count go down.

It was weird, but we were willing to experiment.<br>If it didn’t work, we could always revert.

Bevy’s open code review process

Over the years, we’ve settled on a set of simple, permissive, and clear rules.

Anyone can review anything. You don’t need to be a maintainer, you don’t need to be on a team, you don’t need permission. If you have something useful to say about a pull request, say it.

Two approvals from the community before a PR is marked as Ready-for-Final-Review. Work that everyone thinks is good gets bumped up the queue for consideration.

There are two wrinkles to those rules:

Trivial work — typo fixes, small doc improvements — only needs one approval.

Controversial work — things with high architectural impact, or where people can’t stop arguing — gets routed to designated experts who can make a call.

Importantly, maintainers cannot shortcut this process.<br>This is essential for dogfooding the process, fostering a sense of fairness and reaping the benefits of the review process for our own work.

Because Github doesn’t think that reviews from people without write permissions count,<br>the community itself tracks the progress of work using widespread triage rights.

To close the loop, we clean out the backlog once a week, using those distributed labels to find the work that the community thinks is ready to merge.<br>As a maintainer, this final review pass typically means spending a few minutes to consider the rationale and context, do a quick final quality pass, check for blockers in the unresolved feedback, and make a decision.<br>If the work is more serious, we’ll give it our own review, kicking it over to a fellow maintainer or pestering subject-matter experts for opinions where we have holes in our expertise.<br>We occasionally spot serious problems during this final review, and bounce the PR back to the author — and the reviewers who missed it.<br>But most of the time, the conclusion is “LGTM; merging!”.

Code review is for everyone

You should think about open code review as a funnel: community review catches the obvious problems, refines the design, and builds consensus.<br>By the time a maintainer sits down with a PR, most of the hard work is already done.

Open review distributes judgment, not authority.<br>Reviewing a PR doesn’t give you the power to merge it.<br>It lets you say “here’s what I think” in a way that counts.

Fundamentally, code review doesn’t require deep expertise to be valuable.<br>You can test a PR on your machine and report whether it works.<br>You can review documentation and say whether it makes sense to you as a user.<br>You can spot edge cases, ask about error handling, or point out that an API is confusing.<br>You can check whether there are tests, and whether the tests actually test what they claim to.<br>None of this requires you to be an expert in the subsystem being changed.

Every time someone gives or receives a review, they learn something.<br>Each PR is a tiny lesson for reviewer and author alike: here’s a corner of the codebase, here’s what changed, here’s why.<br>Over time, they become familiar with how things work, what the project’s conventions are, and what sorts of changes are easy or hard.<br>Best practices — tests, docs, code style — spread through review culture far more effectively than through any written guide.

This repeated interaction builds trust and reputations (that’s game theory for you!).<br>When someone consistently shows good judgment, people notice and remember.<br>That reputation leads to more responsibility: triage rights, respect during discussions, and formal roles as the need arises.<br>Open code review works because people who are...