Issue lifecycle & responsiveness

How long issues live in the sanskrit-lexicon org: cohort survival, backlog age, closing latency, and per-repository responsiveness. Object of analysis is the issue/PR record itself — not dictionary content. Source: reports/issue_lifecycle.md, generated by scripts/issue_lifecycle.py.

Time-to-first-response is not computable from the committed snapshot (it carries comment counts, not comment timestamps) — it is an API-gated extension tracked in the roadmap (Workstream G1).

Cohort survival

How to read: Each row is the set of issues opened in one year; each column a horizon after opening. The cell is the share of that cohort still open at that horizon — darker means more of the cohort survived unresolved. Cells are right-censored: a cohort only reports horizons its issues have had time to reach. Example 1: A dark 2014 row means the founding-era backlog never got worked off. Example 2: If recent rows go pale by the 90-day column, current triage is resolving most of what arrives within a quarter.

Conclusion: Survival is era-dependent, not uniform. The 2014 founding cohort still has roughly half of its issues open a decade later, while mid-era cohorts stabilise near a third. Whatever is not closed in the first weeks tends to stay open for years — the survival curve flattens almost immediately after the 90-day mark.

Backlog age pyramid

How to read: Currently-open issues bucketed by age at the snapshot. Each bar splits into issues that received at least one comment (blue) and the silent backlog that never got a single reply (amber). Example 1: A long "4+ years" bar means the open backlog is dominated by legacy items, not fresh work. Example 2: A large amber share in young buckets means new scholars' reports are currently going unanswered — the worst signal for contributor conversion.

Conclusion: The open backlog is old: two thirds of it predates 2022. The actionable slice is the silent backlog — issues nobody ever answered. Triaging those (close, label, or reply) is the cheapest single move to make the org look alive to an arriving scholar.

Time-to-close by closing year

How to read: For issues closed in each year, the line is the median days from opening to closing and the band spans the 25th–75th percentile. Example 1: A low, flat median with a wide band means most closures are fast but each year also digests some very old items. Example 2: A spike in the band without a spike in the median is a backlog-clearing campaign — old issues being swept, everyday responsiveness unchanged.

Conclusion: Everyday responsiveness is genuinely fast — the median closure takes days, not months, in most years. The long tail (p90 around a year) is where the survival problem lives: an issue either gets handled in its first days or joins the multi-year backlog.

Per-repository responsiveness

How to read: The fifteen repositories with the most issues, sorted by median days-to-close (computed only where at least 20 issues have closed). The dot is the median; the amber count is that repo's silent open issues. Example 1: A repo with a low median but many silent opens closes what it engages with, yet lets the rest sit unacknowledged. Example 2: A high median on a dictionary repo means a scholar filing a correction there waits longest for resolution.

Conclusion: Responsiveness differs by an order of magnitude between repositories under the same three maintainers — the difference is attention routing, not capacity. The slow large repos are where an arriving contributor's first issue is most likely to die unanswered, which makes them the priority for the silent-backlog triage above.

Data

All four datasets are downloadable from the Data page: issue_lifecycle_survival.csv, issue_lifecycle_backlog.csv, issue_lifecycle_close.csv, issue_lifecycle_repo.csv. Regenerate with python scripts/issue_lifecycle.py (offline, reproducible).