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-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:

| class | what it is | can a human taking authorship satisfy it? | |---|---|---| | ⛔⛔ PROHIBITED_CERTIFICATION | a checklist item the submitter certifies: "I have not used an AI coding assistant to create this PR" | no — it is a claim about what happened, and no transfer of authorship or matching of style makes a false one true | | ⛔ PROHIBITED_REQUEST | "Please do not submit pull requests generated by AI (LLMs)" | ⭐ yes — it is a request about what they receive; nobody is asked to certify anything | | ⭐ DISCLOSURE_TRAILER | requires a Co-Authored-By / Generated-by commit trailer | mandatory process — omitting it is the violation | | DISCLOSURE_PROSE | asks for disclosure in the PR description | mandatory process | | SILENT | no clause in the repo or its parents | a decision for the human, not a rule |

⛔⛔ 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

| Shortcut | Why it fails | |---|---| | "They have 2,256 open issues, there's obviously work." | Open issues are demand. One house measured 240 open PRs with 94% older than 30 days and a 1:7 merge:reject ratio — the work existed and could not land. | | "good first issue means they want help." | Both closed-door houses measured had zero maintained on-ramp labels; two open ones also had zero. The label correlates with nothing. | | "CONTRIBUTING is friendly and detailed." | One repo's CONTRIBUTING says outright "we are very overloaded, so issues and PRs sometimes wait for a very long time" — the honest ones tell you, and it is still not in the ratio. | | "The queue is stale, so nothing merges." | Wrong on one house: 92% of the queue >30 days and the last twelve merges took 0–5 days, one-off authors included. Bimodal. Writing it off would have cost a landed PR. | | "I'll read the licence when the PR is ready." | In a house where agreement follows from contributing, the PR is the acceptance. There is no later. | | "No CLA bot showed up on the recent PRs I looked at, so there isn't one." | Those authors had already signed. The bot and its required check appear only for someone who has not — which is you. Measured: it posted on the second push, with a not_signed badge and a blocking license/cla check. | | "The CLA is signed, so CI will run now." | Two independent gates. Signing flipped license/cla to SUCCESS and left all five workflows in action_required. | | "The CLA looks aggressive — perpetual, irrevocable, patents." | Diffed against the Apache ICLA, that wording was identical, adjective for adjective. What differed was the recipient and the outbound licence. Report the diff, not the adjectives. | | "It's just a test fix, the appraisal is overkill." | The appraisal is six commands. The fix took a build, a 50-minute measurement sweep and a review round-trip. |

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:

| probe | value | reading | |---|---|---| | open PRs / of those >30 days | 640 / 591 = 92% | the same shape as a house measured closed (94%) | | merged : closed-unmerged, 60 d | 122 : 56 = 2.2 : 1 | merges outnumber rejections | | created → merged, last 12 | 0–5 days, mostly 1–2 | including three one-off authors (1 d, 2 d, 2 d) | | authors in last 40 merges | 14 distinct, top author 6 | outsiders land | | CI on a first-time author's PR | ⛔ needs maintainer approval | ⚠️ my first reading said "runs freely" and was wrong — below |

⇒ 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 /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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: serhiy-bzhezytskyy
• Source: serhiy-bzhezytskyy/contrib-receipts
• License: MIT

Install and usage instructions live in the source repository linked above.