Open Code Review

Bevy had a problem. It was a good problem to have, but still very much a problem. Bevy had grown too popular, too quickly.

Our sole maintainer was stretched impossibly thin, and contributor PRs withered in review limbo as the queue grew and grew. People would pour hours of work into something only to wait weeks for any feedback at all. 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. Even without formal authority, people were already doing useful review work. 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! Peer review centers around the idea that experts, regardless of their affiliation with a particular project or tiny subdomain, are generally pretty good judges of quality, and, with some asterisks, generally trustworthy. 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. Eventually, I suggested giving some formal weight to these community reviews: tag the PRs based on community sentiment 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. 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:

1. Trivial work — typo fixes, small doc improvements — only needs one approval.
2. 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. 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, 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. 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. 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. We occasionally spot serious problems during this final review, and bounce the PR back to the author — and the reviewers who missed it. 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. By the time a maintainer sits down with a PR, most of the hard work is already done.

Open review distributes judgment, not authority. Reviewing a PR doesn’t give you the power to merge it. 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. You can test a PR on your machine and report whether it works. You can review documentation and say whether it makes sense to you as a user. You can spot edge cases, ask about error handling, or point out that an API is confusing. You can check whether there are tests, and whether the tests actually test what they claim to. 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. 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. Over time, they become familiar with how things work, what the project’s conventions are, and what sorts of changes are easy or hard. 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!). When someone consistently shows good judgment, people notice and remember. That reputation leads to more responsibility: triage rights, respect during discussions, and formal roles as the need arises. Open code review works because people who are trusted with real responsibility tend to care more, not less.

Bevy’s experience with open review

This is a weird process. Trusting anyone to review flips the steady progression towards trust that traditional open source uses. In most projects, newcomers are treated with some blend of exasperation, patience, compassion and suspicion, gradually building up trust as they submit PRs, until they are eventually inducted into the inner circle of trusted maintainers.

New contributors are primarily evaluated on and taught through their code outputs, not their review quality. Formally reviewing someone else’s PR often feels like butting in; a failure to read the room that betrays a misunderstanding of how open source works. Even offering critical thoughts can feel presumptuous, and it’s easy to simply keep your stupid questions to yourself to avoid burdening anyone. Open code review turns this on its head: we often tell brand new contributors that they should start by reviewing PRs: asking questions and doing basic quality checks to help them get familiar with the codebase and best practices.

But all of the theory in the world wilts when confronted with real data. What actually happened, both good and bad?

Simple work moves faster. Uncontroversial PRs — bug fixes, doc improvements, small features with clear designs — pick up two community approvals quickly and land smoothly after fairly simple revisions. The common worry, that requiring more review slows things down, gets the bottleneck wrong. You’re blocked on maintainer attention, not community attention. Two rounds of community review then a maintainer LGTM is faster than waiting for maintainers to do all three.

Caveat: reviewers gravitate toward what interests them. Dry infrastructure changes, large, unglamorous cleanups, good but poorly explained changes can and do still wither on the vine. Pestering the community for more reviews helps! In the end, volunteers do as they please, and paid time often has to be spent on the thankless tasks no one picks up.

Work is polished before maintainers ever see it. Everyday contributors reliably catch the obvious issues — missing tests, unclear docs, naming problems, logic bugs. This shouldn’t be surprising: most open source contributors are skilled professionals — they offer real judgment even without full project context.

Caveat: authors need to be taught and empowered to reject feedback. Bikeshedding is an easy trap when you have so many cooks, but it can’t be allowed to halt work dead. Scope creep is the real risk though: “better than before” and “meets project standards” is a good threshold. Authors have to be able to hold that line against reviewers, and be backed up when they do.

Complex work is safer but slower. Large or controversial PRs get picked over by many pairs of eyes, and design concerns are surfaced early, when they’re still cheap to fix. Review doesn’t create conflict; it surfaces it earlier, and the PR is usually better for it.

Caveat: if everyone is empowered to offer critique, it’s easy for deadlock to form. You need designated experts who are empowered to make calls, and willing to do so. Without that backstop, a contested PR can stall forever.

Users get directly involved. Because reviews are open, we can pull the actual people who filed the issue or asked for the feature into reviewing the fix themselves — verifying that the implementation met their real needs, rather than guessing on their behalf.

Caveat: gently pinging users who request features and report bugs works maybe a third of the time. Filing an issue is much lower investment than reviewing a PR, and it may be years between an issue and a fix. It’s wonderful when it works, but you should treat it as a happy bonus.

Our culture became more egalitarian. No one is above reproach, curiosity is welcomed, and everyone can have something worth saying. A new contributor publicly catching a real bug in the work you spent weeks refining is humbling, and reinforces both the value of the policy and this culture. Policy shapes culture shapes policy: be intentional about it.

Caveat: Waiting for volunteer reviews and explaining plus justifying your decisions as a maintainer can be slow and frustrating. The urge to just bypass review and push to main is very real. You get attention faster, but your trusted celebrity status means that those reviews are often less critical than they should be, and you have to push back, explaining that people aren’t being mean enough to you! Expect to work on many tasks in parallel.

You should try open code review

Bevy’s problems used to be unusual: explosive growth left us with a mountain of reasonable code to review, with only a tiny handful of experienced, trusted maintainers.

With the rise of the LLM, every actively-used open source project is staring down a landslide of well-intentioned code, and review has become the universal bottleneck. If your review process depends entirely on a trusted core that isn’t keeping up with the growth in contributions, it will eventually fail under load. There simply aren’t enough hours in the day.

If you want to try open code review, start small:

• Write a short review guide: what to look for, how to give feedback, what not to do.
• Make it clear that review from anyone is welcome, not just tolerated.
• Give people triage rights so they can help organize the work.

Remember: if the experiment fails, you can always revert.

The people who care about your project — who file issues, ask questions, submit patches, hang out in your Discord — want it to succeed. You can trust them.

Code is cheap. Judgement is expensive. Ask for that.

This blog post covers the same content (with minor differences for format) as my RustWeek 2026 talk! A link to a recording will be posted when available.