Stale bot for Nix just closed a bunch of stuff

Stale bot for Nix just closed a bunch of stuff. In Nixpkgs we agreed it is was OK to mark as stale, closing should always be done by humans.

I assume this was just a misconfiguration, but either way, I this should fixed and reverted.

Nix itself is a case of needing more delegation so it’s possible to get through the backlog, and so auto-closing items is worse than crude in masking that problem and sweeping it under the rug.

1 Like

A little oblique, but I think we’re drawing closer to the point where we could implement a much better triage view/queue on top of the new (beta) github issues. The main point would be building an intentional triage view, removing issues that are pending feedback from it, and either returning them when they get feedback or closing them if they don’t (within a reasonable time frame). This would make the stale bot moot, while also not requiring humans to keep up with whether issues have gotten the feedback they need to be actionable.

Two previous posts with more context:

Since I last commented on this, they’ve added options for bulk- and auto-adding issues (see The new GitHub Issues - April 7th update | GitHub Changelog).

You can keep an eye on issues Archives | The GitHub Blog for their updates.


I have opened an RFC for this at [RFC 0124] Do not auto-close stale Nix issues and PRs, matching Nixpkgs's policy by Ericson2314 · Pull Request #124 · NixOS/rfcs · GitHub


By the reactions in various places, this seems broadly popular. In that case, please volunteer to shepherd the RFC! The sooner we can get through the RFC process, the less stalebot-closed items will need to be dredged back open afterwords.

1 Like