Stale-bot closing issues which should remain open

[NiklasBr]

Can I prevent this somehow?

Just because the repository maintainer has not answered does not make the issue stale.

The effect is that issue openers have to spam the repo just to keep their issues open. This cannot be the intended behaviour, right? Because that feel like bad for the community, but at a behavioural level and makes searching for existing issues harder due to duplicates.

[GJKrupa]

Agreed. See, for example, goharbor/harbor#14274. The GitHub actions equivlant (https://github.com/actions/stale) also does this.

GitHub

GitHub - actions/stale: Marks issues and pull requests that have not had recent interaction

Marks issues and pull requests that have not had recent interaction - GitHub - actions/stale: Marks issues and pull requests that have not had recent interaction

[xmo-odoo]

This cannot be the intended behaviour, right?

In theory the bot can be configured to not touch e.g. triaged issues (with specific labels). However in practice I'd say it's the intended behaviour, it's "closure laundering" when the maintainers don't really want to close issues themselves, so they delegate the destruction to the bot and the original reporter, up to you to either keep spamming the issue so it remains open (which doesn't mean the maintainer will ever care) or give up, either way the emotional burden is on you. Have fun.

I'm surprised there is no unstale bot yet, to counter-spam these issues.

[NiklasBr]

Yeah, from my point of view as a contributor, stale-bot has multiple negative effects:

• other contributors will have to remain spamming as we mentioned
• the repository will be cluttered by non-solved closed issues
• issues with a solution will be less prominent because duplicates will make them harder to find

Maybe a feature where I as a contributor can prevent stale-bot from interacting with my threads would be nice?

[ulidtko]

What are you talking about? This bot blatantly violates Asimov's second law of robotics!

It plainly ignores "commands" (really, comment activity) and closes issues anyways. I've seen that time and time again, in multiple repos all over GitHub. See #312 open-rpc/playground#543 middleman/middleman#2302 Jguer/yay#1125, many more are easy to find.

The bot should be killed immediately. Unconfigure it ASAP!

There're better (I mean: actually working) replacements.

[madbrain76]

My point of view as a bug reporter is that issues should never be closed, except by a human. Marking issues as stale seems appropriate. Proper bug reporting tools like bugzilla have ways to query issues on a variety of fields, to sort through inactive issues. Github seems to lack this. Auto-closing bots are not an adequate substitute.

[ulidtko]

@madbrain76 right — however some maintainers will disagree. There's this use-case for such bots in high-traffic repos, where people post issues daily, but not to report bugs; simply asking questions (sometimes, from avoiding to read documentation) and eating away maintainer's attention. It's not rare that people never return to the issue again after posting it, even after maintainer response. In such cases, it can be beneficial to automatically close "stale" discussions on timeout with the help of a bot.

But, real bug reports shouldn't be treated like this. Worse: the bot should not ignore further comment activity, devolving into issue killing timer. 👈 This is the core issue. The issue is that the bot misbehaves — not that it exists.

[madbrain76]

I agree with you that discussions and bug reports should be treated differently.

Perhaps the problem here stems from the fact that "Issues" Github mixes all of these things.

The core problem is that github doesn't have a well defined mechanism for reporting and searching bug reports, like bugzilla on mozilla.org does, for example, or every software company I have ever worked at since the mid-1990s. The "issues" page certainly is not a proper substitute.

I'm not saying bots shouldn't exist, just that they should never auto-close bug reports. A human ultimately needs to decide if the bug report is not reproducible, working as designed, duplicate, more more information is needed, whether the maintainer doesn't want to fix it, etc. There are perfectly valid reasons for both bug reporter and maintainers not to respond. Both bug reporters and maintainers take vacations, lack time, abandon projects, die, etc. Inactivity alone doesn't make a bug report invalid. I have a few hundred bugs on mozilla.org, many of which I opened decades ago, that are still in the open state and not resolved yet.

I can see that bots have a role in high traffic projects sorting through a large number of reports. Perhaps machine learning can help figure out duplicate bug reports, for example, and insert comments to that affect pointing to the suspected dupes, so that either the bug reporter or maintainer can then close them. In other words, set meta data in the bug report, but not outright close them. Maybe there is already a bot that does this. But the bot in question here is "stale-bot", and it seems to focus chiefly on inactivity, and closing issues based on that, and this is why I'm commenting here.

[ulidtko]

I'm not disagreeing. Just want to focus on somewhat more specific matter of this issue: @stale-bot **closes issues which have activity**. I.e. does not work as advertised. It'd be "fine" if it closed really stale issues only -- but that's not the case. Even *not inactive* issues get closed. That's the problem.

[ulidtko]

9 more instances of the issue: #370