Hi Yufei, I'd suggest we separate two things: the surging volume of PRs and how we review them, versus the criteria for offering committership in Polaris.
On the committership criteria, I agree that sustained, high-quality review is harder to fake than PR count and it's a better signal of the things that actually matter for a committer: knowing the codebase well enough to catch real problems, and knowing where your knowledge ends. But IMHO the real problem is PR review. With AI accelerating code generation, the primary bottleneck across open-source projects has transitioned to the review phase. Here are a few levers we could try: * Lean harder on AI-assisted review. We use Copilot today, but not on every push, to keep costs down. Would it make sense to use it more thoroughly? * Require a design doc or dev@ discussion + CHANGELOG.md entry upfront when opening big PRs (say, > 20 files). * Streamline approval requirements. Except for trivial changes, we tend to wait for two or more approvals today, which creates a delay. Switch to single approvals and a fix-forward mindset. * Better test coverage signal. We don't measure coverage across Polaris precisely today; if we did, reviewers would have a clearer sense of which PRs carry real risk and deserve a deep read. * Introduce CODEOWNERS. Auto-request the right domain reviewers instead of PRs sitting unclaimed while everyone assumes someone else will take it. * Introduce automatic labeling. A risk classification (trivial, contained, architectural) + area classification (storage, persistence, events, REST, Helm chart, Python client, etc.) would let us route reviewer attention where it matters instead of spreading it evenly. Iceberg has something in this style [1]. * Limit concurrent contributions. Github has recently introduced a setting that limits the number of open pull requests for users without write access [2]. * On-duty review shifts. A group of weekly on-duty reviewers triage incoming PRs - no deep review, just classify, route, and close what shouldn't proceed. The on-duty reviewers could share a Kanban-like dashboard to facilitate triaging. Thanks, Alex [1]: https://github.com/apache/iceberg/blob/a59412193eebe8f57595b18730b1c3f36efc046c/.github/labeler.yml [2]: https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/ On Mon, Aug 24, 2026 at 12:08 PM Jean-Baptiste Onofré <[email protected]> wrote: > > Hi Yufei, > > While I agree with your points, could you clarify the specific > discussion topic or problem statement you are addressing? > > Evaluating committer candidates based on both the nature of their > contributions and their overall project activity is already our > standard practice. While I agree that good reviewers are necessary, I > believe we should focus on quality over quantity. It is preferable to > have fewer, high-quality reviewers and to trust our committers to > consult others when needed. > > Regards, > JB > > On Sun, Aug 23, 2026 at 9:56 AM Yufei Gu <[email protected]> wrote: > > > > Hi everyone, > > > > LLMs make it easier to write code and open PRs. The Polaris community has > > seen a lot of PRs recently, which is great, or at least a good problem to > > have. But it also means thoughtful, high-quality review matters more than > > ever. Our bottleneck is having enough reviewers to evaluate PRs carefully, > > maintain project quality, and keep Polaris moving in the right direction. > > > > I think reviewing others’ PRs or design docs can be as valuable as, and > > sometimes more valuable than, opening more PRs. I believe sustained, > > high-quality review should be a key consideration for committership. For > > me, it comes down to three things: > > > > 1. The community needs to trust a committer to review and merge PRs > > responsibly and independently. > > 2. We need more good reviewers. They help other contributors improve, > > spread knowledge, and keep the project's quality high. > > 3. Nobody knows every part of the project. A good committer knows when > > to ask someone with more context before merging, and when not to merge at > > all. > > > > Going forward, I’ll give sustained, high-quality review more weight than PR > > count when considering someone for committership. This doesn’t diminish the > > value of authoring PRs. Authoring and reviewing design documents, along > > with technical discussions on the dev mailing list, are also essential > > contributions. > > Yufei
