This action closes issues where a maintainer or contributor has not responded or otherwise acted upon the issue.

[StingyJack]

Repro steps:
I open an issue in a repo where I am not a contributor or maintainer, because I need help or have a question about something. This action is enabled in the repo using the defaults. None of the listed maintainers or contributors comments on the issue for 60 days.

Expected behavior:
If it was answered in the meantime I would update and close the issue but that has not happened in this case. I still need help or have a question, its not likely a great priority or emergency for me after this much time, but still I expect nothing to happen to the issue and for it to remain open until someone from the repo can respond.

Actual behavior:
This action rather rudely informs me the issue will be closed in 7 days.

I get that there are cases where reporters abandon issues, and am totally OK with that - I think 2 weeks is a generous amount of time before declaring reporter abandonment. But it only counts as reporter abandonment when someone other than the reporter has given some kind of response. That is not happening here, and it was the same thing with the stalebot,

[marko-zivic-93]

Hello @StingyJack
Thank you for creating this issue. We will investigate and come back to you as soon as we have some feedback for you.

[SvenStaehs]

Hy @StingyJack, Just my two cents as a fellow user: I think this is expected and desired behavior.

One use-case of this action is to close issues that have resolved themselves before the maintainers got a chance to look at it, so they don't waste time investigating and asking for clarification. On the other hand, if it is still an issue they immediately see that this is the case.
Maybe the user found a workaround or just understood the usage incorrectly. Or a recent update has fixed the issue inadvertently. Maybe the user has simply moved on and isn't using the product anymore because nobody answered their request within a reasonable time, so they won't respond to requests for clarification or verifying fixes.
And after this long of a time and probably multiple new releases, the first and possibly only thing a maintainer who reads this issue will ask is: "Does this still apply? Do I even need to bother investigating this?", when it's much better that they see that Op gave an update just a couple days prior to confirm it's still happening with latest version, so they can investigate with confidence.

In your specific case: Did you consider commenting on the issue after it was marked stale to assert that "Yes, I am still waiting for a response, the issue has not resolved itself and is still bothering me"? That should have reset the staleness. You can also still re-open the issue after it's been closed, or are you lacking permissions to modify issues in this repository?

[calumapplepie]

Hy @StingyJack, Just my two cents as a fellow user: I think this is expected and desired behavior.

No, it isn't. Perhaps it will make you, as a maintianer, think you have less work to do. But old bug reports usually aren't magically fixed, and not all issues are bug reports. Feature requests shouldn't be closed until the feature is done or it is decided that the feature will not be done; both of those require mainteiner intervention. Well-documented reports can be reproduced even without the user, and if you have the time to reproduce them later to verify that the bug was actually fixed, then you should do so. With a stale bot auto-closing issues, uncommon bugs will continue to exist forever.

If the user found a workaround, they'd probably have updated the issue with it. If you then close that issue, it will not show up in github search results; so the next person to encounter it will report a new bug, and have to find the workaround themselves, or just give up.

And as for frustration, well; nothing makes me stop using and contributing to a project faster than seeing the issue I encounter being reported several times, and then closed as "stale".

You can also still re-open the issue after it's been closed, or are you lacking permissions to modify issues in this repository?

Only maintainers can reopen issues. If maintainers have to manually undo the work of an automated time-saver, something is broken.

See https://fvsch.com/stale-bots

[rcomer]

I'm on a project that is using the action to gradually sift through a large backlog of issues and resurface them a few at a time so decisions can be made. As such, we would want the issues to be treated the same regardless of whether we previously got around to responding.

[StingyJack]

One use-case of this action is to close issues that have resolved themselves before the maintainers got a chance to look at it, so they don't waste time investigating and asking for clarification. On the other hand, if it is still an issue they immediately see that this is the case.

@SvenStaehs - I think you mean "Totally ignoring someone who has asked you for help, or that has spent some of their valuable time to make you aware of a problem with something you made." If you were at a party and having a good conversation with a few people you hadn't met before, and one of the group would hold up a hand between you and they whenever you spoke, and would otherwise act like you weren't there, while everyone else was engaged in the conversation with you, what would you think of that one person? #RudeAF

Maybe the user found a workaround or just understood the usage incorrectly. Or a recent update has fixed the issue inadvertently. Maybe the user has simply moved on and isn't using the product anymore because nobody answered their request within a reasonable time, so they won't respond to requests for clarification or verifying fixes.

