CPython has 7,154 open issues — can we organize a cleanup effort?
I’ve been looking at the CPython issue tracker and noticed the number of open issues has grown quite large. I ran some numbers to get a clearer picture, and I’d like to share what I found and start a discussion about whether a coordinated cleanup effort would be worthwhile.
The numbers
As of February 2026, CPython has 7,154 open issues (excluding PRs). Here’s how they break down:
2,237 issues (~31%) haven’t been touched since the 2022 migration from bugs.python.org. These were imported and nobody has looked at them since. Many may no longer be relevant.
~1,100 issues are over 10 years old. The code they reference has likely changed significantly.
~2,500 open feature requests. Some of these may be ideas that never gained traction and could be closed.
~1,100 docs issues. These tend to be more approachable and could be resolved or closed relatively quickly.
What I’d like to discuss
Has there been previous discussion about organizing an issue triage or cleanup effort?
Would a focused sprint on the ~2,200 untouched-since-migration issues be welcome?
What criteria should be used for closing stale issues? (e.g., no activity in N years, references EOL Python versions, etc.)
Is there interest from core devs and triagers in coordinating something like this?
I’m happy to contribute time to this effort. I think a cleaner issue tracker would benefit everyone — contributors looking for things to work on, triagers trying to prioritize, and core devs managing the project.
It has certainly come up repeatedly over the years in the past. At summits, at sprints, and in the mailing list and now discuss threads.
I will note that old issues are valuable and we do routinely tackle some of them. Closing something just because of its age or last comment date, especially on volunteer based open source projects also doesn’t give a good feeling. Time alone does not generalize to mapping to relevant or presence. If we ever decide to close based on age of last genuine activity (not the current fake gh account comment bot-spam) I suggest we apply a special label when doing so to make them easier to find on their own vs other closed ones.
This is often the opposite of how triage can work in a workplace where resources are known and bug bankruptcies are declared to acknowledge the old and lowest priority things are never going to be gotten to so why not close as “not planned" to keep them from showing up as being of active interest.
Issues is a very vague term. What any given one can represent can vary from very micro-targeted clear cut things, to broader things that’d need wide discussion and agreement on the direction of to proceed with. Even those bearing our ‘easy’ tag can ironically fall into the latter category because someone maybe recognized that the change itself should be good for a new contributor to create. But a change being clear how to make does not mean it should be made or that we shouldn’t do something else instead. That triage determination is often not really stated on an issue… Did the right people see it and prioritize making time to participate?
Potential more realistic labels that the core team and triagers could assign might be: needs-discussion, needs-core-team-decision, needs-a-decider or needs-DRI aka “directly responsible individual / driver”)
But merely creating labels by itself is not much of an improvement by itself, maybe more chair shuffling. Proactive triage management time, recognizing that even expecting the right volunteer experts to spend their interrupt time if asked to weigh in on something for technical decisions is “the” hard part in OSS.
Maybe that’s really just me saying “I love that you want to volunteer for this” combined with “I have no idea how it’ll go, it is likely more of a people and community themed problem”.
Aside from the current state of things, it may be interesting to look at historical issue filing dates vs close dates over time in the past. I sort of intuitively expect the shape of any issue tracker on a long running active popular project to be similar to the chart above. recent issues are filed related to current work in progress or recent changes and more often closed. Things that linger might have more maintenance complexity or lack someone who can spend time driving them to resolution?
Mass-closing or marking as stale to me doesn’t work well; it fixes the measure of “Number of open issues” but doesn’t actually resolve the underlying issues or why they were are still open. There’s a lot of interesting, hard to resolve edge cases that come up with the scale and longevity of CPython. Seconding @gpshead old / known outstanding issues are valuable.
I’d also note it’s important not to make more work by triaging. In particular, I like Raymond Hettinger’s “Be a good neighbor” points (https://youtu.be/voXVTjwnn-U?si=Wsvfub0Yu-vG33YR&t=1861). There is a lot that has been debated, discussed, and worked on by many people in Python and there’s often a reason why things are the way they are even if it doesn’t match expectations. There’s a lot of things people have learned building and evolving the Python ecosystem over time.
Two ways I’ve found work well to find issues which I can help with:
Look at issues in the “middle” of the bug tracker. The ones on the very first pages and last pages have had a of lot of eyes look at them and tend to be in states that are hard to resolve. Random pages in the middle in the bug tracker I have found have more straightforward to resolve cases. I’ll go to a random middle page and then spend a bit of time per issue to see if there’s anything useful I can do to move the issue. Note that closing issues should generally be done only by a core developer and their time, which is largely volunteered, is limited. Building relationships and trust matters.
Come to core team sprints at conferences! Working in-person can save a lot of round-trip time and get things to resolution. Not every meetup or conference has active core developers who are looking to help mentor newer contributors but are a lot that do. I did core sprints at PyConUS last year and really enjoyed helping people work on CPython bugs.
Very valuable effort, and also agree with not auto-closing stuff. That said, I think it’s ~impossible for this to be driven by one person, or even as a one-time push across several people. I base this observation on similardiscussions in LLVM, where a lot of effort was made to stay under 20k issues. 2.5 years later, the tracker stands at 28k issues.
This is not to discourage work on this – far from it! But to avoid burning people out who try to stem the tide here, I think it’d need something of a culture change that reviewing open issues is just as necessary as reviewing open PRs, for example. That’s a hard sell though, because closing issues is both less tangible and less prestigious than merging PRs, and obviously reviewer capacity is already one of the rarest resources anyway.
One thing that I could imagine working somewhat, is to try to encourage outside contributions on this, e.g. by having a page that extensively documents good practices for investigating an old issue (does it still apply, has it been solved, if so when, have all aspects been completed, etc.[1]), and then providing a randomized link an open one[2] to go try it. Obviously, low-quality comments will not be very helpful, so that doc page could also provide a template for a checklist to work through and put in the comment, so that it’d be clear immediately whether a contributor tried to follow this (rather than just asking “any updates on this?”, for example).
could also explain how to handle various scenarios, e.g. issues coming from BPO, or crashes, or how to forego the analysis if it’s a doc issue and just raise a PR, and so on ↩︎
say, older than at least one month or maybe year ↩︎
As a reference point: last year I skimmed through all the open issues labelled as bugs, looking in more detail at a smaller subset in areas of interest. I estimate I probably read the full descriptions of 10-15% or so of those ~3k bugs. There were a few that were obviously invalid or had already been fixed that I recommended be closed, and I think most of them have been. I have notes on ~100 or so others that I am pretty sure should be closed, but it wasn’t quite so clear cut.
If there was appetite for this sort of clean-up I’d love to work with others if there was core dev and/or triager support in getting them closed, but even so it would only be a small fraction of those open.
Yeah, the only cleanup I’d want to see is either closing ones that are redundant (either already fixed, the code has changed drastically, or the relevant versions are EOL), and definitely nothing based on “nobody has commented”.
It would also be good to make sure that area tags are accurate, and maybe look at some groupings/dashboards/projects based on areas. For someone trying to find something to work on, it’s likely that they’ll have a module they’re already familiar with, and so being able to easily browse issues related to that module is a great starting point.
