GitHub has introduced draft pull requests to handle work-in-progress scenarios where you might want to open a PR or start a conversation with your teammates before your code is ready to be reviewed.
When you create a new PR, you can now choose whether to create a normal pull request or a draft pull request using a drop-down menu. A draft pull request is clearly distinguishable from a normal one and cannot be merged. You can freely modify a draft PR by adding comments or requiring other team members to have a look at it and provide their feedback. Importantly, draft PRs will not notify all CODEOWNERS for every modification that is made to them. This is a key feature of draft PRs to make them practically useful, otherwise all of them would be notified for changes that do not necessarily require their attention.
When you are done with a draft PR, you can easily set its state back to a normal PR by marking it as ready for review, or you can scrap it if it led to nowhere.
A discussion on Hacker News provides more background and rationale for this new feature. A number of different users stated they already used to create a draft pull request by adding "WIP" or "DO NOT MERGE" to PR names. This goes to show draft PRs are a way to formalize a somewhat common, though informal, practice.
These PRs serve to facilitate discussion, start knowledge sharing, and update other developers on my progress more clearly than a branch they might have to check more carefully. However I would definitely not want to merge one.
User tedivm points out draft pull requests are not to be seen as an alternative to feature branches for the development of new features. Thus, all current CI/CD good practices are not affected by draft PRs. Indeed, he suggests you still create a feature branch and keep committing to it and push to your repository frequently, but you can create a draft pull request at any point in time with two major goals: to show that work is being done on a specific feature and where; and/or to provide an easy way to check for the changes involved and to let people comment on the code itself as early as possible.
User gfosco specifically highlights the value of draft PRs when you contribute to some large and complex project, where you have no rights to create branches, so you work on your own fork. In such cases, asking other project members to check your fork/branch is not usually a practical way to get feedback. On the contrary, creating a draft PR would work seamlessly.
Other comments pointed out their preference for managing this kind of discussion through alternative means, such as a wiki, documentation, or a bug tracker.
GitHub draft PRs are not a "first", since GitLab already offered a similar feature called WIP merge request. Similarly, Gerrit, the original versioning system used for Android development, also used to provide the same concept of draft pull request.
