Inside 80 Pull Request Templates From Popular Open Source Projects

A pull request template can ask for very little, and most of 80 well-known open source repositories do exactly that.

I fetched every template straight from the GitHub, and the shape that turns up most often has exactly two prompts: an account of the change with its reason, and a description of how the author checked it.

I read them the way a designer reads a form. Every field costs the person filling it in. Every field should also hand the reviewer something they could not get elsewhere, and judged that way, the boxes that restate CI fail first.

Templates that render as nothing

CPython, curl, Deno, etcd, Laravel, Node, Rust, Spring Boot, Swift, Vite and VS Code all belong here.

Their sizes vary a lot. etcd needs 7 lines and VS Code 8. Laravel uses 9, Vite 21 and Swift 22, while Spring Boot reaches 29 and Node 45. Length makes no difference to what the reviewer sees, which is nothing.

What they say while hidden is revealing. Rust's comment explains its own homu-ignore:start and homu-ignore:end markers, which tell the merge bot to strip the text. CPython's carries only title guidance, the gh-NNNNNN: prefix followed by a summary. Node carries the Developer's Certificate of Origin 1.1 in full. Deno keeps a numbered list of rules. Swift describes the change it expects and how to trigger CI. curl carries nothing but an AI policy: "If you cannot understand or explain your work without using Artificial Intelligence (AI) then do not file here."

So these files are notices, closer to a sign on a door than to a form. They most often cover which branch to target, where security issues go and what not to send. A reviewer never sees them, and neither does anyone reading the history years later.

That design has one clear use. It reaches the author at the last moment before submission, when a wrong target branch is still cheap to fix.

Projects with no template

19 of the 80 repositories that answered ship no pull request template at all.

Vue core, webpack, Nuxt, React Router, Preact, Playwright,
Express, Fastify, TensorFlow, DuckDB, containerd, Mastodon,
OBS Studio, uBlock Origin, Kotlin, Ruby, PHP, LLVM, workerd

These are not the small ones, and they come from every domain the survey covered, from compilers and runtimes to databases, editors and web frameworks. Several maintain elaborate issue templates, so leaving the pull request box empty is a decision about where structure belongs.

The common template is two prompts long

The remaining templates, roughly fifty, put visible structure into a description. Their median is small, and the shape that turns up most is a pair of prompts: the change with its purpose, then how it was tested.

### What does this PR do?

### How did you verify your code works?

That is Bun's template, word for word, three lines in all. React, Solid, Tailwind, Neovim and Biome keep the same two ideas and add little. React's version has four visible lines and ends on the only stated consequence anywhere in the sample: "If you leave this empty, your PR will very likely be closed."

Long checklists come with heavy traffic

Above the two-prompt floor, projects reach for very different tools.

Angular splits the description into current behavior and new behavior, adds a breaking-change question and asks the author to pick one of nine PR types. Kubernetes runs to 92 lines with seven headings, from special notes for the reviewer to an AI usage disclosure. Grafana asks three plain questions: what the feature is, why it is needed and who it is for.

Some projects drop prose entirely. Babel and Symfony both use a question-and-answer table, and Symfony's is read by a bot for labelling. Envoy uses colon-terminated fields, such as Commit Message, Risk Level and Release Notes. Go writes a plain-text instruction list with no headings at all.

PyTorch goes another way and offers a directory of three choosable templates, for a docs typo, a fix for an issue and a preapproved change.

Section frequency

what changed and why      nearly every visible template
linked issue              about two thirds
testing or verification   about half
a checklist               about a third
AI authorship disclosure  about a third, the newest
release note slot         ten or so
breaking change callout   under ten
risk and rollback         three

What changed and why is nearly universal. Small templates phrase it as one question.

The linked issue is the next most common ask. Most projects mention it in a comment. PyTorch, Keras, LangChain, Django, TypeScript and Axios treat it as mandatory, and the strict ones tend to attach a threat of closure, since a soft request gets ignored.

Checklists

Checklists concentrate in high-volume consumer projects. The three heaviest checklist templates are Home Assistant at 119 lines, Transformers at 91 and Storybook at 86, and every one of them receives a stream of contributions from people who will submit once. The boxes screen that stream before a human looks. Home Assistant even has a box asserting the author reviewed two other open pull requests.

Checklists travel well beyond consumer apps. Angular, Svelte, Django, Rails, Vitest and pandas all carry one. Among consumer apps, Signal-Android asks the author to list the devices and Android versions they tested on. Element asks for guidelines, tests, screenshots and the CLA, plus a pledge not to force push again. Immich and cal.com both pair their checklist with a testing section written in plain words.

Where contributors are regulars, the checklist disappears. Neovim, curl, Git and Bun have none.

CI boxes

A box asking whether lint passed or tests pass is a claim nobody verifies. The pipeline already knows the answer, and it gates the merge regardless. The tick has no effect.

What earns space is the thing a pipeline can't see. Spark asks for copy-pasteable steps when a change was tested outside the regular unit tests. Storybook asks separately how the author tested and how a maintainer should reproduce it. Zed and Syncthing ask how a reviewer gets to the change at all.

Release notes

Moby, Terraform and Envoy carry a fenced release-note block that a changelog tool scrapes, as do Kubernetes, Prometheus and Zed. Grafana goes further and uses the pull request title itself to auto-generate its changelog. Without that tooling, a release-note section is dead weight.

Risk and rollback

Only three templates ask about risk. Terraform's asks which release a change targets, promises a revert within seven days if one is needed, and wants any change to security controls named. Envoy gives risk its own labelled line. The dotnet servicing template asks for customer impact, regression status and risk, because a merge there can go into a release customers already run. No library or frontend framework asks.

Titles

Where a title becomes a durable record, the template polices it. CPython wants the issue number up front. Go wants a package prefix like net/http:, a short title and no Markdown. Deno asks for a conventional-commit prefix with worked examples. The title ends up as a commit subject, a backport tag or a changelog line.

AI disclosure

About a third of templates now ask about AI, and the wording differs every time. Django requires one of two exclusive boxes. pandas wants to know the exact assistant, its model version and its effort level. Caddy pre-fills "This PR is missing an assistance disclosure" under its heading, so silence ships as an admission. Transformers tells first-time contributors not to use code agents. Kubernetes writes a line addressed to the agent.

Two missing prompts

Why the defect wasn't caught earlier appears in no template. It's the one thing a reviewer cannot reconstruct from the diff, because the diff shows the fix and never the path by which the bug slipped past every earlier review, test and release.

The second gap is smaller. What the change still doesn't prove appears only obliquely, in dotnet servicing through customer impact and in Envoy through its risk field. Both come close to asking where the author's confidence ends, and nothing else in the sample does even that much.

What I'd put in a template

For a small project with regular contributors, I'd write two prompts and stop:

the change and its reason, opening on what changed rather than on what broke
how it was verified, phrased so that restating the pipeline obviously doesn't count

A linked issue joins them only where work really lives in issues. Release notes wait for a generator. Risk questions come in the day a merge could hurt a production system or someone's data, and not a day before 🎯

Limits of the evidence

Everything here comes from one snapshot of default branches. Templates change fast. The AI sections alone are young enough that a year ago most of them didn't exist. I picked repositories by popularity, and popular projects run heavier templates than most.

The survey records what templates ask and says nothing about whether contributors answer, which is the question that would settle which fields work.