A median reply time can only see the issues that got a reply, so count the ones that got none
You file a bug against the framework your product is built on. Nothing happens. The repository looks alive the whole time you are waiting: commits daily, stars climbing, a new release out. Nobody has typed a word under your issue.
That silence is the thing I wanted a number for.
StillShipping publishes a maintained / stale / dead verdict for agent tooling, recomputed every night from what GitHub publishes about each repository. Commit recency is the easy input. Whether a human being is on the other side of the issue tracker is the one a star count can never carry, and it is the one that decides whether you get unblocked.
Four things to throw away before you have a sample
Ask GitHub for a repository's issues and pull requests come back mixed in with them. Of the ten newest items on microsoft/autogen, read on 2026-08-22, eight were pull requests. Ask for forty items and filter, and your "sample of recent issues" can quietly be two issues long.
Issues opened by the maintainers themselves come out next. A maintainer files a roadmap note, another maintainer replies in nine minutes, and that scores as responsiveness to an outsider who is not there. GitHub stamps every issue and comment with the author's relationship to the repository, so OWNER, MEMBER and COLLABORATOR all mean "can merge", which you get for free rather than asking for the collaborator list, a question most of the access we run under is not allowed to ask.
Inside the comments, the first reply has to clear two tests: written by someone with write access, and not written by the person who opened the issue. Somebody bumping their own bug is not an answer.
const MAINT = new Set(['OWNER', 'MEMBER', 'COLLABORATOR']);
const candidates = data
.filter((i) => !i.pull_request)
.filter((i) => !MAINT.has(i.author_association))
.slice(0, sample);
for (const issue of candidates) { if (issue.comments === 0) { unanswered++; continue; } // ask GitHub for that issue's comments const first = comments.find( (c) => MAINT.has(c.author_association) && c.user?.login !== issue.user?.login, ); if (first) latencies.push((new Date(first.created_at) - new Date(issue.created_at)) / 3_600_000); else unanswered++; } ```
The comments === 0 line is worth the two seconds it takes to notice. That count arrives with the list already. Zero comments means no maintainer reply without asking, so the repositories that ignore everything are exactly the ones you never have to go back and ask about.

The number that can only see the good news
Take the middle value of latencies and you have a clean, publishable figure: typical time to a first maintainer reply. It is computed over the issues that got a reply, and there is no other way to compute it. Every issue nobody touched contributes nothing, because there is no clock to stop.
So a project that answers one issue in twenty minutes and leaves the next seven alone reports twenty minutes.
That is why the same pass keeps a second number that has no survivorship in it: of the outside issues sampled, how many got no maintainer reply at all. Every issue counts in that one, answered or not.
Measured live on 2026-08-22, eight recent outside issues sampled per repository:
| repository | median first maintainer reply | sampled issues with no maintainer reply |
|---|---|---|
| oraios/serena | under an hour | 7 of 8 |
| zed-industries/zed | 1.1 hours | 7 of 8 |
| crewAIInc/crewAI | 59.4 hours | 7 of 8 |
| microsoft/autogen | none to measure | 8 of 8 |
| github/spec-kit | none to measure | 8 of 8 |
Read the first column alone and Serena answers faster than anyone on the list. Both columns are true at once, and they are answers to different questions. The first says how fast the lucky issue moved. The second says what your odds are of being the lucky issue.
In the stored table on 2026-08-22, 337 tracked repositories, 78 have a median first reply at all. Seventeen of the 57 that clear a two day median leave 70% or more of their sampled issues with nobody replying. Those seventeen are the ones worth catching, because they are the ones where the fast number is the only number you would have seen.
Both figures go on the tool page with the effect each one had on the score, so the verdict can be argued with rather than believed.
That is how we built the issue signal behind StillShipping: https://stillshipping.thecompound.tech/?utm_source=compound-devto&utm_medium=social&utm_campaign=compound
---
One shipped product, taken apart, once a month. What it does, what it cost to build, what the pipeline behind it looks like, and what the numbers did, read off the repository and the live site, not written from memory. Join the list.