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]
