I can only agree with that. I have had been involved in to many "stale" but neither fixed nor forgotten issues which would have become very cumbersome if a sta

I can only agree with that. I have had been involved in to many "stale" but neither fixed nor forgotten issues which would have become very cumbersome if a stale bot was involved. Common reasons for "staleness" include: - blocked on other issues - blocked on external dependencies - blocked because no one has currently time to fix the issue because there are many other high or very high priority issues. This doesn't mean it has low priority, just not high/very high priority. - feature requests which the author agreed to should be implemented, but neither the maintainer nor the issuer has currently time to work on. - feature requests which are braking changes and as such will only included if a new version is made - bugs with low priority if there are higher priority things Sure you can work around this by using many labels and making the stale bot label aware e.g.: - label contains "blocked" => do not stale close - label contains "bug" => do not stale close (and only assign bug if issuer provides the necessary information) - label contains "next-version" => do not stale - label contains "...." => do not stale But that seems somewhat pointless for the large majority of crates. Furthermore I believe stale bots come to some degree from the (IMHO) unrealistic idea that the amount of open issues, issue closing time and issues staleness indicate how health a project is. But the moment you have feature request issues or "will be fixed in next release as braking change" this metrics fall apart completely. Similar some software projects get a lot of spam issues (often an indication that a popular project probably needs some improvements of documentation or UX aspects). For this it can sometimes be reasonable to have stale bot if it doesn't act on certain labels IMHO.