If your #github project uses #stalebot you are being actively hostile to your community and should stop it.

I'm looking at you, #esphome, and the 4 (at least!) identical bugs indicating problems with esp_touch that were all closed by stalebot. Some of them were reproduced and started discussion and debugging before being closed.

Auto-closing is for #support requests, not #bug reports. Bugs don't magically disappear just because you ignore them.

@dis kinda wish y'all cared this much about my actual esp_touch issue ๐Ÿคฃ
@dis I hate the autoclose so much. Like, what the hell. Why would you make it likely that maintainers miss feedback, at all???
@dis agreed. Argo CD issue and PR count keeps going up, and I continue to resist adding a stale bot. "Number going up" is not a good reason to have a bot close people's requests.
@dis I have much better advice: If you are using #github this is hostile to your community and you should consider to change forge: sfconservancy.org/GiveUpGitHub
#GiveUpGitHub
Give Up GitHub - Software Freedom Conservancy

The Software Freedom Conservancy provides a non-profit home and services to Free, Libre and Open Source Software (FLOSS) projects.

@dis when you look at Issues as a list of known bugs in a project, then you are right. But if you would see it as a queue of issues to be fixed then having it open for 2+ years is a false hope to a community that the issue gets fixed. Nope. It rarely happens for old issues. I agree that the default value for daysUntilStale is too low. But 365+ days is OK for me.
@mirek @dis in #OpenRefine, I am working on issues that are 10+ years old. I am glad they have not been closed automatically because they are about (I think) great improvements that are still totally relevant today. Example: https://github.com/OpenRefine/OpenRefine/issues/87
Long running processes should serialize intermediate results ยท Issue #87 ยท OpenRefine/OpenRefine

Original author: iainsproat (June 23, 2010 15:58:35) For a long running process in mid-calculation, long running processes should serialize their intermediate results. Later recovery could be suppo...

GitHub
@mirek @dis I don't think anyone is getting false hopes by looking at a 10 year old issue. They are capable of inferring that it is unlikely to get fixed soon. I don't get how it can feel satisfying to keep the issues list "clean" by sweeping those under the rug instead.

@pintoch @mirek 10 years is a while. Recently I snickered when an old project I contributed to finally got around to triaging a breaking bug I reported in 2011.

Like, I love the dedication but this is a #puppet accessory app. Who still uses #puppet?? Its been a full dot-com bubble since then! (And no, I am not going to reproduce that RHEL4 bug for you here in 2023. My career is intentionally at a point where I never have to reproduce anything in RHEL ever again.)

@dis @mirek but in big projects that's really not that uncommon! For instance this issue about handling of non-breaking spaces in #Firefox. Opened 17 years ago, closed 10 months ago by @pmorinerie. It's worth it! https://bugzilla.mozilla.org/show_bug.cgi?id=359303
359303 - Non-breaking spaces (nbsp) not copied as such

RESOLVED (kemenaran) in Core - DOM: Serializers. Last updated 2022-07-22.

@mirek You don't get hope from a 10 year old ticket. You get continuity, debugging, more information and validation. You may even get a fix.

I'm not going to contribute time (or code, or docs, or debugging effort) when the gatekeepers use #stalebot as a recording to say "We're sorry, all representatives are busy with contributors that aren't you. Please go away.<click>"

@dis I always find it so disrespectful of the people who take the time to write up issues. The latent assumption seems to be that if it does not get worked on, it's not that important. But I don't know any FOSS project where it's a reasonable assumption to make.
@dis The next time a bug report of mine will be auto-closed by a stale bot, I _will_ set out and create an anti-stale-bot bot...
At some point enough is enough.

@dis

Sometimes, an endless stream of issues becomes a nightmare for maintainers... When you're addressing issues slower than they're created (for whatever reason), there is a temptation for a more tough and less polite policy.

I more than agree that auto-closing is the worst solution. But I also see why developers are doing that.

@dis

I think the key point is that the lack of new comments has nothing to do with meaningful close reasons.

Such reasons could include "too complicated", "very rare case", "no human resources", but definitely not "you don't comment often enough". ๐Ÿคจ

@dis if you wait long enough, they disappear together with the project.

@dis I would much rather have my bug stay open for years. That gives others validation that the problem has been seen before. It may not be a priority for the maintainers, but itโ€™s still useful information.

If I go to the effort of filing a bug (a good one with logs, how to repro, etc) and a bot auto closes it, all I see is โ€œwe donโ€™t care about your problem and go fuck yourself for even asking us to fix itโ€

Theyโ€™ll never get a second bugrep, thatโ€™s for sure.

@dis
Stalebot usage should be automatically added to CONTRIBUTING.md or the issue template so I can just go fuck myself right away instead of waiting 2 weeks to be told by a robot
@dis Don't forget fejta-bot...