Stale bot closes issues due to inactivity eventhough they are still relevant

[Syphdias]

• [x] I have searched open and closed issues for duplicates
• [x] I am submitting a bug report for existing functionality that does not work as intended
• [x] This isn't a feature request or a discussion topic

---

Bug description

This is a bug of this Github repository not of the Signal App.

In the search of a missing feature (this one but not that relevant) the forum linked to a closed issues and a closed PR in the repo. Both are closed while not getting attention.

In https://github.com/signalapp/Signal-iOS/issues/5030 the author checked for a fix for multiple versions and commented on the issue that version x still did not fix it. After a while he stopped. Apparently this is what this repository expects to regularly say "still an issue" because after stopping, stale bot commented with "Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs." and marked it as wontfix. Only one other person commented as well and it was not someone from the project. The author commented with "still relevant" on this kind of comment multiple times (as did other people). But in the end, after one more "Is this still relevant?" message a week went by with no one reacting and the issue was permanently closed.

This super toxic to anyone taking the time to interact with your project. If you don't care about issues, fine, do not allow people to open issues. Using stale bot to close support requests or bugs where there is more information needed but the author has gone missing, also fine. But please don't insult people's time by just letting a bot close a ticket a human has never even layed eyes on.

Steps to reproduce

• Report an issue
• Get no response and the issue persists
• -> Stale bot comments on the issue that it will close it and marks it as wontfix
• Not reacting to it for one week (this is the span of a holiday, a hospital visit, or just life happening)
• -> Stale bot closes issue

Actual result: Issue gets closed with no way to reopen it

Expected result: Do not run stale bot on issues that are not marked in a certain way that warrants closing

Screenshots

Device info

Not relevant

Link to debug log

Not relevant

[ExtRIELICi]

I hate this stale bot so damn much

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ExtRIELICi]

Not stale

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ExtRIELICi]

Not stale

[sashaweiss-signal]

Hi, thanks for the comments. We do have a mechanism to prevent StaleBot from closing issues, namely one of us marks an issue as "Acknowledged". It's something we are trying to do more reliably, particularly for issues we're tracking internally. Apologies for any frustration, either with the bot or about open issues.

Since we do have a mechanism for this, I'm going to close this issue. Thanks as always for being Signal users, and for helping us keep track of issues.

[Syphdias]

I disagree that issues have a need to be acknowledged to be valid. This is the wrong way around. You can dispute an issue, if it is unclear, not reproducible, or not an issue at all (e.g. support request). But ignoring or missing an issue does not make it go away.

This issue alone is a good example that for this. Stale bot tried to close it twice before you could acknowledge it or dismissed this as an issue. It does not matter if this is a people or a processes issue. It has to stay open until can take a look and triage it.

BTW: No matter how you, dear reader, feel about this particular issue: If you like using Signal and want it to thrive, please consider donating — recurringly, preferably.