There are lots of "maybe" scenarios. Why not just ask "Are you still experiencing this problem?" If at that point the asker does not respond in a timely fashion, close it for abandonment. The bot is not asking that question. It should not ask it either because it is not capable of understanding the issue described, or any response given to it, and is not doing anything beneficial like aggregation of issues for the benefit of the maintainer. If the maintainers intention is to shuck off a bunch of issues they dont have time for, they should just say that. Being honest may get them the help they need.

In your specific case: Did you consider commenting on the issue after it was marked stale to assert that "Yes, I am still waiting for a response, the issue has not resolved itself and is still bothering me"? That should have reset the staleness. You can also still re-open the issue after it's been closed, or are you lacking permissions to modify issues in this repository?

So many times, and not just here at GitHub. It is community destructive and promotes bad behaviors. Its not the first of its ilk either. The "Stalebot" was around before it, with the "docker desktop robot" being the first instance I had encountered a few years ago. .

@calumapplepie - I was able to fork a copy of this before the original author withdrew it. Its not as detailed as the link you shared, but for me it captures the feeling spot on.

[VincentLanglet]

Hy @StingyJack, Just my two cents as a fellow user: I think this is expected and desired behavior.

No, it isn't.

Yes it is. This is not because you don't like this behavior that this is not the behavior of this stale bot.

If the user found a workaround, they'd probably have updated the issue with it. If you then close that issue, it will not show up in github search results;

Not true, it will show in the closed issue. This is exactly the place you look for resolution and workaround.

And as for frustration

Do you maintain big public repositories with lot of PRs and issues ?
Did you encounter the frustration that a maintainer could encounter with all the stale issues he have to maintain ?
Do you sponsor the maintainer of the library you use ?

If not, who are you to tell how a maintainer should maintain his repository ? It's every body choice.

This action rather rudely informs me the issue will be closed in 7 days.

The rudely part depends on the way the message is written. It just a matter of fact:
Nothing happen on this issue, maybe it could be closed. If not, you just have to post any new message to keep the issue open and prove that

1. The issue is still here with the new versions (there is tons of issues solved with recent versions which are not closed because the opener don't care since it's fixed).
2. People are still looking for a fix (maintainer has always things to do, let's prioritize what's really needed).

It's also useful for feature-request. If nobody post on the feature-request, started to work on it ; maybe the feature is not that useful.

See fvsch.com/stale-bots

You're just proving the point.
If you don't like this lib, don't use it. Some people like it and use it, it's their choice.
If you don't like maintainer which are using stale bots, you're not force to use their lib.

[StingyJack]

As a maintainer, telling someone who is asking you for help that the their request is stale and closing it when you havent bothered to triage it is just a needlessly rude thing to do. Its also a waste of human time and computing power. Simply ignoring an issue requires no human effort to setup an action and deal with the complaints of its behavior, requires no human effort to constantly bump issues to keep them fresh, and doesnt require electricity and compute to run the bot or to run a "fresh bot" that auto bumps issues declared as stale by this action or its ilk.

This is a github action, as such it should be totally within github's ability to add a check for any contributor or maintainer comments and not mark those as stale. Give a configuration option to skip the maintainer/contributor check so that it can behave like it currently does, but that should not be the default. Those who want to engage in rude or community negative behavior and mark things stale that they havent bothered to look at can still enable the behavior, but they wont be able to hide behind the action's behavior.

Github should not be making software that requires community members to be rude or behave in a negative manner to each other.

[rcomer]

I do not think that the proposed change would improve reporter experience in all cases.

With the current behaviour, the worst case scenario is the reporter ends up in an endless loop commenting to remove the stale label. I agree that's pretty bad. However, the best case scenario is the maintainer sees the notification generated by the action's comment (or at least the one generated by the reporter saying "I still care about this") and is prompted to actually handle the issue.

With the proposed change, the action will only ever remind maintainers about the issues they already commented on. The ones they didn't get around to doing anything about continue to slide down the issue tracker and continue to be forgotten.

[VincentLanglet]

I do not think that the proposed change would improve reporter experience in all cases.

Still it's understandable people want a different behavior, but then it should be an opt-in and this issue should labeled as "Feature request" rather than "Bug".

With the current behaviour, the worst case scenario is the reporter ends up in an endless loop commenting to remove the stale label. I agree that's pretty bad. However, the best case scenario is the maintainer sees the notification generated by the action's comment (or at least the one generated by the reporter saying "I still care about this") and is prompted to actually handle the issue.

Which is the purpose of this action.
Helping maintainer working on issue people still care about.

[rcomer]

The problem with viewing this as an opt-in feature request is that the request is not coming from a user of the action. So the action's contributors will have no evidence the option would be used if they put time into implementing it.