docs: Update WIP PR convention to GitHub draft PRs.

Since GitHub supports draft PRs, our [WIP] convention is obsolete.

Signed-off-by: Anders Kaseorg <anders@zulip.com>

CONTRIBUTING.md

@@ -211,13 +211,14 @@ and follow up with next steps.
 It's OK if your first issue takes you a while; that's normal! You'll be
 able to work a lot faster as you build experience.
 
-If it helps your workflow, you can submit a work-in-progress pull
-request before your work is ready for review. Simply prefix the title
-of work in progress pull requests with `[WIP]`, and then remove the
-prefix when you think it's time for someone else to review your work.
+If it helps your workflow, you can submit your pull request marked as
+a [draft][github-help-draft-pr] while you're still working on it, and
+then mark it ready when you think it's time for someone else to review
+your work.
 
 [git-guide]: https://zulip.readthedocs.io/en/latest/git/
 [git-guide-make-pr]: https://zulip.readthedocs.io/en/latest/git/pull-requests.html
+[github-help-draft-pr]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests
 
 ### Stages of a pull request
 

docs/git/overview.md

@@ -9,8 +9,9 @@ with these details in mind:
   [zulip/zulip][github-zulip-zulip] (or the appropriate
   [repository][github-zulip], if you are working on something else besides
   Zulip server) to your own account and then create feature/issue branches.
-  When you're ready to get feedback, submit a work-in-progress (WIP) pull
-  request. _We encourage you to submit WIP pull requests early and often._
+  When you're ready to get feedback, submit a [draft][github-help-draft-pr]
+  pull request. _We encourage you to submit draft pull requests early and
+  often._
 
 - We use a **[rebase][gitbook-rebase]-oriented workflow.** We do not use merge
   commits. This means you should use `git fetch` followed by `git rebase`
@@ -54,6 +55,7 @@ The following sections will help you be awesome with Zulip and Git/GitHub in a
 rebased-based workflow. Read through it if you're new to Git, to a rebase-based
 Git workflow, or if you'd like a Git refresher.
 
+[github-help-draft-pr]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests
 [gitbook-rebase]: https://git-scm.com/book/en/v2/Git-Branching-Rebasing
 [github-rebase-pr]: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
 [github-zulip]: https://github.com/zulip/

docs/git/pull-requests.md

@@ -13,13 +13,12 @@ might also find GitHub's article
 [about pull requests][github-help-about-pr] helpful. That all said,
 the tutorial below will walk you through the process.
 
-## Work in progress pull requests
+## Draft pull requests
 
-In the Zulip project, we encourage submitting work-in-progress pull
-requests early and often. This allows you to share your code to make
-it easier to get feedback and help with your changes. Prefix the
-titles of work-in-progress pull requests with **[WIP]**, which in our
-project means that you don't think your pull request is ready to be
+In the Zulip project, we encourage submitting [draft pull
+requests][github-help-draft-pr] early and often. This allows you to
+share your code to make it easier to get feedback and help with your
+changes, even if you don't think your pull request is ready to be
 merged (e.g. it might not work or pass tests). This sets expectations
 correctly for any feedback from other developers, and prevents your
 work from being merged before you're confident in it.
@@ -121,8 +120,9 @@ You'll see the _Open a pull request_ page:
 
 ![images-create-pr]
 
-Provide a **title** and first comment for your pull request. Remember to prefix
-your pull request title with [WIP] if it is a [work-in-progress][wip-prs].
+Provide a **title** and first comment for your pull request. Remember to mark
+your pull request as a [draft][github-help-draft-pr] if it is a
+work-in-progress.
 
 If your pull request has an effect on the visuals of a component, you might want
 to include a screenshot of this change or a GIF of the interaction in your first
@@ -157,8 +157,8 @@ for another review.
 [edx-howto-rebase-pr]: https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request
 [github-help-about-pr]: https://help.github.com/en/articles/about-pull-requests
 [github-help-create-pr-fork]: https://help.github.com/en/articles/creating-a-pull-request-from-a-fork
+[github-help-draft-pr]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests
 [images-create-pr]: ../images/zulip-open-pr.png
 [keep-up-to-date]: using.md#keep-your-fork-up-to-date
 [self-push-commits]: using.md#push-your-commits-to-github
 [screenshots-gifs]: ../tutorials/screenshot-and-gif-software.md
-[wip-prs]: #work-in-progress-pull-requests

templates/zerver/api/incoming-webhooks-walkthrough.md

@@ -483,8 +483,8 @@ request:
 
 If you would like feedback on your integration as you go, feel free to post a
 message on the [public Zulip instance](https://chat.zulip.org/#narrow/stream/bots).
-You can also create a [`[WIP]` pull request](
-https://zulip.readthedocs.io/en/latest/overview/contributing.html#working-on-an-issue) while you
+You can also create a [draft pull request](
+https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests) while you
 are still working on your integration. See the
 [Git guide](https://zulip.readthedocs.io/en/latest/git/pull-requests.html#create-a-pull-request)
 for more on Zulip's pull request process.

templates/zerver/development-community.md

@@ -59,7 +59,7 @@ feedback.
 - When asking for help, provide the details needed for others to help
   you. For example, include the **full traceback** in a [code
   block](/help/code-blocks) (not a screenshot), a link to the code or
-  a WIP PR you’re having trouble debugging, etc.
+  a draft PR you’re having trouble debugging, etc.
 - Ask questions on streams rather than PMing core contributors. You’ll
   get answers faster since other people can help, and it makes it
   possible for others to benefit from the discussion.