techhub.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
A hub primarily for passionate technologists, but everyone is welcome

Administered by:

Server stats:

5.4K
active users

Dis

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

I'm looking at you, , 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 requests, not 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 bazel has recently started doing this and it’s maddening

@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: github.com/OpenRefine/OpenRefi

GitHubLong running processes should serialize intermediate results · Issue #87 · OpenRefine/OpenRefineBy tfmorris

@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 accessory app. Who still uses ?? 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.)

@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 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@techhub.social 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