Perhaps we just need a better understanding of when to reopen issues to resolve
this thread.
It is well possible that an old feature requests gets a bump in priority again
after a few years (see e.g. the desire to have an os.chdir() context manager).
If we can agree on making it easy to reopen issues, we’d not lose older context.
This would also mean that older rejections should deserve reevaluations after a
while.
With such an understanding, the action of closing an issue would not have the
perceived final pronouncement character and instead get a more project
management oriented meaning: we’re putting this issue into the backlog for
someone else to potentially pick up in the future.
You don’t even need to reopen old issues. You can just as easily say “open a new issue (and link to the old one) if you want to re-propose a feature request”. Then triagers can evaluate that new issue based on current standards and its own merits, rather than trying to evaluate possible decades of discussion.
This doesn’t solve the problem of finding the old closed issues in the first place: if the it’s not found, then all the context, discussions, linked PRs/patches, showstoppers and issues are lost and the effort will have to be duplicated.
On bpo we even switched the default search from “open issues” to “all issues” because people often created duplicated issues that were already fixed/rejected. The GitHub search also defaults to open issues/PRs, so assuming people search before posting, they might end up missing the previous issue.
I agree. Note that in my original post I mentioned exceptions to closing, one of them being that the issue contains discussions or analysis that we don’t want to lose. This is the rare rather than the typical case.
The old issue, if found, is more likely to be used as a reason to quickly close the new one (whether the old issue is open or closed). This usually happens because someone remembers that the idea had already been proposed.
It’s not a major loss if we sometimes have to reconsider the same idea again from scratch, a decade later. Especially if we make it less of a big deal to close it again.
To repeat - if someone spent a significant amount of time investigating the suggestion, or attached a non-trivial patch, then we should think harder about whether there is something there which is worth keeping.
To me, this is backwards: An assigned committer should encourage PRs because it should indicate that PRs will be reviewed and possibly merged. Also, an issue with an assignee should not be closed without asking.
… and if there’s a risk of the assignment being misinterpreted as “I’m working on a PR, so don’t bother”, then presumably it’s easy enough to add a small comment when assigning the issue to yourself - “I’m not working on a PR myself, but I would be happy to help someone who wants to contribute one”.
At least as someone mostly used to GitHub and its conventions (though some exposure to others, e.g. GitLab, Bitbucket, BPO, Trac, Jira, Bugzilla, Fedora, etc),the interpretation
would also be pretty counterintuitive to me, at least for issues (PRs are a different story).
Meaning of assignee: Over the last 10 years, I have been one of the more active coredevs on bpo, including merging patches, now PRs. On bpo, ‘assignee’ can be only one person who is a core dev. So it could not mean ‘person writing a patch’. For at least most of that 10 years, issues marked for IDLE as the only component were auto assigned to me. That meant that I ultimately decided the disposition of the issue and any patches. I know for sure that at least some other core devs meant the same thing when assigning an issue to themselves.
Assigning an issue to oneself should be understood to mean this. And hence, this should mean ‘do not close without consulting me’.
Over half the patches I merged were from 1 of over 10 other contributors. I don’t remember any duplications. If anyone did not contribute a patch because I was ‘assigned’, I do not know about it. But since I have not yet reviewed all the patches submitted, I don’t care. More important to me is reducing the inconveniences and time waste involved in reviewing and merging.
Github apparently allows any 10 people to be assigned to an issue. So I can understand that people not experienced with bpo would have a different understanding than I and some others have had.
Over the past year, Irit asked me about closing several issues, some IDLE, some others. I believe I closed all but about 2 (sometimes with an additional message), and probably added something to those left open. In the past 2 weeks, Erland has asked by about 6 issues or so. Again, move closed. Two should be either replaced or substantially revised. For me, intelligent query has worked quite well.
About 10 years ago, an over-zealous triager with less discrimination annoyed people until removed as triager. A stupider robot would be even more annoying.
Just a clarification—GitHub allows any org member to be assigned to an issue (or PR), as well as anyone who has commented on it (including the author). So not much of a restriction in practice, but not quite just anyone. Also, the assigner has to be an org member with triager permissions or above (or a repo Collaborator, which I don’t believe cpython has any of), whereas IIRC on BPO, couldn’t the assigner be any BPO user? Maybe I’m misremembering on that latter point, but if so that’s somewhat of a reversal between BPO and GitHub, in terms of who can be an assigner vs. assignee.
For me, if there is not activity on an issue for 5 years (or longer) and the issue is 10 years old (or older), it’s unlikely that it will be solved soon, and likely that it will never be solved just because they are more cool feature requests in the queue.
Honestly, I’m fine with that. I prefer closing such issues since it’s a maintenance burden for triaggers, but it’s also a signal that, nope, we are not going to implement this super cool idea (unless someone steps in and actually does the work). It’s very cheap to propose ideas, but an infinite list of cool ideas or “I really need this thing for my important project” issues is not helpful.
For issues active in less than 5 years, someone should read latest comments to see if an action can be done to move on. Usually, there is only a vague idea, nobody proposed a concrete implementation so far, and there is a disagreement on the API or how it should behave. If you want to close such issues, I suggest writing a short summary (rephrase the feature request, explain what should be done and why it wasn’t implemented), and then close it.
When an issue is 10 years old (or older), it’s likely that the Python ecosystem evolved, Python evolved, and the use case evolved, in the meanwhile. Closing the issue is a deliberate action to request the issue creator to describe an updated version of the feature request in its updated ecosystem.
