Price The Door Before You Enter

Price the door before you enter

Purpose

The cost of entering a house is paid before any code is written, and it is refunded only if a PR can actually merge. Every surface a repo shows you — issue count, labels, a warm CONTRIBUTING, a defect you can reproduce in an afternoon — describes demand. None of it describes supply: whether anyone reviews outside PRs, how long they take, what fraction they reject, and what rights you sign away by opening one. Those four things are four API queries and two files, and they routinely reverse the decision. A repo can want a fix, document the workflow perfectly, and still merge nothing from outside for eighteen months.

The queries also produce the numbers you will need later: the latency tells you when silence stops being normal, the rejection ratio tells you how much a first PR is worth risking, and the author spread tells you whether outsiders land at all or only the staff who cut releases.

When to use

• Someone asks "can we contribute to X" about a repo with no landed PR of ours.
• You have found a defect in an unfamiliar repo and are about to start on the fix.
• A repo looks inviting: many open issues, good first issue labels, an active feed.
• A repo looks dead and you are about to write it off — the latency probe distinguishes dead from slow from bimodal, and only the first is a reason not to enter.
• Before promising a human that a contribution is coming.

When NOT to use

• A house already entered and landed in. The numbers are in its playbook; re-measure only when something surprises you.
• A repo we own or control, where merge access is not the question.
• A one-line typo fix offered with no expectation — the appraisal costs more than the work.
• When the human has already decided to enter for a reason that is not merge probability (relationship, learning, a specific person to reach). Price it anyway and say the number, but do not argue with the decision.

The practice (checklist)

1 — The four probes. Substitute $O/$R:

gh api "search/issues?q=repo:$O/$R+is:pr+is:open&per_page=1" --jq .total_count
gh api "search/issues?q=repo:$O/$R+is:pr+is:open+created:<$(date -v-30d +%F)&per_page=1" --jq .total_count
gh api "search/issues?q=repo:$O/$R+is:pr+is:merged+merged:>$(date -v-60d +%F)&per_page=1" --jq .total_count
gh api "search/issues?q=repo:$O/$R+is:pr+is:unmerged+closed:>$(date -v-60d +%F)&per_page=1" --jq .total_count

The ratio merged : closed-unmerged is the door. Measured: 1 : 7 (closed), 2.2 : 1, 7 : 1 (wide open).

2 — The latency probe, which is a separate axis.

gh pr list --repo $O/$R --state merged --limit 12 --json number,author,createdAt,mergedAt \
  --jq '.[]|"\(.number) \(.author.login) \(.createdAt[0:10]) -> \(.mergedAt[0:10])"'

A stale queue and fast merges can coexist. When they do, being seen is the constraint and correctness is not — which changes the whole strategy: it argues for a small, obviously- scoped first PR and for accepting that silence means the other bucket.

3 — Who lands, not just how many.

gh pr list --repo $O/$R --state merged --limit 40 --json author \
  --jq '[.[].author.login]|group_by(.)|map({a:.[0],n:length})|sort_by(-.n)[]|"\(.n)\t\(.a)"'

Count one-off authors. Staff plus release-cutters with no one-offs is a closed door wearing a healthy ratio.

⛔⛔ Check the CI gate on a FIRST-TIME author's PR, or read .github/workflows for the trigger — never on an established contributor's rendered checks. The gate is invisible exactly where it does not apply: two recent outside-author PRs showed a full green matrix, so I recorded "CI runs, no approval gate", and then our own first PR returned action_required on all five workflows with only the repo's review bot completing. ⇒ Getting this backwards makes "no checks" read as a defect forever after, and it is a permanent false alarm in the whose-court sweep.

4 — The enforced gate, in YAML not in prose. Grep .github/workflows/ for a bot that auto-closes, requires an issue link, or gates CI. A workflow file is a fact; "the maintainers seem busy" is a feeling.

5 — The licence and the CLA acceptance mechanism. Read CONTRIBUTING.md and LICENSE* before writing code, and answer three questions explicitly:

• How is the CLA accepted? A signed form, a bot — or by the act of contributing, in which case gh pr create is the signature and the moment is irrevocable. ⛔⛔ Do not conclude "no CLA bot" from the checks on other people's PRs. Their authors have already signed, so the bot and its pending check are invisible there. I made exactly this call and it was wrong on all three counts — there was a click-through form at cla-assistant.io, a bot that comments, and a required license/cla status check that blocked the PR. It appeared only on the second push, not at open. ⇒ Check the repo's .github config and search closed PRs by first-time authors for a CLA bot comment.
• Who receives the grant — a foundation or a company?
• What licence does the contribution ship under, and is it OSI-approved?

⛔ Diff the clauses against a CLA already accepted before calling anything unusual. Alarm read cold is not information. And if a clause turns on employment ("legally entitled to grant"), surface it as the human's decision — never resolve it.

