What is a draft pull request on GitHub, and what changes when you mark it ready for review?

## The problem drafts solve Before drafts existed, teams faked them: `WIP:` in the title, a `do-not-merge` label, a comment saying "not ready". All of those rely on humans reading carefully, and none of them stop the merge button. A draft pull request makes the intent a first-class state that GitHub itself enforces. ## What a draft actually changes **Merging is blocked.** This is the hard guarantee. Approvals can be in, every required check can be green, and the merge button is still disabled. Nobody can merge your unfinished work by accident. **Automatic review requests are held.** GitHub's automatic reviewer assignment — including requests generated from a CODEOWNERS file and team review assignment — does not fire while the pull request is a draft. That is the point: opening early should not spam the people who own the touched paths. When you mark it ready, those requests go out. Manual review requests still work at any time, so you can pull in one person for an early opinion. **Everything else is unchanged.** The pull request is visible to everyone who can see the repository. The diff renders, comments and review threads work, linked issues link, and CI generally runs exactly as it would otherwise, because the underlying branch pushes are the same events. ## The lifecycle around it The usual path is: push a branch, open a draft early so colleagues see the direction and CI starts exercising the change, iterate, then click *Ready for review*. GitHub emits a `ready_for_review` event at that moment, which is how automation can distinguish "this changed state" from "someone pushed another commit". Converting back to draft is equally useful and under-used. If review surfaces a design problem, moving the pull request back to draft communicates "stop reviewing line by line, I am rewriting this" far more clearly than a comment does, and it re-establishes the merge block while you work. ## Where drafts interact with other GitHub features - **Auto-merge.** You cannot arm auto-merge on a draft; mark it ready first. That is consistent — auto-merge exists to merge as soon as requirements are met, and "still a draft" is a requirement that is deliberately not met. - **Required approvals.** Approvals given on a draft still count once it is ready; the draft state gates merging, not reviewing. - **Review load.** On a busy repository the held-back automatic requests are the main practical benefit: reviewers' queues stay meaningful because everything in them is genuinely awaiting review. ## Common misconceptions Candidates sometimes think drafts are private, or that they suppress CI, or that comments are disabled. None of that is true. A draft is public to anyone who can read the repository, and treating it as a private scratch space is a real mistake — a draft in a public repository is world-readable, so it is not a place to park secrets or unreleased plans. Others think a draft can be merged "if you are an admin". It cannot; the state must be changed first, which is a deliberate design choice because state changes are visible in the timeline while a silent bypass would not be. ## How to answer well Give the two enforced behaviours — no merging, no automatic review requests — then the one thing that does not change (visibility and checks), then mention converting back to draft as a communication tool. That structure shows you know the mechanism and how a team actually uses it, which is what a screening question about drafts is testing.