I’ll add in a bit of personal perspective. Working on Solr used to be my full time job; I have since moved on to other (sometimes less green) pastures. I still keep an eye on the project because it interests me and I enjoy the people. But anything I filed as a feature or improvement back in 2022 was probably a wish list item to make my own job easier. Those might still be helpful if they generalize but they also might not. I never went back and said “this is no longer important” on that list.
An analogy, I walk to school every day and asked the city to put in some flowers along the path. Then I graduate and move to a new place, and some city administrator sees my request after a while. They put in the flowers but I’m not there to enjoy them. Maybe I was the only one to walk that path, or maybe there are others who will appreciate them. Mike On Fri, Oct 23, 2026 at 3:37 PM David Smiley <[email protected]> wrote: > Hello Nick! > > Thanks for contributing to the discussion here. > > If you (Nick) were doing work on matters of specific interest to you, > then I wouldn't advise you much on selecting such work since they > matter to you enough to bother producing a solution. And one person's > actual focus can only be so much. But that's not the case here; > you've built a software factory that could work on anything with > boundless focuss. I want to flip this around so that *committers* > (not your factory!) choose what to really start work on! Committers > (or any human I guess) should first confirm that we want solutions for > certain JIRA issues. Otherwise (current state), your choices have > dominated our review time, even when you don't know what the > committers collectively consider to be important (i.e. by at least one > of us, *wanting* a solution to a specific issue to review). Any PRs > aren't going to even get a review. **Basically, I want your factory > to solicit a reviewer on a specific issue before starting work.** > That's the ask. Not merely whether someone cares, but who will > review? The next step might be a PR but I hope in many cases would be > a *plan* (comment on a JIRA issue) of work that could first be > negotiated. For example if there's an alleged bug, maybe the first > step is simply a reproduction attempt to validate it, or a code > reading assessment of the bug as a substitute (if not easily > reproduced). > > The JIRA issue "priority" hasn't been populated with selection > criteria or consequence for the choice, so it's often the default > value of "Major". Often it's chosen by a contributor, not a > committer. We mostly ignore it TBH. I can sympathize your factory > needs *something* to use as a backlock prioritizer, and might as well > pick this. I just want to highlight how inadequate it is at the > moment. I may bump up the priortity of some JIRA issues to "Critical" > despite that word sounding rather alarmist/excessive for some work. > I don't think "newdev" should be a backlog prioritization factor. > > Take care to see when there's existing work on an issue (PR or > attached patch) or if it's "Assigned" to someone. Avoid those. > > ~ David > > On Fri, Oct 23, 2026 at 12:15 PM Nick Boss <[email protected]> wrote: > > > > 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] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
