I would rather be the one who comments on old tickets, I have already done a lot of research. Skill files are welcome.
The ASF's LLMAO uses Gemma4-26b, a very weak model released in April that scores only 17 on the Intelligence Index (LMAO). Haiku 5.5 scores 38 at High effort, 29 at Low effort. Claude subscriptions are generous with tokens, and I know many of us use them. A sweep needs to achieve something more than a ping. A bot should only comment when it moves something forward. For example: - Reproduction possible from code-reading? Ask if there is interest in a fix. If not possible, ask for details. - Ticket should be closed? Point to the evidence and ask if closure is okay. No reply? Close it. - Ticket needs a maintainer decision? Post a decision ladder and ask if there is interest. Maybe tag someone else. - Can't resolve? Avoid commenting; a better workflow will resolve it later. The goal should be to generate PRs after a human agrees to review a fix. No response from the ticket creator doesn't mean the ticket should close. No buy-in means no public interest in a fix at this time. It should not mean, "Apparently no problem exists, let's close it". I decided to start commenting on old tickets, here is how my initial sample breaks down: 44=Close candidate 57=Candidate fix 8=Maintainer question 109=Total Let me know how I can make this less noisy or more optimized before I do another batch. On Sun, Oct 25, 2026 at 6:39 PM Jan Høydahl <[email protected]> wrote: > I am creating a "solrbot" user account on JIRA similar to what we have on > Github, > to run a small experiment. > > Jan > > > 25. okt. 2026 kl. 23:12 skrev Amrit Sarkar <[email protected]>: > > > > My 2 cents on Jan’s plan: I have local LLM compute and could run the > triage > > skill on it, so quota wouldn’t be a concern. That’s one more option to > > consider. The downside is that it would run independently on my machine > and > > wouldn’t be visible to other committers, so it may not be the best > approach. > > > > Amrit Sarkar > > Engineer | Search and Kubernetes > > https://seamadic.com/ > > Twitter https://twitter.com/sarkaramrit2 > > LinkedIn: https://www.linkedin.com/in/sarkaramrit2 > > Medium: https://medium.com/@sarkaramrit2 > > > > > > On Sun, Oct 25, 2026 at 2:41 PM Jan Høydahl <[email protected]> wrote: > > > >> I don't know how big of a quota we have from the new > >> https://llm.apache.org > >> If we made a really good issue triaging SKILL and let an LLM loose on > the > >> backlog, > >> it could chew 100 JIRAs a day and we'd be throug the backlog in 6 weeks. > >> A majority of issues would likely be closed by such a skill. Others > would > >> receive a > >> comment, tagging the author, and if no reply in 14 days it would close. > >> Yet others > >> would be confirmed an active bug, receive some labels (e.g. a > "confirmed" > >> one), a > >> category, a severity, and be up for grabs by contributors. > >> > >> 100 issues@ emails a day is a lot, so it could optionally use the bulk > >> feature for the > >> obvious ones, skipping notification emails. > >> > >> WDYT? > >> > >> Jan > >> > >>> 24. okt. 2026 kl. 16:30 skrev David Smiley <[email protected]>: > >>> > >>> I’m warming up to this +1 > >>> Maybe phase one should exclude bugs. > >>> > >>> On Sat, Oct 24, 2026 at 9:36 AM Andrzej Białecki <[email protected]> > wrote: > >>> > >>>> I was reminded of this thread by Jan in another thread (thanks!). > >>>> > >>>> +1 to your plan with the three Tiers. I would only add that the ticket > >>>> severity should play a role, too - issues marked as Critical should > get > >>>> more attention (there are a few dozen such issues at the moment). > >>>> > >>>> Cheers, > >>>> Andrzej > >>>> > >>>>> On 10 Jun 2026, at 10:13, Jason Gerlowski <[email protected]> > >> wrote: > >>>>> > >>>>>> I know there are different philosofies on such gardening. Some hate > >> it, > >>>> some love it, some don't care. > >>>>> > >>>>> I think I'm in the "don't care" category. Or at least, I'm not sure > >>>>> how to feel about it. I tend to use JIRA to track my own work or > read > >>>>> about what others have been working on recently (via the mailing > >>>>> list). I haven't seen "noise" being a big problem there, but I'm > open > >>>>> to folks having different usage patterns where there is more negative > >>>>> impact. Was just fishing for a concrete example I guess :-p. I > >>>>> appreciate the addtl detail! > >>>>> > >>>>> Consider me a +0. Agree with David's comment that it'd be great to > >>>>> find an appropriate Resolution that'd make the "auto-closed for > >>>>> staleness" easy to detect down the road. > >>>>> > >>>>> Best, > >>>>> > >>>>> Jason > >>>>> > >>>>> > >>>>> On Fri, Jun 5, 2026 at 9:45 PM Jan Høydahl <[email protected]> > >>>> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> 8.5 years mean age. You can pick a random open JIRA issue for Solr > and > >>>> most likely you'll find that it is not open at all, it is something > >> that is > >>>> either not relevant anymore, fixed somewhere else or just an idea that > >>>> stalled 5 years ago and is superceded by something else. > >>>>>> > >>>>>> Whether it is a problem depends on what you expect from an issue > >>>> tracker and what you expect from a "state" field. > >>>>>> Some might not care at all, and that's ok. I think this much cruft > is > >> a > >>>> noise issue. And it is easy to deal with. > >>>>>> I call it gardening. > >>>>>> > >>>>>> If we did not have stalebot for PRs, I'm sure there would have been > >>>> 2000 open PRs instad of the current 281... I have been reminded a few > >> times > >>>> by the bot that I had some work that started to go stale, and I'm > >> triggered > >>>> to either bring it to completion or close it. I want to do the same > with > >>>> Github Issues once we (perhaps) migrate away from JIRA. > >>>>>> > >>>>>> I know there are different philosofies on such gardening. Some hate > >> it, > >>>> some love it, some don't care. > >>>>>> > >>>>>> Jan > >>>>>> > >>>>>>> 5. juni 2026 kl. 21:30 skrev Jason Gerlowski < > [email protected] > >>> : > >>>>>>> > >>>>>>> You mention the existing situation being untenable - can you expand > >> on > >>>>>>> that a bit please? Are the old, untouched JIRAs causing some sort > of > >>>>>>> problem? > >>>>>>> > >>>>>>> Best, > >>>>>>> > >>>>>>> Jason > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> 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] > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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] > >
