The Conversion Gap: Why 9-Year-Old Issues Never Die in Open Source

If you filter the Kubernetes issue tracker today for open issues still carrying the needs-triage label, you will find a backlog of over 650 results. If you filter for those older than five years, you will find 34.
One of them, Issue #50375, has been open for nine years. It is not abandoned noise or a low-quality bug report. It contains sustained, genuine community demand that was ultimately locked without ever reaching a resolution path.
We often assume that as open-source projects grow, issue trackers inevitably rot. We blame maintainer burnout, bot-generated noise, and the sheer volume of incoming reports. But the data tells a different story. Projects like pytest manage their issue states exceptionally well, proving that triage labels can function exactly as intended, as temporary holding states that resolve cleanly. The breakdown isn't an inevitable open-source law, it is a specific failure of hyper-scale governance.
While contributing to Selenium, I observed this firsthand: genuine accessibility issues were reported multiple times by different users, yet sat in duplicate silos, never connected by the triage process. When I examined Kubernetes specifically, the same failure appeared at a scale that made it impossible to ignore,34 open issues older than five years, still carrying a label that was meant to be temporary. The core problem isn't that maintainers are lazy or that bots are maliciously burying contributors.
The problem is what I call the Conversion Gap.
In heavily automated, massive-scale projects, triage labels stop being a step in a workflow and devolve into a permanent archive. The project maintains the illusion of process, bots assign tags, move tickets, and ping users, but there is no actual mechanism to convert sustained community signal into a prioritized decision. The community keeps speaking, but the project has no structural way to decide.
In this talk, I will use verifiable repository data to examine this specific governance failure. We will contrast the healthy triage hygiene of smaller-scale projects against the multi-year backlogs of hyper-scale repositories, and explore how the reliance on automation has masked a critical breakdown in decision-making.
This is not a talk about adding more bots, configuring better templates, or buying new tools. It is a talk about how we manage human signals. Because when a label like needs-triage becomes a permanent tomb, we don't just lose track of bugs, we lose the trust of the contributors we rely on.

Understand how issue trackers gradually become harder to manage as duplicate reports, stale requests, and unresolved issues accumulate over time.

• The Myth of the Inevitable Backlog: Understand through comparative data (like pytest vs. Kubernetes) why triage decay is a solvable governance issue, not an unavoidable reality of open source.

• Deconstructing the Conversion Gap: Recognize the specific failure mode where sustained community demand is trapped in open issues indefinitely because a project lacks a mechanism to force a decision.

• The Duplicate Silo Effect: Learn how the absence of human synthesis creates fragmented reporting, illustrated through a pattern I observed directly while contributing to Selenium's issue tracker.

• The Danger of the "Permanent Archive": See how labels like needs-triage create a psychological placeholder that provides the illusion of process while actively alienating long-term contributors.

• Naming the Problem Correctly: Understand why misidentifying a conversion failure as a volume problem guarantees the wrong solutions — and why that distinction is the prerequisite for any governance fix.