[Policy, no patch] closing older issues

smustgrave → credited catch → .

smustgrave → credited larowlan → .

smustgrave → credited quietone → .

Just adding to the parent issue about 'issue management'

I think this could be healthy for the issue queue. It also will close a lot of the issues that were duplicates and fixed somewhere along the line.

Why 8 years though?

I honestly feel like the cutoff could be more like 2 years.

Also why 5 per day? Is that just a starting point so we don't spam hundreds a day being closed? I would think once the backlog of older issues are closed you would want the old issues to be closed at the same rate they accumulate and there is no need to limit to 5 per day.

@smustgrave, thanks for keeping this idea moving along.

My thoughts on #7
7.1 Drupal 8 was released in Nov 2015, just over 8 years ago. So, 8 years is a sensible place to start.
7.2 Do you mean if an issue is idle for 2 years? If so, there are valid Critical issues that would meet that criteria.
7.3 A limited number per day is for two reasons that I can think of. One is to not overwhelm any individual developer and to allow a small sample size for the initial trial.

I like to see a step in the process where a human verifies that an issue wasn't closed that should be open. Perhaps some percentage of what was closed, or ones with lots of comments, or from typically complicated subsystems?

I've added some thoughts to the templates for Task and Feature Request.

-1

Firstly, what is the aim here? Just to make the numbers go down? To me, the numbers indicate the sign of a healthy project. Are old issues really getting in the way? Personally I feel there is no problem that needs solving here.

Secondly, closing issues with a bot feels rude and impersonal. A bot cannot know whether an issue is genuinely outdated, a duplicate, or just a minor bug or cleanup task that is still valid. Some projects I use on GitHub have bots that auto close stale issues and it is so disheartening when you have put effort into an issue or comment for a machine to come along and tell you it was a waste of time. It deters me from contributing to those projects again, in a way that just leaving the issue open would not.

Quite often when I find something I need an issue for I will search for relevant keywords; sometimes I find something relevant and reuse it, sometimes I will find duplicates or related outdated issues and close them, and I think both of those things are OK. If this policy was in place and those old issues were already closed, I would probably be more likely to open a new one instead - but in some cases the old comments are still very valuable and so there is a risk this information would not get considered.

One thing I am OK with is bulk closing the 7.x issues once Drupal 7 is end of life. By now the two lines have diverged enough that if the same issue is required for modern Drupal it probably already exists. But I am strongly against closing any 11.x issues just because they haven't been commented on for any length of time.

This has previously been discussed on Hacker News where most commenters feel the same way I do.

Blog post and discussion:
https://blog.benwinding.com/github-stale-bots/
https://news.ycombinator.com/item?id=25821092

More discussion (original blog post is 404)
https://news.ycombinator.com/item?id=28998374

Prettier: https://news.ycombinator.com/item?id=39438501

Signal: https://news.ycombinator.com/item?id=30972745

@quietone That makes sense, I just wasn't sure where the time frames came from. 8 years still feels like a long time, but it can always be adjusted.

I think we would exclude critical issues from auto closing.

@longwave I also agree with your point. The first time an issue was auto closed on github it was disconcerting, however it just took a comment for me to retest and confirm it was still an issue. In another case it was a duplicate issue that had been fixed so it was correct to close.

I think that last point is one of the important things to consider, the more open issues, the harder it is to find existing issues and the more likely a duplicate will be created which duplicates effort. I know auto closing won't solve that issue, but it can help older issues get rechecked if they are going to be closed to confirm if they are still valid.

I mostly agree with #9 usually, but I think the constraints outlined in the issue summary might make this worth a try.

i.e. only tasks and feature requests, only minor and normal, only issues with no activity in 8 years, marking needs more info instead of closing.

