Full agree: Stalebots are horrible, and nobody is helped by getting spammed with notiications that time has passed (I don’t need an email for that, and would get tens of such emails per day if nixpkgs did that, as I’m subscribed to hundres of issues).
A value of keeping unfinished PRs open is that it makes them easy to discover: When something isn’t working, the first thing I do is check if there are open issues or PRs. I wouldn’t be searching in closed PRs for pre-exisitng unfinished work.
I do think it’s good to manually close old PRs that receive no updates and have no chance of being merged as they are, e.g. because the package / code was removed, or the issue was fixed a different way by another PR.
I also think it’s fine to manually ask “is that still relevant” if there’s any indication that something may have changed since the issues/PR were filed.
When it’s my PR, I do actually find “hey we’re waiting on you to do something” reminders useful, because there’s a good chance I have completely forgotten about the PR. Which does not mean I have lost interest; it means I have a zillion other things on my plate at all times and if I am not in a position to fix a mechanical issue like a merge conflict immediately upon being notified about it the first time, there’s a good chance I won’t remember to do it later. Actual review feedback is easier for me to remember to get back to but it does still often fall off the bottom of my inbox.
However, I am very firmly with @TLATER and @nh2 regarding automatic closure of PRs or bug reports: Never. Ever. Do. This. Not even if it seems like the original author has lost interest. Not even after multiple years of inactivity. (I personally have had bug reports open on upstream Firefox and GCC for decades now that are still every bit as much of a bug today as they were the day they were filed.)
Especially, I don’t understand why people are advocating for closure of PRs where the only review blocker is a merge conflict. That’s, like, the easiest possible thing for people other than the PR author to fix. A bot we should have is a bot that tries to do a mechanical rebase on each PR with a merge conflict.
And even when there’s more work to be done than just a merge conflict, and the original author appears to have lost interest, I fully endorse this bit:
I do agree that a PR that has been fully superseded by changes since it was filed – the package was removed, the problem was fixed a different way – should be closed, but only ever manually, with an explanation of why it has become moot.
Side note:
IMO, while this is fine, for issues the person doing it should always at least attempt to reproduce the problem themselves before asking. “Hey are you still having this problem”, especially when it is the only activity that a bug report has received in years (or, in the worst case, ever) comes off as dismissive, whereas “I tried to reproduce this problem with the current dev tree and couldn’t, are you still affected if you update” does not.
It only takes 9 months to have a baby. If a PR is untouched for more than the time it takes to make a new human, it’s probably okay to kill it.
One of the big open-source antipatterns is having long unaddressed and stale PR and issues collections–it signals to newcomers that the project is overwhelmed, that it can’t prioritize, and that any work they do is likely to languish and fall through the cracks.
I suggest aggressively closing PRs older than 9 months without interaction–each one that is open is a burden.
It actually takes about 20 minutes - if that. The rest is just waiting for the build to finish. You’ll have a much harder job convincing folks to close PRs after 20 mins.
I think it should be pretty obvious that similes to biological processes have no bearing on the merits of nixpkgs’ dev processes, and at best serve as grandstanding in a debate.
On the contrary, I believe anyone who has worked in the field in any capacity knows that software projects naturally have a long tail of difficult work that stays half-done or experimental pretty much indefinitely.
Going by a “how many open PRs/issues are there” metric would only influence a complete novice, or a project manager trying to invent KPIs to sell to investors.
It’s no more useful than lines of code, trying to use this as a quality metric leads to perverse incentives (and is probably indeed where stale bots come from).
Again, whom do open PRs burden how? Nobody’s work is actively impacted by their mere existence. Unlike pregnancy, an open PR is not a debilitating physical condition.