Introducing draft pull requests

When I was interviewing GitHub employees for my book (<a href="https:&#x2F;&#x2F;buildingtoolswithgithub.teddyhyde.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;buildingtoolswithgithub.teddyhyde.io&#x2F;</a>) one of them made a surprising comment. Early on, his GitHub teammates told him he should create an empty PR with a plan of attack before writing any code. I thought it was a brilliant idea and most teams don&#x27;t do this. Smart of them to make this a separate feature instead of just bolting on WIP.

Help me understand something -- right now my workflow is to create a new branch when I&#x27;m working on a new feature. One branch per feature. I check in frequently and push up so my work is saved.<p>Sometimes I ask people to look at the code in progress when I want opinions on architecture or just overall code quality.<p>When I think the feature is ready for merging, I&#x27;ll create a pull request.<p>How does a draft PR help me? What do I get with a draft PR that I don&#x27;t already have?<p>I assume it&#x27;s a good idea, and everyone here seems to think so too, so I think I&#x27;m missing something obvious.<p>Edit: Lots of great points below, mostly pointing out features that I don&#x27;t really use a lot, which is why I didn&#x27;t see the improvement. Thanks everyone!

It would also be nice to have a way to link multiple PRs together so they can be merged simultaneously. A ton of people are working across multiple repos which makes reviewing and coordinating changes really annoying.

I&#x27;m assuming this is a response to GitLab&#x27;s concept of a WIP merge request.

Nice, I tend to like having pull requests created early so people can follow what is happening and give early feedback.

This blog post really doesn&#x27;t sell this feature well. How is this any different at all from me just putting &quot;WIP&quot; in the title of the PR? Ok, so it prevents merging a WIP PR - who would do that?

I just use a WIP label on the PR, keep it simple.

Love it. I’ve had success using Issues in the past to do get implementation feedback, and have a “one pager” for whatever I&#x2F;the team was working on at the time, but it didn’t feel like it stuck very well with junior team members.<p>Having something like this that allows a little closer relationship between the plan and the code created for the plan is nice.

This is good. We have been emulating this with either a &quot;don&#x27;t review yet&quot; tag or by opening a pull request without setting reviewers, but it&#x27;s clearly better to have support for it built in. More people will use it, and I don&#x27;t have to train people in our particular way of indicating not-ready pull requests.

Very happy about this. We recently switched to github and I asked my team to start their PRs immediately. Was pretty disappointed to discover that they needed something to commit first. Having a draft state will in itself be really useful.

This is rad. I usually like to put up a PR early and add a WIP label. This lets my teammates take a look at the early direction of whatever I&#x27;m doing and I can make changes as necessary. This is a small but really impactful feature!

It’d be nice to have some way to configure exactly how the “draft pull request” works, because there are a couple cases where I think this could be improved:<p>* Notifying the maintainers might be useful in some cases. Often, I will file a WIP pull request to get preliminary review by a maintainer so that I know I’m going in the right direction.<p>* Being able to convert a draft pull request into a full one: Useful if the original author has stopped responding and you’d like to merge in their changes (after tweaking them, etc.)

&gt; <i>Also, if you have a CODEOWNERS file in your repository, a draft pull request will suppress notifications to those reviewers until it is marked as ready for review.</i><p>I&#x27;m not sure. When I send a PR marked with PR I usually want to know the opinion of the maintainer&#x2F;owner to know if it is going in the right direction and if it worth finishing.

I love this! I draft pull requests as an ad-hoc branch management scheme at work with a [WIP] prefix, and reviewers are notified when I make a change (small team so not too spammy). When it&#x27;s ready I update the summary and remove [WIP]. There might be a better way to do it (and I&#x27;d love to hear suggestions), but this is how I do it right now.

Looks great. Any idea when it&#x27;ll be added to GitHub Enterprise? This would be really helpful for my team.

I literally saw someone ask for this feature on Twitter last week. VSTS&#x2F;VSO&#x2F;DevOps&#x2F;? already has something similar.<p>This seems like the kind of feature that probably takes longer than a week to build and test, so I&#x27;m guessing it was already in the works.

I count at least 17,800 requests for this feature. <a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22WIP%22+inurl%3Apull+site%3Agithub.com" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=%22WIP%22+inurl%3Apull+site%...</a>

I can already see this coming in handy on our private team repo as I was not far off from revoking someone&#x27;s merge permissions for abusing PRs, this will be a nice little way to &#x27;jail&#x27; the offending party.

We have Github Team and I don&#x27;t see the feature. Still rolling out?

This will be helpful for the cultural clash that can sometimes happen when a new contributor tries to do something like this and the maintainers expect all PRs to be immediately merge-worthy.

Why? Aren&#x27;t all merge requests a WIP until they are merged?

Is there a way to convert a regular PR to a draft PR?

Hey niiiice, opening PRs early is definitely the way I work. This will definitely help with PR grooming :)

This is nice. I&#x27;ve always used the WIP tag but this is cleaner since it blocks merging.

I could be wrong, but I feel this actually enables the wrong kind of behavior we should expect from developers. We want fast, continuously integrated code that is merged early. Usually that means using feature toggles so that we can see compilation issues without the code being active by default.<p>This feature signals &quot;yeah it&#x27;s OK to take your time and not merge stuff incrementally - here&#x27;s a feature just for that since it&#x27;s such an important part of your workflow&quot;. Yes, people have been doing it anyway but at least it felt a bit like a hack, like it&#x27;s not supposed to work that way.<p>Am I crazy, or is this pushing back progress made in CI coding practices?