At the language summit session on the issue and PR backlog, we briefly discussed the problem of feature requests that remain open for a very long time because they are reasonable but nobody cares enough about them to implement them.
Recall that our premise was that a noisy issue tracker is harmful to the project, so it is desirable to close issues that will not be implemented. It seems unlikely that anyone will implement a feature (and a core dev will merge it) just because of a 10-15-20 year old open issue. If the feature will be implemented, it will be because someone will rediscover the need for it.
Should we, as a general rule (there are always exceptions*), close feature requests after, say, 10 or 15 years?
(*) Some exceptions would be:
the issue is a borderline bug report (sometimes fixing a minor bug breaks backwards compatibility and we call it a feature request).
the original issue and/or the discussion reflect a significant research effort or expertise
the issue has a patch implementing the suggested feature
in such cases, we should look deeper before closing it.
Currently there are 60 feature requests older than 10 years with 3 or less comments. It’s probably worth going through them and see if some can be closed, especially if the proposed feature is not well thought out or if there was some initial pushback.
As you mentioned, if there is some discussion and/or patches, it might be better to leave it open.
That’s tricky to define though. The first issue of that list is Support display of both __cause__ and __context__ · Issue #59010 · python/cpython · GitHub. The feature request seems reasonable and I would consider this a valid issue (unless the handling of the traceback changed in the meanwhile making the issue obsolete/invalid). It only has two other comments, that point out other two modules that should be updated too.
If the issue is left open it will be easier to find it, increasing the chances that someone will notice it and move it forward. In addition, all the three messages contain useful information, even though I’m not sure it can be considered “significant research or expertise”. If it’s closed there will be one less issue, and if someone proposes this again, they might not be aware that the other modules need to be updated too and might introduce inconsistencies that will take more time to notice and fix.
Closing an issue does not delete it, and search will still easily find it.
In the example you mention the problem is more that nobody had the courage to say “no, we should not do this” – which IMO is correct response: if we had wanted that we could have implemented it that way from the start.
I am not at all worried that if we closed this and someone implemented it independently and we approved of doing so, we would collectively forget that there were other modules that would need to be updated.
I don’t see a downside to closing that issue, and I see two upsides: one less open issue in the tracker, and nobody has to make an explicit negative decision – we can just let the lack of interest imply that the status quo is fine.
Old issues with low activity does not add anything to noise.
Closing 60 or 120 old issues will not reduce the number of open issue too much.
Many of these proposals look reasonable and are interesting to me. They just leaved my focus for a time. Many of them are simple enough, and just need somebody to make a PR.
I usually ignore closed issues when search on GitHub, unless I search for some specific closed issue. The number of closed issues is larger than the number of open issues, and most of them are not relevant anymore. It is impossible to distinguish solved issues from rejected for reason from closed by the lack of interest at that moment.
They don’t add to the noise if you don’t look at them. They do add to the noise if you are looking in the issue tracker for things you can improve.
If you don’t look at them because there are so many of them, and it’s too hard to scroll through the ones that will never happen to find something you can do, then the ones that will never happen are preventing people from resolving issues.
If we keep the tracker tidy by removing the issues that will never happen, we increase the chance that useful issues will be noticed and resolved.
This was the premise of the language summit discussion.
These 60 old, dormant feature request only make up a very small percentage of the open issues. Closing these will not drastically reduce noise; it will hardly be noticeable. If we want to reduce noise, perhaps we should focus on the other 99%?
I’m aligned with Ezio and Serhiy’s observations and opinions here.
But I am looking at them. One of issues in your decimation list (about grapheme clusters) is in my list. I was going to implement it in 3.11, but did not have time, so it now waits for 3.12. Another issue may be related to my large deferred work for rewriting tkinter dialogs. There are other interesting issues why I may take and finish in next weekends. If you close them they will be considered as resolved, and either disappear completely from my field of view, or possible interesting information which they contain may be completely lost.
In the past I often used a search for the oldest issues with few comments. They could already be resolved in other issues, or be low hanging fruits just waiting for a patch or a review. Don’t take this restroom away from me.
That was Ezio’s list, not mine (I’m pointing this out because you quoted me and then discussed it). I don’t think number of comments tells us much in this case. There are plenty of issues with long discussions that will go nowhere.
In a case like this, it would be good if you indicate on the issue that you intend to work on it. This would make it one of the exceptions for closing (that is - it would be clear that there is interest in the issue, and who it is that it interested in it). At the very least you could subscribe to issues you are interested in so that you get a heads up and can respond when someone decides it will never happen.
If you don’t agree that a large pile of low value issues is a problem, then we are unlikely to come to an agreement here. If there is no cost to leaving issues open, then of course we should leave them open on the off-chance that someone will do something with them. But I don’t believe it is true that there is no cost, so I think we need some kind of balance.
You can assign issues to developers, so why not simply say: Unassigned old feature request issues can be closed, assigned ones are left open ?
In my experience it often happens that a feature request has to sit and
wait for the right time to get implemented, so it’s not uncommon for
such requests to stay open for a longer while.
Other project management techniques we could implement to improve
ticket resolution:
start using milestones and assign tickets to milestones, e.g.
for alpha, beta, RC and final releases
group tickets in projects (which can span milestones) for longer
running tasks, e.g. deprecations, evolving the C API, speeding
up CPython, etc.
start using priority labels to differentiate between more
important tickets and less important ones
Github has support for all of these. They would help with adding
more structure of intent to the CPython project and make the various
areas of activity more easily discoverable by new volunteers.
When I began inheriting the Flask project and other related projects, the six repositories had well over a thousand open issues and PRs between them. It was paralyzing. It was hard to find duplicate discussions, or to know if closing one issue could close others. It was hard to know if I could merge a PR, because there were years of other PRs that might have conflicts in their implementation or purpose. It was hard to have a sense of what I should close, because why should I close this issue when all these remained open.
At my first PyCon, I ran a sprint, and I struggled to find things I was confident in having people work on. It was just as likely they would work on something only to find that it didn’t make sense, had already been done, or was no longer valid.
I’ve worked for six years to cut down that backlog. There are now between 60-100 open issues across six repositories. It has been the greatest thing I’ve ever done to help myself as a maintainer. I’m confident that what is open are things I really want for the projects. I’m confident in assigning tasks to new contributors at sprints. I’m confident at coming up with new tasks and knowing where I can take the projects next, since there’s not 10 years of history piled up to think about first.
Yeah, it’s going to take a long time, and anyone starting now will take a long time to see a visible dent when there’s 7.1k open issues. But if you don’t work at it, it won’t change. If you do start, you’ll see a change eventually, and things will progressively become easier to track. As a maintainer, I highly recommend closing your backlog one way or another.
Personally I prefer to keep old valid issues or requests open, regardless of activity, simply because of having the “bucket” of things to look through to do.
I have found it also helps avoid duplicates, as many reporters do search open issues before posting a new one (despite the fact that some post without searching - nothing we can do about them).
However, in this case, I believe GitHub Issues is woefully under-featured for this many issues, and we should close as many as possible. A decent issue tracker lets you manage more issues than can fit in your head, but GitHub is not (currently) one of them. So as David says, closing as many as we can in order to get it down to the ~100 issues that GitHub can reasonably represent is the best way forward (okay, we’re a big project, we’ll probably only get to ~500 )
We can argue about the best way to do it (personally I think getting every issue under a given category with an assigned expert who can make the call is the best way), but let’s at least agree that it’s not going to work to have a bottomless list in our current tool.
)