Thanks everyone for the thoughtful feedback! I really appreciate you taking the time to share your thoughts and experiences.
Yong, I'm glad to hear that Orca is helping here! JB, I agree that the two-working-day rule is not a commitment. Dmitri, agreed. We should adjust our approach to align with the new ASF rules. Yongrea, thanks for sharing your practices! I especially appreciate the effort to keep PRs small and focused. That's exactly what we want to encourage. Looking forward to see more reviews and contributions from you! Yufei On Fri, Oct 30, 2026 at 7:07 PM youngrae kim <[email protected]> wrote: > > Hi all, > > +1 to both points, from the contributor side. > > Two things that worked well for me over the last few weeks, in case they > help others: > > - Writing the reproduction test first and quoting the failing behavior in > the PR description. > Reviewers could check the claim in a minute, and the AI pre-review bot > had something concrete to verify against. > - Reviewing PRs in the areas I had just touched (federation connection > configs, credential vending, exception mapping). > Even partial reviews surfaced things like missing spec fields and > outdated docs, and reading other people's changes was the fastest way to > learn the codebase. > I will keep saying explicitly which part I looked at, as JB suggests. > > I will keep taking small reviews in those areas. > If there is a list of PRs waiting for a first look, pointing new > contributors at it would make it easier to pick something up. > > Youngrae Kim > > 2026년 10월 31일 (토) 오전 2:35, Jean-Baptiste Onofré <[email protected]>님이 작성: > > > Hi Yufei > > > > Fully agree. > > > > That said, I think most of this is already written down in the > > CONTRIBUTING.md. It has the "Guidelines for AI-assisted Contributions" > > section. It clearly states that the person opening the PR is the author, > > must understand the change end-to-end, and must be able to explain and > > justify the design and the code. > > AGENTS.md also goes further for coding agents. > > I don't think we need new rules and being strict (it can be seen as > > pedantic :)), instead we should point contributors to CONTRIBUTING.md and > > AGENTS.md, reviewers should feel free to link them when a PR clearly needs > > to follow them. > > > > I fully agree on small PRs. I think it can make sense to have a large draft > > PR to illustrate a concept and split in smaller PRs in a follow-up. It's > > what I did for Polaris Directories,. > > > > To Yong, for reference, CONTRIBUTING.md says "two working days is a good > > base to get first reviews and comments". It's a guideline to give reviewers > > time, not a commitment to merge within that window. It's extremely hard > > (and pretty risky) to announce any commitment around that. I strongly > > against because it's not the Apache philosophy: we are all contributing as > > individual, volunteer, best effort. For some of us, it's also our job, but > > it doesn't change the philosophy. As I said in a previous thread, a fast > > first response is important to keep contributors motivated, but time to > > merge is less important than quality and review. > > > > AI review tools are clearly a good first pass, for authors and reviewers, > > but they don't replace committer review. Ideally, contributors address (or > > answer) the bot comments before asking for a human review. > > > > Partial reviews are also very welcome. If you only review part of a PR, > > it's completely fine (it should be mentioned to inform the other > > reviewers). > > > > Regards > > JB > > > > On Fri, Oct 30, 2026 at 6:09 PM Yufei Gu <[email protected]> wrote: > > > > > Hey folks, > > > > > > It’s great to see more contributions coming into Polaris! At the same > > time, > > > the review load is pretty high, so it’s normal for some PRs to take > > longer > > > to get reviewed. > > > > > > I’d encourage more people to help with reviews. It is helpful even you > > > don’t review the whole PR and look at the parts you’re familiar with and > > > sharing feedback. > > > > > > For authors using AI, I think we should be the first reviewers of the > > code > > > and docs it generates. At least read and understand what you’re > > submitting, > > > and challenge its decisions. Do we really need this extra doc or a new > > > interface? Can we solve the problem within the existing design? A few > > > rounds of AI review, combined with your own judgment, can help catch > > issues > > > that a single pass might miss. Few-shot is always better than one-shot, > > > esp. with human’s insights. Taking responsibility for this initial review > > > helps reduce the back and forth with reviewers. > > > > > > As I mentioned in my earlier email [1], please keep PRs small and well > > > scoped. They’re easier to review thoroughly and usually have a faster > > > turnaround. Even if AI makes it easy to produce a large change quickly, > > > splitting it into focused PRs still helps everyone. > > > > > > Just my two cents. Curious what you all think. > > > > > > Thanks, > > > Yufei > > > > > > [1] PR review and committership, September 2 ( > > > https://lists.apache.org/thread/jdsc283vwbrff822kw2hh5nlb6qbw6x6) > > > > >
