chore: Remove stale bot

[terrytangyuan]

Stale bot has been noisy and unfriendly. See discussions at #11802. Open to feedback and suggestions.

[jmeridth]

I'd prefer keeping stalebot on for pull requests. This lets contributors know whether a pull request is still active or not. When it gets flagged and closed, this lets contributors know they can attempt the fix.

update: automating this frees up maintainer time. instead of maintainers having to comment on the PR checking status.

[terrytangyuan]

There are currently only 48 open PRs, so I think that's a manageable size.

[agilgur5]

@jmeridth that scenario is 3.ii. in #11802 (comment). It is one of two valid scenarios, but those two are in the tiny minority of usage of stalebot.
As I mentioned there, old stale PRs can be manually marked as stale and closed, or they can be left open until there is a superseding PR (the closes #xxx syntax also allows you close a PR from another PR in GitHub).

I also don't think stalebot itself has a way to configure PRs vs. issues. stalebot is also deprecated and the stale action is now recommended (which is a good bit more configurable as well).

[jmeridth]

@agilgur5 🤦 (at myself for missing that) I'm a stale action user. Not stalebot.

I still believe marking PRs stale and closing is better than maintainers "waiting" manually and then allowing others to supersede PRs.

[agilgur5]

I don't think the stale action has a way to configure for lack of response from maintainers (certain users). There are a good number of PRs that get marked as stale in this repo but never really got an adequate response from approvers 😕

(which is one of the harmful, counter-productive usages of it)

[jmeridth]

@agilgur5 that blog post has holes IMO.

I have personal opinions that counter that post in multiple ways.

• If an issue is important enough to work on, a PR will get created.
• If a PR is worth finishing, it will get finished.
• old, open issues do not show popularity. It shows inactivity and lack of care by maintainers IMO.

At least the author is honest about their bias against GitHub.

[jmeridth]

@agilgur5 that being said I'm a fan of replacing stalebot with stale GitHub action. And keep on for PRs. Willing to get outvoted. What do you think?

[caelan-io]

👍 for removing stalebot on issues

[terrytangyuan]

WDYT? @sarabala1979 @juliev0

[agilgur5]

• If an issue is important enough to work on, a PR will get created.
• If a PR is worth finishing, it will get finished.

It only requires one counter-example to disprove these, and I can point to many in this repo and many others, including several I am or was a maintainer of. I think those opinions rely on idealistic assumptions that don't hold up in my experience.

Also, as is often in OSS, the number of active contributors are several orders of magnitude smaller than the number of users, so I think these scenarios will happen almost by definition. Not to mention that contributors are often spread thin across several repos as well.

• old, open issues do not show popularity. It shows inactivity and lack of care by maintainers IMO.

I would say both are true. Old open issues tend to have many upvotes (conversely, popular issues closed as stale tend to have more duplicates). And they tend to be complex in some way that maintainers have been unable to get to it.
The reason for that is irrelevant though, it does happen and has happened in this repo many times. That it happens is all that matters. I actually think this argument is more of a con of stalebot.

Willing to get outvoted. What do you think?

But that's just one blog post, and it's not even one I found myself. Someone else had linked it in Argo and it was an instant bookmark for me. @isubasinghe and I also left comments about it and we're just two contributors.
I am fairly positive most users do not like stalebot either (if not hate it passionately). The amount of passion against stalebot is substantial, and I've never seen anything even remotely close to that in support of stalebot.

[juliev0]

I agree with Anton's recommendations here.

[jmeridth]

@agilgur5

I think those opinions rely on idealistic assumptions that don't hold up in my experience.

That's fair. I've had the opposite experience but the repos I've maintained haven't dealt with the scale of this repo. 😄

Thank you for the discussion.

[agilgur5]

Throwing a recent example here: I just got linked to #8224 via Slack from a user. It's a very popular bug that got closed as stale without being resolved (and the stale closure comment also has 6 downvotes). It also could potentially be the root cause of some other templating bugs too.

So this is a very concrete example of where stalebot had ended up obscuring bug reports as well.

EDIT: There's more examples of bugs being closed as stale without resolution: #5173, #1932, #7615

[agilgur5]

@jmeridth that scenario is 3.ii. in #11802 (comment). It is one of two valid scenarios, but those two are in the tiny minority of usage of stalebot.

For these two use-cases where stalebot can actually be useful, we may want to add the newer Stale Action in a very limited capacity: if an issue or PR is labeled with more information needed, then it can be marked as stale and closed out if no response. If there is a response, probably both the more information needed and stale tags should be removed, and it would be up to a contributor to mark it with more information needed again if the response does not suffice.

That process is still pretty manual (and requires that all contributors understand it when doing triage), so I don't think it's much of a productivity increase based on the current issue load, but Stale Action in that very limited capacity I do think can be useful. I might implement that myself if that situation happens often enough (not many things are labeled more information needed right now).

[agilgur5]

Added Stale Action as described above in #12488