Hello, Solr! Nick here, I had a great chat with Eric and I am excited to be here. I know I opened many PRs and I look forward to being part of the community while following community norms.
There has never been a better time to be a contributor; I have a lot to share. Big thanks to David Smiley for all the backports. This email is my attempt at the follow-through this thread asks for. TL/DR: I will clear out blocker and critical items first. A list of 10 easy PRs and 10 Blocker/Critical PRs is at the bottom. 1. How the work is done - I work through the backlog with AI assistance, and every PR description says so. - Nothing goes out under my name that I have not read first. - I direct the work and I stand behind it; the commits carry my name because they are mine to answer for. - Results: 90 open PRs, 12 that have merged. - I answer review comments the day they arrive. - I reply with my human voice when I can. 2. Taking the criticism - The criticism I take from this thread is about closure, not effort, and I think that is fair. - A PR that sits open is not finished work, however fast its author replies. - Spread out is a fair description of the queue. It is not a fair description of any single PR in it. - Software factories are not built in a day and quality beats volume. 3. What follow-through means from my side - Every comment gets an answer. - I check if a change is even worth it first. I check if code could be removed rather than added. I slow down to try to understand more. - If a PR of mine goes quiet because the next step is mine, that is on me. - I will talk about my PRs on the mailing list. 4. The two-sided part - Closure takes two people. A PR can be ready, answered, and green, and it still closes only when a reviewer picks it up. 5. The priority commitment - My order from here is Blockers and Criticals first, then "new developer". I also check PRs from others. - Open Blocker tickets will get PRs or JIRA notes this week. 6. Drafts - I will stop parking finished work as drafts. - Drafts from me will mean genuinely unfinished, and there will be few of them. 7. What I am not asking - For the cap to be lifted for me. - For anyone to believe I am a human. In closing, - Tell me where this is wrong. I am teachable. - Thank you to the people who have been merging this work, including this week. 10 Blocker/Critical PRs: - #5181 https://github.com/apache/solr/pull/5181 · SOLR-18552 · Blocker · 9.x launcher passes the MMapDirectory arena permits - #5199 https://github.com/apache/solr/pull/5199 · SOLR-14200 · Critical · streaming fails clearly instead of an NPE on a missing shards-map entry - #5200 https://github.com/apache/solr/pull/5200 · SOLR-16155 · Critical · field values out of indexing error messages - #5003 https://github.com/apache/solr/pull/5003 · SOLR-7394 · Critical · clear the recovering shard-terms entry when recovery is abandoned - #5139 https://github.com/apache/solr/pull/5139 · SOLR-7550 · Critical · a 500 for the versions request counts as success when cantReachIsSuccess is set, same as a 503 - #5093 https://github.com/apache/solr/pull/5093 · SOLR-16655 · Critical · indexing nested documents and update processors - #5118 https://github.com/apache/solr/pull/5118 · SOLR-18010 · Critical · security.json replacement through a synced temp file - #5203 https://github.com/apache/solr/pull/5203 · SOLR-17844 · Blocker · sort-assertion test repair - #5202 https://github.com/apache/solr/pull/5202 · SOLR-18446 · Blocker · collection routing follows the path, not the parameter - #5117 https://github.com/apache/solr/pull/5117 · SOLR-18541 · Major · distributed search returns wrong totals, silently 10 Easy-to-review PRs: - #5116 https://github.com/apache/solr/pull/5116 · SOLR-18540 · gradlew under Git Bash · 13 lines - #5098 https://github.com/apache/solr/pull/5098 · SOLR-18530 · route adds after the proxy cut in recovery · 20 - #5002 https://github.com/apache/solr/pull/5002 · SOLR-11431 · a core that fails to load returns 503, not 500 · 23 - #5090 https://github.com/apache/solr/pull/5090 · SOLR-14262 · skipped commit and the update log · 34 - #5094 https://github.com/apache/solr/pull/5094 · SOLR-16673 · numeric field update processors · 34 - #5104 https://github.com/apache/solr/pull/5104 · SOLR-2681 · original highlighter term extraction · 35 - #5086 https://github.com/apache/solr/pull/5086 · SOLR-12864 · test coverage for echo with mapUniqueKeyOnly · 37 - #5131 https://github.com/apache/solr/pull/5131 · SOLR-5394 · default per-field thread count · 37 - #5158 https://github.com/apache/solr/pull/5158 · SOLR-10305 · distributed request on a schema with no unique key · 42 - #5105 https://github.com/apache/solr/pull/5105 · SOLR-4540 · FastVectorHighlighter per-field work · 43 On Thu, Oct 22, 2026 at 4:26 PM David Smiley <[email protected]> wrote: > 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] > >
