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]
