A draft label is a useful work-in-progress signal. It is not a magic cupboard that makes a crowded contribution queue disappear. Before changing a pull-request cap, count the work that the cap will actually cover.
On October 8, 2026, GitHub announced that pull-request limits can be configured to include drafts. Previously, drafts were excluded. The important word is configured: the announcement does not establish that every repository has automatically changed its setting.
First resolve the documentation mismatch
As checked on October 9, GitHub’s repository interaction-limit guide still said drafts were excluded. Treat the dated announcement as evidence of the new capability, and inspect the actual setting before relying on it. Do not assume that an older help paragraph describes your saved configuration.
The repository guide describes the underlying cap for public repositories and users without write access. It also describes a trusted-contributor bypass list. This is not a universal cap on every contributor, a review-quality score, or an API rate limit. A search-result count alone cannot establish whether a particular author is subject to it.
This guide offers an original read-only inventory and change record. It is not a report of a tested rollout in your repository. If you cannot see the draft-inclusion control, ask an authorized maintainer to inspect it; do not invent an API parameter or change permissions to hunt for it.
Make one row per author, in one repository
Start with a single public repository whose queue you help maintain. Write down its exact owner/name, the time of inspection, the displayed limit, whether drafts are included, and any bypass entries relevant to the people you are checking. If a value is not visible to you, record unknown. A blank cell is too easy to mistake for zero.
Use GitHub’s documented search qualifiers to separate open drafts from open non-drafts. Replace OWNER/REPO and USERNAME below; these are search strings, not terminal commands.
repo:OWNER/REPO is:pr is:open author:USERNAME draft:false
repo:OWNER/REPO is:pr is:open author:USERNAME draft:trueOpen the matching results and record their PR numbers. Check that you did not retain an unrelated label, branch, or review filter from a previous search. Repeat for the next author without mixing repositories. Keep the two observations close together: a PR can change state while you are counting.
| Author | Open non-drafts | Open drafts | Covered by cap? | Evidence or unknown |
|---|---|---|---|---|
| Contributor A | 2 | 3 | Verify | Record PR numbers and access/bypass check |
| Contributor B | 1 | 0 | Verify | Record PR number and access/bypass check |
| Your next author | — | — | Unknown | Do not infer access from activity |
The two filled rows are invented examples, not GitHub measurements. Ready here means non-draft; it does not mean approved, passing checks, or safe to merge.
Compare both counting choices before touching settings
For the fictional Contributor A, the inventory contains two non-drafts and three drafts. A non-draft-only count is two. A count including both is five. With a hypothetical cap of four, the second number is already above the proposed threshold. That arithmetic identifies a conversation to have; it does not predict how GitHub will handle existing PRs after a setting change.
Do not close useful work just to make the worksheet look tidy. Ask which draft is active, which has a next step, and which is superseded. Give each uncertain item an owner and a follow-up date. A quiet draft may be waiting on a maintainer rather than abandoned by its author.
Write down why you want the change. “Our review queue contains repeated unfinished submissions from the same authors” is a checkable problem. “Fewer PRs must mean better quality” is not. If your problem is slow reviews of useful contributions, a cap alone does not assign anyone to review them.
Use a before-and-after change record
Have an authorized maintainer make the deliberate settings change. Keep the old values before saving, then reopen the same settings page and verify the saved state. Do not submit disposable PRs to somebody else’s project to test a boundary.
| Record | Fill in before changing anything |
|---|---|
| Repository and decision owner | Exact owner/name; person accountable for the change |
| Before | Displayed cap; draft inclusion; relevant bypasses; observation time |
| Proposed change | Specific setting to change and why |
| Expected effect | Which observed author rows would be affected |
| After | Saved values read back; time; any discrepancy |
| Revisit | Review date; person responsible; condition for restoring prior settings |
If the saved state is unclear, stop at “not verified.” Do not announce a new contribution rule as active. If a legitimate contributor later reports a blocked submission, capture the exact repository, displayed message, time, and existing PR links before changing the cap again.
Explain the queue rule without treating contributors as the problem
Adapt this short notice only after checking the values: “We now count [drafts and non-drafts / non-drafts only] toward our concurrent pull-request limit for affected contributors. Before starting another submission, please check your existing PRs and their next steps. If useful work is blocked, contact [the project’s existing maintainer route] with the relevant PR links.”
At the review date, compare a few concrete outcomes: which useful submissions were delayed, which stale items gained a next step, and whether maintainers actually spent less time sorting the queue. Record observations, not a made-up productivity percentage. Keep the cap only if it addresses the problem you wrote down.
Done means: the repository is identified, drafts and non-drafts are counted separately, affected authors are checked rather than guessed, the saved setting is read back, and someone owns the next review. The cupboard can stay. Just label what is inside.