Hi Yufei, I now have a better understanding of the purpose of your message.
I think we need to distinguish between two different metrics: - The time to initial review response - The time to merge Regarding initial response time, I agree that responding quickly is important to keep contributors motivated and help grow the community. However, time to merge is not a critical metric in my view. Project quality and long-term sustainability are much more important. Iterations and discussions on a PR are normal, and our role as committers is to build consensus to move the project forward. Finally, I encourage reviewers to request additional reviews from other committers when needed, as relying on single-reviewer approvals can sometimes create bottlenecks. Regards, JB On Wed, Sep 2, 2026 at 10:51 AM Yufei Gu <[email protected]> wrote: > > 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 > >
