So well written AB; exactly. My attempt: FOLLOW-THROUGH (closure == success) is valued over a great quantity of first-drafts. Same energy level is appreciated, just focused instead of spread out.
On Sun, Oct 18, 2026 at 9:35 AM Andrzej Białecki <[email protected]> wrote: > > Eric wrote: > > > 1) We could limit the number of PR's opened, but to me, it just seems like > > we are gating potential new contributions (and anyway we close PR's if they > > don't get activity after a period of time anyway). > > > > I don’t see this as gating in the sense of discouraging new contributors - > quite the opposite, I see this as a quality and closure gate. If all you can > open is 7 PRs you will think twice before opening the 7th one, and you will > be more invested in helping close the first 6. Current situation where anyone > can open 50 PRs and then follow up with rote AI responses is untenable. > > Cheers, > Andrzej > > > On 16 Oct 2026, at 16:16, Eric Pugh <[email protected]> wrote: > > > > > > > > On 2026/09/03 22:44:13 Jason Gerlowski wrote: > >> I'm not sure I agree with the bullish assessment on all fronts haha, > >> but I love the call to action! Both as individuals and as a group we > >> can be doing more to help out contributors. > >> > >> As an aside - I haven't played around with the Github Copilot stuff > >> you mentioned. (Largely because I've been pretty happy with Claude). > >> Maybe I'm alone in being a late adopter there, but if I'm not then > >> maybe that'd make a good demo for our community meetup? Show other > >> committers something that you've seemingly found revolutionary in your > >> review workflow. > >> > >>> Eric cleverly convinced me I wasn't doing enough > >> > >> Never listen to Eric :-p > >> > >> Jason > >> > >> On Thu, Sep 3, 2026 at 12:27 PM Arup Chauhan > >> <[email protected]> wrote: > >>> > >>> Maybe we can get a dedicated open source code review bot and tweak it’s > >>> code for us. That should instill more confidence :) > >>> > >>> > >>> > >>>> On Sep 2, 2026, at 8:02 PM, David Smiley <[email protected]> wrote: > >>>> > >>>> It's never been an easier time as a committer to be the > >>>> shepherd/reviewer > >>>> to a non-committer PR. We have automated code reviews via GitHub > >>>> co-pilot > >>>> (need to add as a reviewer to engage). No longer do we have to edit a > >>>> massive CHANGES.txt to pick a version that might be wrong or even know > >>>> the > >>>> version. No longer do we have the chore of back-porting, for the vast > >>>> majority of PRs. Just pick a final destination Milestone on the PR and > >>>> please DM me a "thank you" if you appreciate this. An LLM armed with a > >>>> script is usually going to do this more thoroughly than you would have > >>>> (i.e. it actually considers multiple CI jobs and usually runs tests > >>>> before > >>>> push). And recently, I'll manually "resolve" the JIRA issue as well as > >>>> the > >>>> final step (if it looks like a one-shot PR issue) -- Eric cleverly > >>>> convinced me I wasn't doing enough, so I've got this ;-). It's really > >>>> rather satisfying. > >>>> > >>>> So with that said, I want to ask the committers here that don't review > >>>> other people's PRs to please do so, especially those of contributors. > >>>> You > >>>> have powers they don't -- you can get something merged. The contributor > >>>> will be grateful; remember being in their shoes. You can fully handle a > >>>> PR > >>>> responsiby without leaving the GitHub PR issue screen -- at least most of > >>>> the time. > >>>> > >>>> p.s. I'm also grateful for Crave.io for very fast builds... but we'll > >>>> need > >>>> to do without this by the end of the year :-( > >>>> > >>>> ~ David Smiley > >>>> Apache Lucene/Solr Search Developer > >>>> http://www.linkedin.com/in/davidwsmiley > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > A big topic at Community/Code this past week across all the projects (not > > just ours) was the benefits and perils of AI assisted coding. During the > > past few months we've seen some very prolific new contributors (thanks > > Serhiy!) start contributing to Solr. The fresh energy has really > > increased our project development. Then we've had Nick join the party, > > and he has gone through our JIRA backlog and cranked out quite a few PR's > > that deal with long dormant tickets. > > > > I wanted to start a thread and share some thoughts with the dev@ list. > > > > There are a couple of approaches we could take to these new contributions. > > > > 1) We could limit the number of PR's opened, but to me, it just seems like > > we are gating potential new contributions (and anyway we close PR's if they > > don't get activity after a period of time anyway). > > > > 2) We probably *should* go back through our JIRA and close issues that are > > no longer relevant to the project so that new contributors don't get > > mislead. Today I would consider any JIRA issue open for Solr as a valid > > one to be worked, but maybe that isnt' the case. > > > > 3) We could establish strong prioritization for what PR's need review. For > > example, when I look at what Nick has provided, maybe we want to focus > > first on bugs before we focus on feature oriented PR's? > > > > 4) We could lean more heavily into AI for evaluating PRs so we can get > > through them easier? I know I struggle with PR's that I want to review, > > but aren't in an area that I have deep expertise in. Unforutantly, too > > many of those PRs then just wither on the vine. > > > > 5) We can try and activate more committers and contributors to be reviwers. > > I'm referencing David's email: "What a time to be a committer in 2026". > > https://lists.apache.org/thread.html/p0cdnwf01v9jb308w4od5bgqp4phno79 > > > > I don't know what the right path forward is, though I suspect it all > > requires us to grow the set of people reviewing PR's. Any approach we > > take hits up against the fundamental limit of us having only so many folks > > actively working PR's and merging them. > > > > Beyond that, I wanted to start thinking about who to tag for review beyond > > the immediate suspects that Github recommends. My thought was "Who are the > > specialists in various areas" that maybe aren't super active, but would be > > happy to engage on a PR. > > > > So I put together this analysis: > > https://claude.ai/code/artifact/2745c59f-a69e-4ee9-9417-6cc421bce4d3?sk=2GexyqEaX33w_f1X3sDw6Q > > > > I'd love feedback on it, I suspect it will go through some iterations to be > > accurate. > > > > Secondly, I wanted to get my arms around the contributions from Nick, as > > there are 30 of them which makes it tough to figure out where to start. I > > went ahead and leaned into my current "Pacific Rim" movie fascination, and > > did an analysis of them. I tried to seperate out the pure bug fix from > > the feature fixes, and get a quick sense of the complexity of going through > > them. > > > > https://claude.ai/code/artifact/60d11ce1-18c8-4699-a3fd-cd2a3c19d8e3?sk=XTELG6l6Mk2QHBBDmdaDog > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
