The AI policy and our own AI policy probably need some refreshing and looking at. I haven’t written a line of Solr that wasn’t AI assisted in someway or another in weeks.
And I think it has let me be a better more active reviewer of PR’s. Now if only JIRA had a better MCP/CLI tool ;-) > On Oct 17, 2026, at 10:36 AM, Gus Heck <[email protected]> wrote: > > Another thing to consider when reading that link is that very large AI > companies, which have a HUGE vested interest in the copyright status of AI > outputs likely have lobbyists, and could offer campaign contributions > contingent on support for changes to the laws surrounding AI outputs. > > On Sat, Oct 17, 2026 at 10:27 AM Gus Heck <[email protected]> wrote: > > > Nobody liked it when I pointed it out on the lucene list, but there is ASF > > guidance on this: > > https://www.apache.org/legal/generative-tooling.html#include-in-contributions > > > > <https://www.apache.org/legal/generative-tooling.html#include-in-contributions> > > Note especially the bits about copyright. > > > > The more AI code we accept the more easily disputed our copyright claim > > is. > > > > People seem to get upset, as if I'm trying to take away their candy when I > > point this out, but someday some project will become the test case... > > > > On Fri, Oct 16, 2026 at 10:16 AM 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 > >> > > > <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 > >> <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 > >> > >> <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 > >> > >> <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] > >> > >> > > > > -- > > http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work) > > https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction book) > > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com> (work) > https://a.co/d/b2sZLD9 <https://a.co/d/b2sZLD9> (my fantasy fiction book) Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
