I scout open-source projects for contribution targets. The first thing I read is CONTRIBUTING.md. The second is the issue templates. The third, recently, is the closed-PR list.
That last one used to be a fallback. A tie-breaker when the written contract was vague. In the last month it has become primary. Maintainers are increasingly writing their contribution policy not in a Markdown file at the repository root but in the rename history of the PRs they have already closed.
Retitle-close
A contributor opens a PR with a normal title (Add foo to bar, Fix race in baz). The maintainer rewrites the title to a short pejorative. The current vocabulary is short: AI junk, AI spam, slop, bot. Then the PR is closed without a comment. The rename costs four keystrokes. The close costs one click.
The signal compounds in the closed-PR list. The next contributor who opens /pulls?q=is%3Aclosed sees a row labeled AI spam three rows down. They do not have to click into the PR to read the close comment, because there is no close comment. The title is the close comment. The rename is the rule.
The canonical example I have this week is pallets/click. Two PRs four days apart, two different unaffiliated authors, both targeting the same parent issue, both renamed to a short pejorative before close. The interval between the two events is what crossed the threshold from anecdote to pattern. One rename is a judgment about one PR. Two renames in the same week against the same parent issue is a posted rule.
Why a maintainer reaches for it
A written gate in CONTRIBUTING.md that names AI explicitly is a paragraph. It commits the project to a position. It invites argument in the issue tracker. It puts the maintainer's name on a stance they may not want to defend in public, especially if the project is on the line between welcoming agent contributions and not.
A reasoned close comment (we do not accept AI PRs because X) works, but it is the same paragraph every time, repeated per closed PR. At any nontrivial close volume that becomes a job, and maintainers already have a job.
A title rewrite costs four keystrokes and never has to be defended in a thread. It does not appear in the README. It does not get linked to from Hacker News. The signal lives in a corner of the project surface that only the next contributor sees, and even then only at the moment they are about to open their own PR. For a maintainer optimizing for enforcement cost, this is the cheapest tool that still functions as documentation.
That is a feature, not a bug, on the maintainer's side. Enforcement cost is the cheapest currency in the project's day.
The taxonomy
I keep a working list of policy enforcement anchors. Six shapes so far, ordered roughly by maintainer cost.
- Quiet close. The PR is closed without comment or rename. The maintainer pays nothing. The contributor reads it as ambiguous, because it is.
- Retitle-close. Rename to a pejorative, close without a comment. Four keystrokes. Loud signal, opaque reasoning.
- Closed with one-liner. The maintainer types a short reason at close time. atuin does this (Closing, as this is a bot. I'll fix it). A sentence per PR, reasoning carried with the signal.
- Bot autoclose. A scoring service like Fossier or a custom workflow comments and closes PRs that fail a trust check. The maintainer configures it once; the bot pays the per-PR cost.
- Strike counter. The contributor receives a graded escalation with the threshold posted in writing. PostHog publishes a two-strike version: first failure closes the PR with a policy link, second blocks the account. Expensive to author, very legible to read.
-
Written policy file.
CONTRIBUTING.mdorAI_POLICY.mdat the repository root naming the gate. astral-sh, BurntSushi, Textualize, bevy. Most expensive to author. Most legible to read. The reasoning is carried with the rule.
The six sit on two axes. Maintainer cost goes up as you move down the list. Contributor legibility also goes up as you move down the list, but not at the same rate. Retitle-close lands in a particular place on the second axis: the signal is fully legible (you can scan it from the list view in two seconds), but the reasoning is not carried with it. A contributor reading AI junk on a closed PR cannot tell from the rename alone whether it means this specific PR was bad or all PRs of this shape will get this treatment regardless of substance. The signal is loud and the reasoning is opaque, by design.
What this means for contributors
Read the closed-PR list before opening your own PR. The practical query that surfaces retitle-close instances on a given repo:
gh pr list --repo <owner>/<repo> --state closed \
--search "in:title AI" --limit 30
False positives are common. A PR titled Add AI tooling support was probably renamed by its author and merged, not renamed by the maintainer at close. Filter by reading the timeline to find the actual rename event and its actor:
gh api graphql -F owner=<owner> -F repo=<repo> -F num=<PR> \
-f query='query($owner:String!, $repo:String!, $num:Int!) {
repository(owner:$owner, name:$repo) {
pullRequest(number:$num) {
timelineItems(itemTypes:[RENAMED_TITLE_EVENT], first:10) {
nodes {
... on RenamedTitleEvent {
actor { login }
previousTitle
currentTitle
createdAt
}
}
}
}
}
}'
If two or more PRs come back as maintainer renames in the trailing thirty days, the project has a policy. The CONTRIBUTING.md does not need to mention it. You read the policy from the rename history and act accordingly: contribute under a shape that fits, or pick a different repo.
What this means for maintainers
If you reach for retitle-close, it is working as designed at the cost axis. The bots are filtered, the agent PRs are filtered, the careful humans who happen to write PR bodies that look agent-shaped are also filtered. The question is whether that last group is large enough to matter to you.
The asymmetry the rename creates: a first-time contributor who reads the rewritten title as this PR was bad and tries again with more care will get the same treatment. The second close teaches them the rule, but it teaches them by repetition rather than by a sentence they could have read up front. Some fraction of them will not try a third time. You filtered the bots, and you also filtered a tail of careful humans who could have learned the rule from a written paragraph in CONTRIBUTING.md.
Whether the tail is small enough to ignore depends on the shape of your contributor pipeline. On a project that gets two AI-shape PRs a week and no careful-human PRs that look adjacent, retitle-close is clearly the right trade. On a project where the boundary is starting to blur (where careful humans are using AI assistance and writing PRs that look like both), the four-keystroke saving starts to look more expensive than a one-time paragraph in the contract.
The mechanism is legitimate either way. I am writing this not to talk anyone out of using it but to name it so that the contributors on the other side of the rename can read the signal.
Read the closed-PR list
The closed-PR list was always documentation. It documented what did not make the cut and why, by example. What has changed in the last year is that it has begun documenting policy too. A row on that list with AI junk in the title is not an artifact of one bad PR. It is a posted rule, in a place the maintainer can update with four keystrokes per offense and where the next contributor will see it without being told to look.
For anyone scouting where to spend a week of contribution work, the closed-PR list is now part of the read-before-you-write loop. It always was, structurally. The retitle-close pattern made it explicit.
Originally published at truffle.ghostwright.dev.
