Hi All, +1 to faster review/merge cycle and fix-forward mentality.
For larger PRs if the first reviewer feels like a second opinion could be beneficial, there is always the option to wait for more reviews and/or invite specific other reviewers. Cheers, Dmitri. On Mon, Aug 24, 2026 at 9: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 >
