Thanks, JB and Alex, for chiming in. While committership criteria were the main topic I wanted to raise, I think we’ve also touched on another critical question: how do we scale our PR review process without sacrificing quality? This may be worth a separate thread.
One observation is that LLMs make it easier for contributors to submit large PRs. Larger PRs not only introduce or overlook mistakes by both humans and LLMs, but also are much harder to review thoroughly. Across multiple OSS communities, we’ve seen large PRs sit for a long time, frustrating both authors and reviewers. Authors think, "I’ve made a substantial contribution, could someone please review it?". Reviewers may really want to help, but finding enough uninterrupted time to thoroughly review a large PR can be tough. As a result, large PRs often have much longer turnaround times than smaller ones. I strongly encourage all contributors to keep their PRs small and focused, even if they can produce a large change quickly. In short: keep your PRs small and focused! Yufei On Mon, Aug 24, 2026 at 6:40 AM Alexandre Dutra <[email protected]> wrote: > 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 >