(although I note while the issue summary says only tasks and feature requests, there's a template for bugs, maybe we can drop that?)

it can help older issues get rechecked if they are going to be closed to confirm if they are still valid.

Yes when @smustgrave pinged me about this and I was trying to work out a cut-off, I looked through some of the inactive issues I'd opened 8 years ago, and was able to quickly close several as outdated etc. The idea here is it would remind people when it gets to that threshold and they can check them.

I've been thinking about this a lot, and I think the issue is more about discoverability of similar issues.
I also think this situation would be different than the stale bots on other projects because many of those are bot more aggressive (every 30 days in the articles linked) and you can't reopen the issue once it's locked, but with Drupal you could. I think the root issue is solved a different way.

1. Make it easier to find the same issue / link similar issues.
2. Have greater incentive to have a group that periodically triages / reviews issues.
3. Have greater incentive to review, address and close support issues.

Automatically closing issues will make the queue artificially smaller, but does that mean that bugs are fixed faster or better?

There's been #1060798: Enable apachsolr 'related posts' block for issues (and forums?) → open for a very long time, but it's too late for that to get implemented on Drupal.org because were moving to gitlab, and I don't know if there's any similar functionality on gitlab available.

I can think of at least one case where I was following and occasionally contributing to two duplicate bug reports for years until one day I saw them at the same time and realised they were different issues and not the same one.

I saw some talk that gitlab uses elasticsearch for searching issues so that might help. But maybe there is an automated way to suggest duplicates for review in a queue at some point.

There was already a discussion about (automatically) closing some issues here: ✨ Close or set to "Stale" Issues that have not received an update in the previous 12 months Closed: won't fix

I still disagree with this (and agree with @longwave). For me autoclosing makes sense only for Support requests. Bugs/Tasks/Feature reuquest can be relevant event after years and will be lost between closed issue if closed (detault search is only for open issues).

There exists a GitLab Triage Bot so we would not have to author one.

I find giant backlogs psychologically paralyzing and that if a bug, task, or feature is important to a community people will continue interacting with it. GitLab, for example, allows voting up issues without needing to comment.

I constantly flip-flop/see-saw on this issue between wanting to clear out the old issues and worrying about closing some that are still worthwhile. The eight year cut-off and 3 month warning does make me worry less though, and looking at https://www.drupal.org/project/issues/search/drupal?text=&assigned=&subm... → I'm sure a lot of those issues are outdated and would not be missed.

As long as they are searchable and can be reopened I think closing is good as long as it's clear why it was closed. And there is a way to keep preformed long running issues open.

One thing to think about is new people opening issues and seeing 21k issues is intimidating too.

And I can’t figure out why but even with modules being removed and the review queue initiative the overall open issues goes up 100+ each month

Here's some possible draft text for a canned issue updated:

This issue hasn't been updated for more than eight years, we should confirm whether it is still relevant, and whether there is a more active issue addressing the same thing.

I am marking this 'Postponed (maintainer needs more info)' to begin with.

If you know that the issue is relevant, please move it back to active or needs work, and update the issue summary.

If there is a more recent issue, please close it as duplicate, linking the more active issue.

If there are no responses at all after three months, we will close this issue as 'outdated', however it will still be possible to re-open the issue after that time if it is re-discovered and found to be relevant.

Per slack I'm willing to volunteer to manually run a trial run of this. 10 issues a day. Any objection to me starting it tomorrow 01/15/2025?

Also I'm fine with the wording.

Should we also tag issues? Maybe 'drupal-stale-issue'

Also I’d like to do this trial run for least a month. After we can see

1. How many get re-opened
2. Anyone find the spike in emails annoying (maybe consider upping to 15 a day)
3. Any other info to help tailor this.

Before agreeing, let's clarify the trial. The proposal is #22 is do 10 a day and in the proposed resolution it is 5.

What category of issues? The proposed resolution is task/feature but there are comment templates for others categories. Also, Catch has suggested text that is different than what is the in proposed resolution.

What are we agreeing to?

--
Like others here I have gone back and forth on this. Personally, I agree with @cilefen that the giant backlogs is "psychologically paralyzing". But this isn't about me. The backlog causes real extra work for many of us and possibly makes it harder for a new contributor to get started. And we can avoid that extra work by implementing some regular 'spring cleaning'. I have closed lots of older issues and a small percentage do get re-opened, so that is encouraging that valid issue won't get missed.

Oh I didn't reread the issue summary after coming back here from slack. Let's use the text in the issue summary except something brought up in slack was thay n years y months will be extra work especially for a person, so we could replace that with 'several years'.

We should add a tag - best way to track re-opened issues.

I think with a bot we should rate limit it to 5/day to start with, but ramp it up to 10/day if it's going well. The main reason to rate limit was not to overwhelm people's issue trackers with bumped issues but that's less of a problem if a person is doing it.

For a manual trial by @smustgrave 10/day seems fine - any of us could triage an issue at any time.

On issue type.

I think it could be worth doing something like this:

Active tasks
Active features
Needs work tasks
Needs work features
Active bugs
Needs work bugs

This is on the basis that over the years we have definitely opened thousands of minor tasks to clean things up which then got forgotten about, but we're then fixed or made redundant by other issues in the meantime. It may be less true for features/ bugs so doing those in subsequent passes lets us iron out issues before we get to them.

So we are in agreement to try a trial run?

I’ll do 10 a day
Oldest issues sorting by update date.
And I’ll use the phrase in the summary
And tag “stale-issue-cleanup””

That tag I just made up

Yeah that sounds good to me.

Plus one to #27 from me

Thanks for the extra clarification, it really helps. I agree with the trial as stated in the last comments. Although how about instead of 'several years' we could say 'for more that 11 years' or whatever the number is for a group of issues. Yes, I like detail but it also shows that we are specifically picking very old issues.

The other thing is that the new tag, “stale-issue-cleanup”, should be added to the list of special tags.

Updated phrase to be 8 years since that's what I believe we have agreed upon.

I will start tomorrow!

Excited to see how this goes.

Adding #30 to the remaining taks. Something a site admin can do I presume.

Just did the first 10!

https://www.drupal.org/project/issues/search?issue_tags=stale-issue-cleanup →

Added "stale-issue-cleanup" to the list of special tags with this description,

To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues 🌱 [Policy, no patch] closing older issues Active