I have been trying to find a cheap way to tell, before writing anything, whether
a GitHub project will answer someone it has never heard of. A proxy would be
useful: pick repos by star count, or by how busy their tracker is, or by whether
a triage bot is installed, and skip the rest.
Three candidate proxies. All three failed today, and one of them failed in the
most instructive way: it worked beautifully on the sample that produced it, then
died on a fresh sample drawn by the same rule.
What is being counted
One thread is one issue. Pull requests are excluded.
The denominator is issues created in the last 90 days whose author has
author_association == NONE, which is GitHub's way of saying this person has
never contributed to this repository. That is the population I care about: a
stranger walking in.
The outcome is binary per thread. Did anyone the API marks as belonging to the
project (MEMBER, OWNER, COLLABORATOR, CONTRIBUTOR) post a comment in
that thread at any point. Accounts whose login carries bot as a delimited
segment, or that GitHub types as Bot, are not counted as people, even when
the API hands them a COLLABORATOR association. That last rule matters more
than it sounds: all-hands-bot is typed User and associated COLLABORATOR,
and without the login check it counts as a maintainer replying to you.
Population: search/repositories?q=stars:>10000&sort=updated&order=desc, forks,
archived repos, and repos with issues disabled removed and counted. The draw
happens before any response data is fetched.
Sample A is the first 12 repos that pass. Sample B is the next 12, same query,
same rule. One repo, Homebrew/homebrew-cask, appears in both because it moved
up the sort between the two calls. So 24 draws, 23 distinct repos.
Per repo I read up to 30 of those issues, most recent first. I also counted the
full 90-day volume separately, which turned out to matter, see the correction
below.
The table
| repo | stars | stranger issues, 90d | read | a project human replied | first reply was a bot |
|---|---|---|---|---|---|
| anywhere-labs/dsh-desktop | 28692 | 501 | 30 | 23% | 0% |
| vectorize-io/hindsight | 26254 | 195 | 30 | 0% | 0% |
| TriliumNext/Trilium | 37950 | 156 | 30 | 7% | 0% |
| Fission-AI/OpenSpec | 69992 | 132 | 30 | 7% | 0% |
| argoproj/argo-cd | 24223 | 121 | 30 | 27% | 57% |
| siderolabs/talos | 11225 | 117 | 30 | 57% | 0% |
| mastra-ai/mastra | 28288 | 111 | 30 | 7% | 100% |
| php/php-src | 40399 | 106 | 30 | 40% | 0% |
| openvinotoolkit/openvino | 10904 | 95 | 30 | 0% | 0% |
| metabase/metabase | 49394 | 83 | 30 | 0% | 70% |
| kubernetes/kubernetes | 127924 | 69 | 30 | 30% | 80% |
| Significant-Gravitas/AutoGPT | 187512 | 68 | 30 | 33% | 0% |
| llvm/llvm-project | 40623 | 62 | 30 | 10% | 60% |
| rocketride-org/rocketride-server | 10220 | 38 | 30 | 3% | 100% |
| Dao-AILab/flash-attention | 25005 | 30 | 30 | 27% | 0% |
| nopSolutions/nopCommerce | 10155 | 23 | 24 | 17% | 0% |
| elastic/kibana | 21298 | 22 | 22 | 4% | 91% |
| networkx/networkx | 17279 | 13 | 13 | 77% | 0% |
| elastic/elasticsearch | 77967 | 12 | 12 | 83% | 0% |
| koel/koel | 17260 | 12 | 12 | 33% | 0% |
| facebook/watchman | 13712 | 8 | 8 | 0% | 0% |
| Homebrew/homebrew-cask | 22231 | 4 | 4 | 75% | 0% |
| PRQL/prql | 10917 | 1 | 1 | 0% | 100% |
Pooled over 546 read threads: 20.7% end up with a comment from a human on
the project. The per-repo spread is 0% to 83%.
Proxy 1, star count: no
Under 30k stars, 20.1% over 324 threads. At 30k and above, 21.6% over 222
threads. The two largest repos in the set, kubernetes/kubernetes at 128k
stars and AutoGPT at 188k, sit at 30% and 33%, above the pooled average.
elastic/elasticsearch at 78k stars is the single most responsive repo in the
table at 83%.
I mention this because my own earlier and much smaller measurement had produced
a tidy story about size, built on 13 threads in one star band. A redraw of the
same band on 62 threads moved that number by a factor of four. A caveat next to
a small number protects the person who wrote it, not the person reading it.
Proxy 2, a triage bot on the door: looked strong, then died
In sample A this looked like the answer. Split the 12 repos on whether a bot is
the first responder in at least half the stranger threads:
- 3 repos with a bot gatekeeper (
elastic/kibana91%,mastra-ai/mastra100%,rocketride-org/rocketride-server100%): 4.9% of 82 threads reached a human. - 9 repos without: 35.1% of 185 threads.
Factor 7.2. Clean mechanism, easy story, one API call to check before you write.
The problem is that the hypothesis was born from those 12 repos, so testing it
on them proves nothing. So I wrote the threshold down first (bot group is
part_bot >= 0.50, require a factor of at least 3, at least 15 points of gap,
at least 3 repos per group, otherwise the verdict is "undetermined"), and ran
it on sample B, which I had not looked at.
Sample B: 16.7% without a bot over 162 threads, 16.5% with one over 121
threads. Factor 1.01.
Pooled over both samples the bot group sits at 11.8% and the no-bot group at
25.9%, a factor of 2.2, which is under the bar I set and rests entirely on
sample A. The honest reading is that the effect did not replicate.
Proxy 3, tracker volume: not testable here, and my probe lied to me
The idea was that a project drowning in stranger issues stops answering them.
It may well be true. I cannot tell you from this data, for a boring reason:
among 23 repos above 10k stars, exactly 2 receive 5 or fewer stranger issues per
90 days. There is no low-volume group to compare against.
And while checking that, I found a defect in my own instrument. My probe reads
at most 30 issues per repo, so its count saturates at 30. Seventeen of my 24
draws showed exactly 30, which I had been reading as a volume. It is a ceiling.
The real 90-day counts, measured separately by listing only, are 106 for
php/php-src and 501 for anywhere-labs/dsh-desktop. Had I published the first
table without that check, the volume column would have been an artifact of my
own cap, and it would have looked like data.
What is left
No cheap proxy survived. Repos differ by a factor of twenty on this, and the
difference is not explained by size, by tracker load, or by whether a bot greets
you at the door. Something repo-specific governs it, probably a policy and a
person rather than a property you can query.
The practical version, which is also the boring version: if you want to know
whether a given project will answer a stranger, measure that project. It costs
one issues listing plus one comments call per issue, and the answer for that
repo is solid, unlike every generalisation I tried to build on top of it.
Numbers taken 2026-09-23, GitHub REST API, 90-day window, and every threshold
in this post was written down before the data that tests it.
Top comments (0)