Deprecate WIP prefix in favor of Draft for MRs

Rename work_in_progress_merge_requests.md to draft_merge_requests.md
and fix the links

doc/README.md

@@ -200,7 +200,7 @@ The following documentation relates to the DevOps **Create** stage:
 | [Cherry-picking](user/project/merge_requests/cherry_pick_changes.md)                                                                        | Use GitLab for cherry-picking changes.                                                                                                |
 | [Merge request thread resolution](user/discussions/index.md#moving-a-single-thread-to-a-new-issue)                                          | Resolve threads, move threads in a merge request to an issue, and only allow merge requests to be merged if all threads are resolved. |
 | [Merge requests](user/project/merge_requests/index.md)                                                                                      | Merge request management.                                                                                                             |
-| [Work In Progress "WIP" merge requests](user/project/merge_requests/work_in_progress_merge_requests.md)                                     | Prevent merges of work-in-progress merge requests.                                                                                    |
+| [**Draft** merge requests](user/project/merge_requests/work_in_progress_merge_requests.md)                                                      | Prevent merges of draft merge requests.                                                                                               |
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#overview">

doc/api/merge_requests.md

@@ -1303,7 +1303,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
 
 Merge changes submitted with MR using this API.
 
-If merge request is unable to be accepted (ie: Work in Progress, Closed, Pipeline Pending Completion, or Failed while requiring Success) - you'll get a `405` and the error message 'Method Not Allowed'
+If merge request is unable to be accepted (ie: Draft, Closed, Pipeline Pending Completion, or Failed while requiring Success) - you'll get a `405` and the error message 'Method Not Allowed'
 
 If it has some conflicts and can not be merged - you'll get a `406` and the error message 'Branch cannot be merged'
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -30,8 +30,7 @@ can still be successfully merged into the target.
 When the merge request can't be merged, the pipeline runs against the source branch only. For example, when:
 
 - The target branch has changes that conflict with the changes in the source branch.
-- The merge request is a
-  [work in progress](../../../user/project/merge_requests/work_in_progress_merge_requests.md).
+- The merge request is a [**Draft** merge request](../../../user/project/merge_requests/work_in_progress_merge_requests.md).
 
 In these cases, the pipeline runs as a [pipeline for merge requests](../index.md)
 and is labeled as `detached`. If these cases no longer exist, new pipelines will

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -146,7 +146,7 @@ is recreated and all pipelines restart.
 
 ### Merge request dropped from the merge train immediately
 
-If a merge request is not mergeable (for example, it's WIP, there is a merge
+If a merge request is not mergeable (for example, it's a draft merge request, there is a merge
 conflict, etc.), your merge request will be dropped from the merge train automatically.
 
 In these cases, the reason for dropping the merge request is in the **system notes**.

doc/development/fe_guide/development_process.md

@@ -73,8 +73,8 @@ With the purpose of being [respectful of others' time](https://about.gitlab.com/
 - Before assigning to a maintainer, assign to a reviewer.
 - If you assigned a merge request or pinged someone directly, be patient because we work in different timezones and asynchronously. Unless the merge request is urgent (like fixing a broken master), please don't DM or reassign the merge request before waiting for a 24-hour window.
 - If you have a question regarding your merge request/issue, make it on the merge request/issue. When we DM each other, we no longer have a SSOT and [no one else is able to contribute](https://about.gitlab.com/handbook/values/#public-by-default).
-- When you have a big WIP merge request with many changes, you're advised to get the review started before adding/removing significant code. Make sure it is assigned well before the release cut-off, as the reviewer(s)/maintainer(s) would always prioritize reviewing finished MRs before WIP ones.
-- Make sure to remove the WIP title before the last round of review.
+- When you have a big **Draft** merge request with many changes, you're advised to get the review started before adding/removing significant code. Make sure it is assigned well before the release cut-off, as the reviewer(s)/maintainer(s) would always prioritize reviewing finished MRs before the **Draft** ones.
+- Make sure to remove the `Draft:` title before the last round of review.
 
 ### Share your work early
 

doc/topics/gitlab_flow.md

@@ -176,9 +176,9 @@ The name of a branch might be dictated by organizational standards.
 When you are done or want to discuss the code, open a merge request.
 A merge request is an online place to discuss the change and review the code.
 
-If you open the merge request but do not assign it to anyone, it is a "Work In Progress" merge request.
+If you open the merge request but do not assign it to anyone, it is a [draft merge request](../user/project/merge_requests/work_in_progress_merge_requests.md).
 These are used to discuss the proposed implementation but are not ready for inclusion in the `master` branch yet.
-Start the title of the merge request with `[WIP]` or `WIP:` to prevent it from being merged before it's ready.
+Start the title of the merge request with `[Draft]`, `Draft:` or `(Draft)` to prevent it from being merged before it's ready.
 
 When you think the code is ready, assign the merge request to a reviewer.
 The reviewer can merge the changes when they think the code is ready for inclusion in the `master` branch.

doc/university/training/end-user/README.md

@@ -159,7 +159,7 @@ git push origin squash_some_bugs
 - When you want feedback create a merge request
 - Target is the ‘default’ branch (usually master)
 - Assign or mention the person you would like to review
-- Add `WIP` to the title if it's a work in progress
+- Add `Draft:` to the title if it's a work in progress
 - When accepting, always delete the branch
 - Anyone can comment, not just the assignee
 - Push corrections to the same branch

doc/university/training/topics/merge_requests.md

@@ -7,7 +7,7 @@ comments: false
 - When you want feedback create a merge request
 - Target is the default branch (usually master)
 - Assign or mention the person you would like to review
-- Add 'WIP' to the title if it's a work in progress
+- Add `[Draft]` to the title if it's a work in progress
 - When accepting, always delete the branch
 - Anyone can comment, not just the assignee
 - Push corrections to the same branch

doc/university/training/user_training.md

@@ -186,7 +186,7 @@ git push origin squash_some_bugs
 - When you want feedback create a merge request.
 - Target is the ‘default’ branch (usually master).
 - Assign or mention the person you would like to review.
-- Add 'WIP' to the title if it's a work in progress.
+- Add `[Draft]` to the title if it's a work in progress.
 - When accepting, always delete the branch.
 - Anyone can comment, not just the assignee.
 - Push corrections to the same branch.

doc/user/project/issues/issue_data_and_actions.md

@@ -253,7 +253,7 @@ Also:
 
 ### Create Merge Request
 
-Create a new branch and [WIP merge request](../merge_requests/work_in_progress_merge_requests.md)
+Create a new branch and [**Draft** merge request](../merge_requests/work_in_progress_merge_requests.md)
 in one action. The branch will be named `issuenumber-title` by default, but you can
 choose any name, and GitLab will verify that it is not already in use. The merge request
 will automatically inherit the milestone and labels of the issue, and will be set to

doc/user/project/merge_requests/getting_started.md

@@ -57,7 +57,7 @@ request's page at the top-right side:
 - [Close issues automatically](#merge-requests-to-close-issues) when they are merged.
 - Enable the [delete source branch when merge request is accepted](#deleting-the-source-branch) option to keep your repository clean.
 - Enable the [squash commits when merge request is accepted](squash_and_merge.md) option to combine all the commits into one before merging, thus keep a clean commit history in your repository.
-- Set the merge request as a [Work In Progress (WIP)](work_in_progress_merge_requests.md) to avoid accidental merges before it is ready.
+- Set the merge request as a [**Draft**](work_in_progress_merge_requests.md) to avoid accidental merges before it is ready.
 
 Once you have created the merge request, you can also:
 

doc/user/project/merge_requests/merge_request_dependencies.md

@@ -38,15 +38,15 @@ the `awesome-project` merge request before the `awesome-lib` one would
 break the `master`branch.
 
 The `awesome-project` merge request could be [marked as
-WIP](work_in_progress_merge_requests.md),
-and the reason for the WIP stated included in the comments. However, this
+**Draft**](work_in_progress_merge_requests.md),
+and the reason for the draft stated included in the comments. However, this
 requires the state of the `awesome-lib` merge request to be manually
 tracked, and doesn't scale well if the `awesome-project` merge request
 depends on changes to **several** other projects.
 
 By making the `awesome-project` merge request depend on the
 `awesome-lib` merge request instead, this relationship is
-automatically tracked by GitLab, and the WIP state can be used to
+automatically tracked by GitLab, and the draft state can be used to
 communicate the readiness of the code in each individual merge request
 instead.
 

doc/user/project/merge_requests/work_in_progress_merge_requests.md

@@ -2,42 +2,46 @@
 type: reference, concepts
 ---
 
-# "Work In Progress" merge requests
+# Draft merge requests
 
 If a merge request is not yet ready to be merged, perhaps due to continued development
 or open threads, you can prevent it from being accepted before it's ready by flagging
-it as a **Work In Progress**. This will disable the "Merge" button, preventing it from
-being merged, and it will stay disabled until the "WIP" flag has been removed.
+it as a **Draft**. This will disable the "Merge" button, preventing it from
+being merged, and it will stay disabled until the "Draft" flag has been removed.
 
-![Blocked Accept Button](img/wip_blocked_accept_button.png)
+![Blocked Merge Button](img/draft_blocked_merge_button_v13_2.png)
 
-## Adding the "Work In Progress" flag to a merge request
+## Adding the "Draft" flag to a merge request
 
-There are several ways to flag a merge request as a Work In Progress:
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32692) in GitLab 13.2, Work-In-Progress (WIP) merge requests were renamed to **Draft**. Support for using **WIP** will be removed in GitLab 14.0.
 
-- Add `[WIP]` or `WIP:` to the start of the merge request's title. Clicking on
-  **Start the title with WIP:**, under the title box, when editing the merge request's
+There are several ways to flag a merge request as a Draft:
+
+- Add `[Draft]`, `Draft:` or `(Draft)` to the start of the merge request's title. Clicking on
+  **Start the title with Draft:**, under the title box, when editing the merge request's
   description will have the same effect.
+- **Deprecated** Add `[WIP]` or `WIP:` to the start of the merge request's title.
+  **WIP** still works but was deprecated in favor of **Draft**. It will be removed in the next major version (GitLab 14.0).
 - Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
   in a comment in the merge request. This is a toggle, and can be repeated
   to change the status back. Note that any other text in the comment will be discarded.
-- Add "wip" or "WIP" to the start of a commit message targeting the merge request's
+- Add `draft:` or `Draft:` to the start of a commit message targeting the merge request's
   source branch. This is not a toggle, and doing it again in another commit will have
   no effect.
 
-## Removing the "Work In Progress" flag from a merge request
+## Removing the "Draft" flag from a merge request
 
 Similar to above, when a Merge Request is ready to be merged, you can remove the
-"Work in Progress" flag in several ways:
+`Draft` flag in several ways:
 
-- Remove `[WIP]` or `WIP:` from the start of the merge request's title. Clicking on
-  **Remove the WIP: prefix from the title**, under the title box, when editing the merge
+- Remove `[Draft]`, `Draft:` or `(Draft)` from the start of the merge request's title. Clicking on
+  **Remove the Draft: prefix from the title**, under the title box, when editing the merge
   request's description, will have the same effect.
 - Add the `/wip` [quick action](../quick_actions.md#quick-actions-for-issues-merge-requests-and-epics)
   in a comment in the merge request. This is a toggle, and can be repeated
   to change the status back. Note that any other text in the comment will be discarded.
-- Click on the **Resolve WIP status** button near the bottom of the merge request description,
-  next to the "Merge" button (see [image above](#work-in-progress-merge-requests)).
+- Click on the **Resolve Draft status** button near the bottom of the merge request description,
+  next to the **Merge** button (see [image above](#draft-merge-requests)).
   Must have at least Developer level permissions on the project for the button to
   be visible.