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]
