I don’t think it necessarily has anything to do with being a “completionist”, just a different view of what the issue tracker is for. If you view the issue tracker as s thing to record what anyone thinks might be a problem, then you leave the issues open. But if you view the issue tracker more about what the maintainers think are actual issues, then you want to close issues where the OP has abandoned them. So I think if you view the issue tracker more for the users or the maintainers shapes your view on this topic (I’m a “for the maintainers” person).
3 Likes
Of course, if a maintainer thinks something is not a problem the issue should be closed. But there’s a gray area where either there is room for different opinions or an investigation is needed before a maintainer can form an opinion. In a busy project like CPython there are a lot of those, and that doesn’t bother me.
2 Likes
In my view, the tracker is for maintainers. But the original reason for adding ‘stale’ (see the first post) was contrary to that. It was to warn that an ‘inactive’ issue would be closed even if a core dev wanted it open – unless the core dev periodically jumped through the hoop of periodically posting something, to make it ‘active’. With autoclosing rejected, why were the labels and bot kept? I see no positive benefit to the label, and definite costs, and would like the ‘stale’ bot and labels removed.
2 Likes
Personally, I’ve not been that in favor of systems as you describe, at least for issues rather than PRs, on the repos I maintain. However in the case of a user not providing the actionable information needed such that a maintainer can reproduce the issue and thus act on it, which is what @hugovk and I brought up, in that case the closing is a prompt to the user that they should respond with the requested details, otherwise the issue will stay closed as there’s nothing immediate actionable others can do unless its responded to.
“Needs more from the user before we can proceed” is signalled by a triager applying pending. I have often applied this myself, or converted to closing. ‘Stale’ means nothing but ‘inactive’ for a arbitrary interval (not visible last I knew). Has nothing to do with the quality of issue or of responses or the needed next step.
2 Likes
These perfectly valid different views imho, are what actually lead me to persuing the ‘upvote’ approach, finding it very difficult to resolve the marking as ‘pending more info’ vs ‘stale’ vs hard closing (what might be) stale but valid issues. One major consideration though, spanning both maintainers and contributors, is the desire to avoid feeling ‘completely overwhelmed’ by an unordered, unprioritised backlog and/or lack of effective roadmap planning, even indicatively or emergently.
I haven’t yet got the PR for the ‘top issues dashboard’ merged, so the usefulness of the approach is still hypothetical at this point.
For JupyterHub and Binder repos, especially in the early days when it was just Min and me, I would use saved replies and leave a message that the issue/PR had been inactive for 3 months or more since the last message. If they didn’t take any action in 30 days we would close. We also gave them the option to close themselves. After the 60 days we would close with a message stating thar we would be happy to reopen when requested.
Fewer issues would reduce the cognitive load for Min and me. I did this every month manually and it helped us prioritize fixes and enhancements.
7 Likes
For pyca/cryptography, on issues that are not actionable without input from the reporter (e.g., because no one can reproduce, because they’re support requests, etc.) we will add a label indicating that the issue requires input from the reporter.
We have an action that, for issues with that label, will automatically leave a comment after 3 days reminding the reporter to reply and letting them know that if there’s no action, the issue will be closed in 5 days.
5 Likes
Issue that cannot be acted upon are quite different from issues that could be acted on but are not because of inadequate develpers resources. This issue is about the latter. The former, un-actionable issues, are often closed before they become stale.
4 Likes