What 9 Popular Open-Source Issue Trackers Reveal About Process Health

A TwinFlow data report — issues fetched 2026-06-12; scored 2026-07-03 on TwinFlow's current scorer.

Every team believes their process is unique. Then you put the event logs side by side and the same patterns show up everywhere — in a Fortune 500 ops queue and in the issue tracker of your favorite open-source project.

We pointed TwinFlow — our process-intelligence engine, normally used to scan Linear, Jira, GitHub, and Salesforce for SaaS ops teams — at the public GitHub issue trackers of nine of the most-loved open-source projects. Same pipeline our customers run: extract the raw event log, mine the real process map with process mining (PM4Py), measure cycle times, dormancy, rework, and bottlenecks, and compute a health score.

One thing before the numbers: this is not a ranking of maintainer quality. Every project below is a triumph of volunteer-driven engineering used by millions. A "low" process health score measures the shape of work moving through an issue tracker — and a massively popular project accumulating more issues than any volunteer team could ever close is a law of nature, not a failing. TwinFlow's score was calibrated for commercial ops teams with SLAs and dedicated staff, so a volunteer-run tracker is being held to a yardstick built for a different operating model. Under that yardstick none of the nine reaches the bands a staffed commercial team is designed to hit — which is exactly what you'd expect, and no knock on any of them. What's interesting is that the yardstick still separates: the one tracker a company staffs like a commercial operation pulls well clear of the rest of the field.

Bottom line: eight of the nine trackers cluster at 38–45; vercel/next.js — the one issue tracker staffed like a commercial operation — scores 53, eight points clear of the runner-up (grafana, 45). And in every tracker, the quiet states ("under review", "unplanned", WIP) are where work goes to wait. Full methodology below.

The data

Sorted by TwinFlow health score. "Issues sampled" = GitHub issues (not PRs) updated inside the scan window; the window varies per repo to respect API budgets — see Methodology.

* transformers also had a "WIP" label with a far longer wait (359 d avg) but only 8 affected issues — below the ≥10-issue threshold applied to every row, so the close step is the listed bottleneck.

Eight of the nine trackers land in a tight 38-45 band — three of them at the scorer's "Critical" line — well under the 60 "Fair" floor TwinFlow's bands set with staffed commercial teams in mind. The lone exception is the one tracker a company actually runs as a product: vercel/next.js scores 53 — eight points clear of the best volunteer-run tracker in the set. Under a scorer recalibrated this month to treat sub-90% SLA compliance the way a commercial ops team would (see Methodology), no volunteer tracker escapes the bottom bands — and next.js doesn't reach "Fair" either; a bar built for staffed teams with SLAs is simply a bar none of these nine was ever trying to clear. But the separation is untouched. Across wildly different domains, sizes, and communities, volunteer-run issue trackers converge on a narrow low band, while the single company-staffed tracker pulls cleanly away from the pack. Process shape tracks who runs the process, not what the project builds.

What the data actually shows

1. Every tracker runs at two speeds — and the average measures the museum, not the assembly line

In all nine scanned projects, issues that get closed move fast: the median wait into the close step is measured in hours to ~3 days (next.js 2.6 h, cpython 2.4 h, ansible ~15 min, duckdb 3.1 d, kubernetes 2.9 d). Meanwhile the average age of issues touched in the same window runs 39 to 432 days. Both numbers are true; they describe different populations. The fast lane is live triage. The slow number is backlog archaeology — old issues resurfacing (often via a stale-bot or a milestone sweep) and dragging years of accumulated age into the math. Any team that reports "average resolution time" as one number is blending these two populations — and the blend hides both stories.

2. next.js runs the most industrial tracker in the set — and the score agrees

vercel/next.js is the outlier on every flow metric: dormancy 17% (the next best is 33%), reopen rate 1.9%, average touched-issue age 39 days (3-11× lower than the rest), a median close wait of ~2.6 hours, and the highest SLA compliance in the set — 77% of completed issues closed inside 7 days, against 19-53% everywhere else. The event log shows why: a staffed, systematic triage operation — one Vercel triager alone accounts for 45 of the 67 assignment events in the 90-day sample — plus heavy automation. This is what an issue tracker looks like when a company runs it as a production process — and it is the one project here whose health score, 53, stands clear of the field (the next best is 45). The score isn't asserting that next.js is run like a business; the same event log that produces every metric above is what puts it there.

3. "Under review" is where issues go to wait

The single most striking bottleneck in the dataset: duckdb's "under review" label — 115 issues that, once labeled, waited an average of 254 days (median 253) for their next recorded event. fastapi shows the same shape at smaller scale ("reviewed" label: 16 issues, ~2.9 years average wait), as does transformers ("WIP": 8 issues, ~a year on average). A state named like active work behaving like a parking lot is a pattern process mining regularly surfaces in commercial ticket systems too — work that is "in review" is frequently work that nobody owns. Issue trackers don't have a "we looked at it once and moved on" label, so review-ish labels absorb that role.

4. Rework rates track automation aggressiveness, not fix quality

The reopen ("rework") spread is wide: ansible 12.7%, kubernetes 9.7%, neovim 7.2%, transformers 6.3% — versus duckdb 2.8% and next.js 1.9%. (Since the July re-scoring, the rework metric also counts backward loops in the process map, not just literal reopens — it nudges neovim, cpython, and kubernetes up by at most 0.7 points; see Methodology.) The high-reopen projects are exactly the ones running aggressive lifecycle automation (ansible's needs-info auto-closer, kubernetes' lifecycle/rotten bot). In a commercial process, rework usually means defective output; in these trackers it more often means a bot closed it and a human pushed back. Same metric, different root cause — which is precisely why a process map matters: the metric tells you where to look, the event log tells you what's actually happening.

