You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Jan Høydahl <ja...@cominvent.com> on 2026/05/29 13:57:11 UTC
[DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Hi all,
This thread complements the ongoing discussion about migrating to GitHub Issues, but is worth pursuing regardless of how that ends.
I have raised the idea of a major JIRA cleanup several times before. The usual pushback is that important work or still-reproducible bugs would be lost forever. I understand the concern, but I think the current situation has become untenable: the median age of an open JIRA is 8.4 years. That number does not reflect what anyone is actually working on — it reflects years of accumulated noise that makes the tracker harder to navigate for everyone.
I used an LLM to analyse all 4,093 currently open issues and put together a short report. It took about five minutes and surfaces some useful data. The full report is here:
https://claude.ai/public/artifacts/81fe75ce-e387-4b88-81fb-d4fc8b90a1a9
A few highlights from the data:
- 84% of open issues have not been touched in over 2 years
- 34% have zero comments — filed and never discussed
- 70% have no assignee
Select graphs are included below (if they don't make it through the list, see HTML link above)
The report suggests a three-tier approach:
* Tier 1 — Close now (~1,200 issues): Zero comments AND no update in 3+ years. Bulk-close with a label such as "housekeeping-2026" so nothing is permanently lost.
* Tier 2 — Triage with LLM assistance (~2,200 issues): No update in 2+ years, possibly some comments. Review in batches and close obvious candidates with the same label.
* Tier 3 — Keep and triage properly (~700 issues): Updated within the last 2 years, or has votes or active comments. These deserve real attention.
Does the community agree that something needs to be done? I am happy to help coordinate the effort if there is appetite for it.
Jan
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Eric Pugh <ep...@apache.org>.
I often go spelunking in JIRA and find old tickets that are hard to validate, or, if I ping the creator, they have long moved on and can't share any more details.
What do you think about using the same labels as in in our PRs? You could imagine that sixty days after a JIRA being opened we add "stale" and then 60 days after that "closed-stale". I would be fine with any activity counting as a reset.
For your Tier 1, you could do "housekeeping-2026" and "closed-stale".
If we committed to doing this, I would be happy to dig into the Tier 2 and Tier 3 lists.
Eric
On 2026/06/10 08:13:25 Jason Gerlowski 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 <ja...@cominvent.com> 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 <ge...@gmail.com>:
> > >
> > > 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: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Eric Pugh <ep...@apache.org>.
On 2026/10/26 04:24:56 Nick Boss wrote:
> 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 <ja...@apache.org> 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 <sa...@gmail.com>:
> > >
> > > 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 <ja...@apache.org> 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 <ds...@apache.org>:
> > >>>
> > >>> 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 <ab...@getopt.org>
> > 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 <ge...@gmail.com>
> > >> 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 <ja...@cominvent.com>
> > >>>> 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 <
> > gerlowskija@gmail.com
> > >>> :
> > >>>>>>>
> > >>>>>>> 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: dev-unsubscribe@solr.apache.org
> > >>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>>>>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >>>>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >>>> For additional commands, e-mail: dev-help@solr.apache.org
> > >>>>
> > >>>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > >> For additional commands, e-mail: dev-help@solr.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
I think you have done the first step, which is to look at them and inquire about them.
Then, in a few weeks, if no reply, and they are in the "we really aren't sure about this", then I think it's good to close those.
And if someone replies, well that then indicates we should pay more attention!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Nick Boss <ni...@gmail.com>.
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 <ja...@apache.org> 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 <sa...@gmail.com>:
> >
> > 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 <ja...@apache.org> 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 <ds...@apache.org>:
> >>>
> >>> 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 <ab...@getopt.org>
> 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 <ge...@gmail.com>
> >> 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 <ja...@cominvent.com>
> >>>> 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 <
> gerlowskija@gmail.com
> >>> :
> >>>>>>>
> >>>>>>> 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: dev-unsubscribe@solr.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Jan Høydahl <ja...@apache.org>.
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 <sa...@gmail.com>:
>
> 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 <ja...@apache.org> 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 <ds...@apache.org>:
>>>
>>> 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 <ab...@getopt.org> 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 <ge...@gmail.com>
>> 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 <ja...@cominvent.com>
>>>> 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 <gerlowskija@gmail.com
>>> :
>>>>>>>
>>>>>>> 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: dev-unsubscribe@solr.apache.org
>>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Amrit Sarkar <sa...@gmail.com>.
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 <ja...@apache.org> 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 <ds...@apache.org>:
> >
> > 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 <ab...@getopt.org> 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 <ge...@gmail.com>
> 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 <ja...@cominvent.com>
> >> 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 <gerlowskija@gmail.com
> >:
> >>>>>
> >>>>> 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: dev-unsubscribe@solr.apache.org
> >>>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Jan Høydahl <ja...@apache.org>.
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 <ds...@apache.org>:
>
> 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 <ab...@getopt.org> 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 <ge...@gmail.com> 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 <ja...@cominvent.com>
>> 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 <ge...@gmail.com>:
>>>>>
>>>>> 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: dev-unsubscribe@solr.apache.org
>>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by David Smiley <ds...@apache.org>.
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 <ab...@getopt.org> 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 <ge...@gmail.com> 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 <ja...@cominvent.com>
> 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 <ge...@gmail.com>:
> >>>
> >>> 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: dev-unsubscribe@solr.apache.org
> >>> For additional commands, e-mail: dev-help@solr.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> >> For additional commands, e-mail: dev-help@solr.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Andrzej Białecki <ab...@getopt.org>.
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 <ge...@gmail.com> 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 <ja...@cominvent.com> 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 <ge...@gmail.com>:
>>>
>>> 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: dev-unsubscribe@solr.apache.org
>>> For additional commands, e-mail: dev-help@solr.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
>> For additional commands, e-mail: dev-help@solr.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Jason Gerlowski <ge...@gmail.com>.
> 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 <ja...@cominvent.com> 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 <ge...@gmail.com>:
> >
> > 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: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <ge...@gmail.com>:
>
> 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: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by Jason Gerlowski <ge...@gmail.com>.
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: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: [DISCUSS] JIRA housekeeping — let's prune 3,000+ stale issues
Posted by David Smiley <ds...@apache.org>.
+0
If you auto-close an issue, choose an appropriate Resolution like
"Abandoned" so we don't confuse it with actual work being accomplished.
And any bulk changes should be done to explicitly opt-out of notifications.
I don't really understand how the statistics you speak of _matter_, or how
keeping an ancient JIRA issue open matters. But you don't have to convince
me either.
On Fri, May 29, 2026 at 9:57 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Hi all,
>
> This thread complements the ongoing discussion about migrating to GitHub
> Issues, but is worth pursuing regardless of how that ends.
>
> I have raised the idea of a major JIRA cleanup several times before. The
> usual pushback is that important work or still-reproducible bugs would be
> lost forever. I understand the concern, but I think the current situation
> has become untenable: the median age of an open JIRA is 8.4 years. That
> number does not reflect what anyone is actually working on — it reflects
> years of accumulated noise that makes the tracker harder to navigate for
> everyone.
>
> I used an LLM to analyse all 4,093 currently open issues and put together
> a short report. It took about five minutes and surfaces some useful data.
> The full report is here:
>
> https://claude.ai/public/artifacts/81fe75ce-e387-4b88-81fb-d4fc8b90a1a9
>
> A few highlights from the data:
> - 84% of open issues have not been touched in over 2 years
> - 34% have zero comments — filed and never discussed
> - 70% have no assignee
>
> Select graphs are included below (if they don't make it through the list,
> see HTML link above)
>
> The report suggests a three-tier approach:
>
> * Tier 1 — Close now (~1,200 issues): Zero comments AND no update in 3+
> years. Bulk-close with a label such as "housekeeping-2026" so nothing is
> permanently lost.
> * Tier 2 — Triage with LLM assistance (~2,200 issues): No update in 2+
> years, possibly some comments. Review in batches and close obvious
> candidates with the same label.
> * Tier 3 — Keep and triage properly (~700 issues): Updated within the last
> 2 years, or has votes or active comments. These deserve real attention.
>
> Does the community agree that something needs to be done? I am happy to
> help coordinate the effort if there is appetite for it.
>
> Jan
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org