Triage stale issues and PRs automatically?

Development
1

Hey,

Currently nixpkgs has thousands of stale issues and PRs. I was wondering if it would
be any help to automatically close stale ones? Kubernetes and other large projects
take this approach as well and seem pretty pleased with it. If an issue or PR doesnt have any progress in 6 months, we simply close it. The author can then re-open it by pinging the bot. GitHub - probot/stale: A GitHub App built with Probot that closes abandoned Issues and Pull Requests after a period of inactivity. is a bot that implements this. I think it would be useful to get back some oversight in the jungle of issues and PRs that we currently have.

If more people are interested, we could perhaps draft up an RFC and get this bot enabled. What do you think?

2 Likes
2

I feel that closing the issue should be reserved for actually resolved bugs or issues that have a definitive resolution like a wontfix/wontimplement decision. I’ve personally hit many bugs in other projects that were closed by a bot and never solved.
On the other side I agree with you that stale issues obfuscate what’s really recent or currently discussed.
We can use the docker approach as a middle ground and use a bot to put a “stale” label on issues that haven’t been worked on in a while like this one

Pro: no need for an administrator to reopen the issue, silent users that are watching issues can reopen them if they still feel that a solution is needed
Con: it’s not really closed so you always need to add a -label:stale when searching for issues

EDIT: I’m fine if we close stale issues, too, I’d rather prefer it to not be that automatic

2 Likes
3

GitHub normally sorts recently changed issues first. If you arrive on an issue, you can easily see the stamp of the last reaction.

4

Idea to close staled PRs and issues isn’t that bad as I thought first. I’d like to object only one thing from stale bot README:

In an ideal world with infinite resources, there would be no need for this app.

But in any successful software project, there’s always more work to do than people to do it […]. Just making decisions about what work should and shouldn’t get done can exhaust all available resources.

Is it true, that if making a decision over staled PR is hard, then we should close it? (I assume that easy-to-decide issues don’t burn out maintainers)

For example, nginx: Check syntax also at nix evaluation time · Issue #35395 · NixOS/nixpkgs · GitHub . The decision is clearly “yes we want this”, the status is “mmm, maybe someone wants to volunteer his time for this?”. Especially, given it has pitfalls.

Stale bot will close it. Is bot correct here? I think, it is correct, BUT, it should have a message:

So, you stranger came up here with exact same question or exact same problem and wonder why is it closed. You see, maintainers haven’t found TIME to solve this issue. Yep, it happens. We like the idea in general, so if you’d really like to add some priority, open new issue with new details. But, ideally, open a new PR with following issues resolved:

  1. issue1
  2. issue2.
  3. issueN.

Open issues and PRs are prioritized over closed ones.

Sure, bot can’t list real “issues” of an issue or PR. So someone from steering committee or it’s extension should make this. And add a label volunteer-wanted

In the end, open issues and PRs will form a highest-priority (actual) queue, closed issues and PRs with tag volunteer-wanted will form a second-priority queue (technical debt), and issues without this tag would be things maintainers no longer care. TODO: should the label assignment be revisited periodically?

Until maintainers are paid for fixing things, this would be fine. (btw, by maintainers I assume top contributors, but maybe it should be defined more precisely?)

1 Like
5

Yes! That’s my exact concern over automatic closing over improvements.
If the bot could allow unprivileged users to reopen bugs that would be optimal in case there is a long-standing bug but automatic close happen (and the user is still alive to report it).

1 Like
6

No, not reopen. Simply because of GitHub. If you reopen an issue, you’ll notify only previous commenters, but if you open a new issue, you reach a greater audience. And for nixpkgs, that audience changes each year. You will notify previous commenters by mentioning that old issue in a new one.

Also, you can’t reopen PRs.

One more argument for closing staled issues. PR Improvements for declarative nixos containers by chrisfarms · Pull Request #3021 · NixOS/nixpkgs · GitHub. It should have been marked “stale” (or “volunteer-wanted”) and closed in 2015-2016. Other PRs reimplemented it’s parts (in some cases, new authors didn’t know about this PR existence!), so it was of little use to keep it open.

And also, I’ve started a list of nixpkgs issues and PRs, which are quite interesting, but decision is hard to impossible to do: User:Danbst/Ideas in Limbo - NixOS Wiki . Feel free to extend this list!

3 Likes