Install tooling to close stale issues and PR's?

[lassepe]

Julia has a lot of open issues and pull requests. While this is valuable as a collection of ideas and todos, it is often hard to determine which issues and PRs are active and actionable.

In particular pull-request become stale very quickly and there may not be a large value in keeping them open for too long. Even if they are closed, the code still exists, they can still be found using the search bar, and it is not hard to re-open them should they become relevant/actionable again. Therefore, as previously discussed in #33239, it may be good to have some tooling to address this issue.

The github stale action would be a good option which is fairly simple to set up. This action can automatically add a "stale" label to issues/pr's after a pre-configured time of inactivity and will add a comment to notify participants that this will be closed soon unless there is any further activity.

The reason why this is an issue and not a pull-request are the following points which may need some discussion:

1. Do we want to automate this at all? Do we need a stale bot in the first place?

2. If we want this: How aggressively should the tool close issues and PR's?

---

In my opinion, such a bot would add value to the Julia repository if it was configured in a "non-aggressive" manner. That is, it should only step into action after long period of inactivity (maybe 90 days?) and perhaps should not affect issues at all (?). On pull-requests it could be a little more aggressive since they may be almost un-mergable after a long period of time.

The stale action also allows to exempt issues/PR's with certain labels (e.g. "bug") . This way we can configure the action to ignore "WIP" PR's and/or add a label "never-stale" or "pinned" to tag issues/PRs that should not be closed automatically.

[vtjnash]

From my experience trying to deal with that stale bot on libuv (a nodejs child project), that configuration of it causes a large waste of additional effort and increased friction between users and among developers (For context, see the longer version of this discussion and my thoughts at libuv/libuv#2498 (comment)). Thus, it'd more beneficial to have a hackathon (or just a motivated person) actually walk through and triage them.

I think we could make effective use it to bump them after ~2 weeks of inactivity (but never close them), but the length of that timing is so PR-dependent, I fear it may begin to actively discourage people from making difficult PRs that requires more than a week of discussion. While a longer time interval starts to limit the effectiveness of the bot.

[KristofferC]

As someone who dedicates a few days per year going through old issues checking if they are still valid / adding tests if a bug has been fixed etc, I would argue that only using time as an input to automatically close an issue isn't really useful. Sure, some old issues are completely stale and useless (usually one-off bug reports on some strange system, or problems building Julia) but many of them still need some action before they should be closed:

• Bugs that have been fixed should get a corresponding test before closing.
• Performance issues are sometimes valid for years and shouldn't be closed based on time.
• Many other issues need some kind of manual consideration before knowing if it is closable.

Automatically closing old issues would decrease the number of open issues (duh!) but other than that I don't see anything useful from it. A stale PR doesn't really make any noise but if a bot goes and close it, then it will notify a lot of people and it might need to be reopened if the bot was wrong.

[StefanKarpinski]

I'm also against any kind of stalebot. I really hate it when other projects use it. Using it on Julia would just make more work for me since I would have to reopen things that shouldn't be closed and I really don't need more GitHub busy work. Autoclose also destroys useful information: we already know if a PR is stale based on if it's conflicted; if it's open, we know that it wasn't actively closed, which means we may want to dust it off and merge it at some point. Autoclose would make it easier to permanently forget such PRs. The same with issues: I can often remember that there's some open issue about something and searching open issues makes it much easier to find; there are a lot more closed issues than open ones, so autoclosing makes the search much harder.

In my opinion, such a bot would add value to the Julia repository if it was configured in a "non-aggressive" manner.

One thing that's implicit here which is worth discussing is: add value for who? I suspect that you're talking about adding value for people who come to the project and aren't active contributors / core devs. Indeed, fewer open PRs and issues would make the repo a lot less confusing for newcomers to navigate. While that would be nice, I'm much more concerned with making GitHub as useful as possible for the people who "live here". When it comes to software we ship, we consider the bulk of users first and convenience for developers is a much lower priority. When it comes to GitHub, on the other hand, utility and convenience for the developers is the top priority.

[lassepe]

Convinced :)