-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: Remove stale bot #11836
chore: Remove stale bot #11836
Conversation
Signed-off-by: Yuan (Terry) Tang <terrytangyuan@gmail.com>
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. |
There are currently only 48 open PRs, so I think that's a manageable size. |
@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. I also don't think stalebot itself has a way to configure PRs vs. issues. stalebot is also deprecated and the |
@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. |
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) |
@agilgur5 that blog post has holes IMO. I have personal opinions that counter that post in multiple ways.
At least the author is honest about their bias against GitHub. |
@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? |
👍 for removing stalebot on issues |
WDYT? @sarabala1979 @juliev0 |
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.
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.
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 agree with Anton's recommendations here. |
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. |
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 |
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 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 |
Added Stale Action as described above in #12488 |
Stale bot has been noisy and unfriendly. See discussions at #11802. Open to feedback and suggestions.