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] >