⭐⭐ 5b — The contribution-tooling policy, which can close a door that every mechanical measure says is open — and it lives in prose no API field exposes. Read, in this order: .github/pull_request_template.md, CONTRIBUTING.md, and any contributing/ or docs/*/contributor-guide/ directory. ⛔ Then read them again in the PARENT or ORG repo.

for R in "$O/$R" "$O/.github" "$PARENT"; do
  for P in .github/pull_request_template.md CONTRIBUTING.md docs/CONTRIBUTING.md; do
    gh api "repos/$R/contents/$P" --jq .content 2>/dev/null | base64 -d 2>/dev/null \
      | grep -inE 'do not submit .*(AI|LLM)|Generative AI Policy|AI (coding )?assistant|generative tooling|AI-[Gg]enerated'
  done
done

⚠️ Use word boundaries: case-insensitive CLA matches class, declare, clause, and plain AI matches available, maintain, domain. One pass of mine said "0 mentions" and the next said "5 files"; both were artefacts of the pattern, not facts about the repo.

⭐ Classify by FORM, not by topic — the form decides whether anything is possible:

⛔⛔ The receipt for why this step exists. I priced fifty repos by plumbing — CLA bots, required checks, Signed-off-by, who pressed merge — and ranked opentofu/opentofu first for openness: no bot, no CLA status, 13 check-runs. Its PR template line 19 is - [ ] I have not used an AI coding assistant to create this PR., with the reason in contributing/DEVELOPING.md:181 — LLM training data may contain BUSL-licensed Terraform, so a model "may emit copyrighted code". The last three merged PRs all carry [x]. ⇒ The most closed row in the map by the only criterion that governs how we work, ranked first by mine. A verified one-line fix, proved red→green over five seeds, was unshippable and stayed unshipped.

⛔ And the parent-repo half is not hypothetical either. A per-repo scan called duckdb/duckdb-fts silent; the Generative AI Policy is at duckdb/duckdb CONTRIBUTING.md:131 and governs the extension. Same shape for opensearch-project/opensearch-benchmark (org-level .github, deferring to the Linux Foundation policy) and apache/solr-orbit (parent's PR template). ⇒ A SILENT verdict is only worth recording if you name which files, in which repos, you read.

⚠️ Four houses, four incompatible correct answers — Kafka requires the trailer that our own convention says to strip; duckdb wants no disclosure at all; Solr wants prose disclosure; OpenTofu wants no such contribution. ⇒ A policy carried over from the last house is a defect, not a default. Record the class and the file:line in the house's playbook.

⇒ ⛔ Where the class is PROHIBITED_CERTIFICATION, stop and say so. Do not draft toward making the certification pass, and do not treat style-matching as a workaround: the cost of a false certification lands on the human's name in every house at once.

6 — Write the numbers down with the query beside each one, in the house's playbook. A count without its query is not re-checkable, and full-text counts read exactly like triaged ones.

Rationalizations

RECEIPT

redis/redis, 2026-08-13 — the eleventh house, entered on the strength of these probes, and the appraisal decided both whether and how.

Measured before reading any issue:

⇒ The two axes disagreed, and that was the finding: a queue where 92% never moves and what moves merges within a day. Entering on the ratio alone would have been right by luck; entering on the ratio and the latency told us the real constraint is attention, which directly shaped the first PR — small, test-only, one file — and set the expectation that a week of silence means the other bucket.

The licence probe changed the sequence of the whole entry. CONTRIBUTING.md, first line: "By contributing code to the Redis project in any form you agree to the Redis Software Grant and Contributor License Agreement" — no form, no portal, and no CLA bot in the checks on outside PRs. So there was nothing to sign and nothing to prepare: the only act was a decision, and gh pr create executed it irrevocably. That is a fact you cannot discover after the fact.

And the clause comparison prevented a false alarm. The grant reads "perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable" for copyright and patents — reported first as alarming, then diffed against the ASF ICLA (pdftotext) and found to be the same six adjectives and the same termination-on-litigation clause, with the Foundation replaced by Redis. Three things actually differed: the recipient is a company, two of the three outbound licences are not OSI-approved, and ASF makes you sign while here the PR is the signature. ⇒ The decision was made on those three, not on adjectives.

Outcome: redis/redis#15636 opened 2026-08-13, reviewed by a core developer within 8 hours — in a repo where 591 PRs have waited more than thirty days.

⚠️ And one probe of the six came out wrong, which is why the checklist now says "first-time author". I recorded "CI runs on an outside PR, no approval gate" from the rendered checks of two authors the repo had already approved once. Ours returned action_required on all five workflows — CI, CodeQL, Spellcheck, Codecov, External Server Tests — against 16 SUCCESS on a known author's PR in the same window. The appraisal was right about the door and wrong about the turnstile.

Lifecycle

• Re-measure when a house surprises you — a review that arrives in 8 hours or silence past the measured latency both mean the numbers moved.
• The numbers belong in <repo>/playbook.md with their queries, dated. They are the baseline every later "is this normal?" question is answered against.
• A closed door is a finding, not a failure: record the ratio and the enforcing workflow so the next appraisal of the same repo costs nothing.
• ⚠️ The probes appraise the repo, not the work. They say a PR can land; they say nothing about whether the candidate is claimed, already fixed, or worth doing — that is the pre-flight search, and it has killed candidates in two houses.