5. Most "active" issues show no process movement at all

Between 8% (neovim) and 56% (grafana) of issues updated in the window had zero captured workflow events — no close, no assignment, no milestone, no workflow label. They were bumped by discussion alone. Comment activity is engagement, but it isn't state movement — an issue can be vigorously discussed for years while its process position never changes. (These no-movement issues enter the metrics as zero-length cases, flagged by the pipeline's imputation step; we compute the per-repo share directly from the stored event logs — an issue counts when its only captured event is its creation. Re-verified 2026-07-03.)

Methodology (read this before quoting any number)

What we scanned. For each repository we pulled GitHub issues (pull requests excluded) that were updated within the scan window shown in the table, via the public GitHub REST API, then ran them through TwinFlow's standard pipeline: connector → event-log extraction → PM4Py process discovery → health scoring. Windows vary per repo (30-365 days) because we capped each scan's API request budget; very active trackers get shorter windows. Rates are therefore samples of recent activity, not a census of each project's full history.

A tenth project, pytorch/pytorch, was attempted and excluded: its tracker is so active that even a 14-day window meant ~1,300 API requests, and the fetch exceeded our pipeline's scan timeout. Rather than publish a partial sample, we dropped it. (microsoft/vscode was ruled out at the planning stage for the same reason — ~2,300 requests for a single week.) That the two most active trackers we looked at couldn't fit the budget is itself a data point about their volume.

What an "event" is here. GitHub's issue-event timeline gives us: issue created, closed, reopened, assigned, milestoned, and a small set of workflow-style labels ("under review", "WIP"). It does not include comments, linked PRs, or commits — so the event log captures a project's triage process, not its full development process. Issue trackers are only one window into how an open-source project works.

Metric definitions.

• Cycle time — first to last captured event per issue. Because the window selects issues touched recently, an issue opened years ago and closed by a stale-bot last week enters with its full lifetime. That is why averages dwarf medians: the average measures the age of the backlog being touched, the median measures how fast a typical active issue moves.
• Stuck (dormancy) rate — share of sampled issues with any gap longer than 3 days between consecutive captured events. Three days is TwinFlow's default for staffed ops teams; for volunteer maintainers it is a harsh bar, and we report it as a dormancy measure, not a judgment.
• Rework rate — share of sampled issues that were closed and then reopened at least once, or whose trace moved backward to an earlier stage (structural loop detection, added to the miner in June 2026). One honest caveat: the structural detector does not yet exclude assignment changes, so an issue returning to a previous assignee can count as rework; on this dataset the effect is at most +0.7 percentage points (neovim, cpython, kubernetes — every other repo unchanged). Still genuinely comparable across projects.
• Completion — issues that reached a closed/done state inside the window, out of all sampled (the "Completed" column, e.g. 351/722). Open issues that never closed are not counted as completed.
• 7-day SLA compliance — of the issues that did complete, the share that closed within 7 days of their first captured event. It is measured over completed issues only, so a low completion count makes the SLA figure thinner, not lower.
• Health score (0-100) — TwinFlow's composite (cycle time vs a 5-day target: 30%, dormancy: 25%, rework: 20%, SLA: 15%, handoffs: 10%). All five components are measured on this dataset; the scorer renormalizes only when a component is genuinely unmeasurable, which is no longer the case here (see the connector note below). Scores in this report were computed 2026-07-03 on TwinFlow's current scorer. The SLA component was recalibrated on 2026-07-02 — a compliance knee at 90% replacing a straight linear credit — because the linear curve under-penalized missed SLAs relative to the ~90% bar staffed ops teams actually hold themselves to. That recalibration lowered every score in this report by 3-9 points versus our June draft; the underlying SLA rates are unchanged. Calibrated for commercial ops processes; treat OSS scores as relative, not absolute.

On completion and SLA. These two metrics are measured here on the same connector code TwinFlow ships today. They were blank in our first pass on 2026-06-12: the connector then only recognized a closure when an issue's final activity was a bare terminal word like "Closed," and GitHub records closure as a transition ("Open → Closed"), so nothing matched and SLA came out empty. We fixed that — the connector now reads the transition target — and re-mined all nine scans from their stored event logs on 2026-06-13 (no re-fetch, identical underlying data), so the figures above include completion and SLA throughout. The scores were then re-computed once more on 2026-07-03, when we recalibrated the scorer's SLA component (see the Health score definition above) — again from the same stored event logs, with no re-fetch at any point. So the dates split cleanly: issues fetched 2026-06-12; metrics mined from those logs; scores as printed here computed 2026-07-03. Neither re-scoring touched the underlying rates; only the scores moved (and the rework rate, slightly — see its definition).

Known limitations. (1) The GitHub event model is thin — ~1.3-3 events per issue — and TwinFlow's own data-quality scorer flagged every scan "Fair" or "Poor" for exactly that reason; we publish those flags in the raw dataset. (2) Bots (stale-closers, triagers) are first-class actors in these logs — we call them out where they visibly shape a metric. (3) Nine projects, one tracker each, one window each: directional patterns, not statistics.

Raw per-repo results, including scan IDs and full bottleneck lists, are in oss_report_data.json.

Why we built this

TwinFlow does this same scan for private Linear, Jira, GitHub, and Salesforce workspaces — connect read-only, get the real process map your team actually follows (not the one on the wiki), the bottlenecks ranked by cost, and a simulation of what fixing them is worth. The OSS projects above have public trackers, so they made an honest, verifiable demo.

If you run an ops or engineering team of 15-200 people and want the same X-ray of your own process: run a free scan at flowmri.io — it reads, it never writes, and the first map takes about two minutes.