Merge branch 'docs-aqualls-create2' into 'master'

More word and line revisions to Create docset See merge request gitlab-org/gitlab!52850

Merge branch 'docs-aqualls-create2' into 'master'
More word and line revisions to Create docset See merge request gitlab-org/gitlab!52850
4b6a75bf · Craig Norris · 889e4ede · 2e678d42 · 4b6a75bf · 4b6a75bf
Commit 4b6a75bf authored Jan 29, 2021 by Craig Norris
5 changed files
--- a/doc/user/project/merge_requests/cherry_pick_changes.md
+++ b/doc/user/project/merge_requests/cherry_pick_changes.md
@@ -13,12 +13,13 @@ with introducing a **Cherry-pick** button in merge requests and commit details.
 ## Cherry-picking a merge request
-After the merge request has been merged, a **Cherry-pick** button will be available
+After the merge request has been merged, a **Cherry-pick** button displays
 to cherry-pick the changes introduced by that merge request.
 ![Cherry-pick Merge Request](img/cherry_pick_changes_mr.png)
-After you click that button, a modal will appear showing a [branch filter search box](../repository/branches/index.md#branch-filter-search-box)
+After you click that button, a modal displays a
+[branch filter search box](../repository/branches/index.md#branch-filter-search-box)
 where you can choose to either:
 - Cherry-pick the changes directly into the selected branch.
@@ -28,12 +29,12 @@ where you can choose to either:
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2675) in GitLab 12.9.
-When you cherry-pick a merge commit, GitLab will output a system note to the related merge
+When you cherry-pick a merge commit, GitLab displays a system note to the related merge
-request thread crosslinking the new commit and the existing merge request.
+request thread. It crosslinks the new commit and the existing merge request.
 ![Cherry-pick tracking in Merge Request timeline](img/cherry_pick_mr_timeline_v12_9.png)
-Each deployment's [list of associated merge requests](../../../api/deployments.md#list-of-merge-requests-associated-with-a-deployment) will include cherry-picked merge commits.
+Each deployment's [list of associated merge requests](../../../api/deployments.md#list-of-merge-requests-associated-with-a-deployment) includes cherry-picked merge commits.
 NOTE:
 We only track cherry-pick executed from GitLab (both UI and API). Support for [tracking cherry-picked commits through the command line](https://gitlab.com/gitlab-org/gitlab/-/issues/202215) is planned for a future release.
@@ -44,15 +45,15 @@ You can cherry-pick a commit from the commit details page:
 ![Cherry-pick commit](img/cherry_pick_changes_commit.png)
-Similar to cherry-picking a merge request, you can opt to cherry-pick the changes
+Similar to cherry-picking a merge request, you can cherry-pick the changes
 directly into the target branch or create a new merge request to cherry-pick the
 changes.
-Please note that when cherry-picking merge commits, the mainline will always be the
+When cherry-picking merge commits, the mainline is always the
-first parent. If you want to use a different mainline then you need to do that
+first parent. If you want to use a different mainline, you need to do that
 from the command line.
-Here is a quick example to cherry-pick a merge commit using the second parent as the
+Here's a quick example to cherry-pick a merge commit using the second parent as the
 mainline:
 ```shell

--- a/doc/user/project/merge_requests/merge_request_approvals.md
+++ b/doc/user/project/merge_requests/merge_request_approvals.md
@@ -10,8 +10,8 @@ type: reference, concepts
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/580) in GitLab Enterprise Edition 7.2. Available in GitLab Core and higher tiers.
 > - Redesign [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1979) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8 and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/10685) in 12.0.
-Code review is an essential practice of every successful project, and giving your
+Code review is an essential practice of every successful project. Approving a
-approval once a merge request is in good shape is an important part of the review
+merge request is an important part of the review
 process, as it clearly communicates the ability to merge the change.
 ## Optional Approvals
@@ -19,8 +19,8 @@ process, as it clearly communicates the ability to merge the change.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27426) in GitLab 13.2.
 Any user with Developer or greater [permissions](../../permissions.md) can approve a merge request in GitLab Core and higher tiers.
-This provides a consistent mechanism for reviewers to approve merge requests, and makes it easy for
+This provides a consistent mechanism for reviewers to approve merge requests, and ensures
-maintainers to know when a change is ready to merge. Approvals in Core are optional and do
+maintainers know a change is ready to merge. Approvals in Core are optional, and do
 not prevent a merge request from being merged when there is no approval.
 ## Required Approvals **(STARTER)**
@@ -50,8 +50,9 @@ be merged, and optionally which users should do the approving. Approvals can be
 - [As project defaults](#adding--editing-a-default-approval-rule).
 - [Per merge request](#editing--overriding-approval-rules-per-merge-request).
-If no approval rules are defined, any user can approve a merge request, though the default
+If no approval rules are defined, any user can approve a merge request. However, the default
-minimum number of required approvers can still be set in the [project settings for merge request approvals](#merge-request-approvals-project-settings).
+minimum number of required approvers can still be set in the
+[project settings for merge request approvals](#merge-request-approvals-project-settings).
 You can opt to define one single rule to approve a merge request among the available rules
 or choose more than one with [multiple approval rules](#multiple-approval-rules).
@@ -81,20 +82,21 @@ A group of users can also be added as approvers. In the future, group approvers
 [restricted to only groups with share access to the project](https://gitlab.com/gitlab-org/gitlab/-/issues/2048).
 If a user is added as an individual approver and is also part of a group approver,
-then that user is just counted once. The merge request author, as well as users who have committed
+then that user is just counted once. The merge request author, and users who have committed
 to the merge request, do not count as eligible approvers,
 if [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests) (enabled by default)
 and [**Prevent committers approval**](#prevent-approval-of-merge-requests-by-their-committers) (disabled by default)
 are enabled on the project settings.
-When an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget,
+When an eligible approver comments on a merge request, it displays in the
-indicating who has engaged in the merge request review. Authors and reviewers can also easily identify who they should reach out
+**Commented by** column of the Approvals widget. It indicates who participated in
-to if they have any questions or inputs about the content of the merge request.
+the merge request review. Authors and reviewers can also identify who they should reach out
+to if they have any questions about the content of the merge request.
 ##### Implicit Approvers
 If the number of required approvals is greater than the number of assigned approvers,
-approvals from other users will count towards meeting the requirement. These would be
+approvals from other users counts towards meeting the requirement. These would be
 users with developer [permissions](../../permissions.md) or higher in the project who
 were not explicitly listed in the approval rules.
@@ -103,7 +105,7 @@ were not explicitly listed in the approval rules.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7933) in [GitLab Starter](https://about.gitlab.com/pricing/) 11.5.
 If you add [Code Owners](../code_owners.md) to your repository, the owners to the
-corresponding files will become eligible approvers, together with members with Developer
+corresponding files become eligible approvers, together with members with Developer
 or higher [permissions](../../permissions.md).
 To enable this merge request approval rule:
@@ -115,7 +117,7 @@ To enable this merge request approval rule:
 ![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_7.png)
 Once set, merge requests can only be merged once approved by the
-number of approvals you've set. GitLab will accept approvals from
+number of approvals you've set. GitLab accepts approvals from
 users with Developer or higher permissions, as well as by Code Owners,
 indistinguishably.
@@ -154,27 +156,27 @@ To add or edit the default merge request approval rule:
 1. Click **Add approval rule**, or **Edit**.
   - Add or change the **Rule name**.
   - Set the number of required approvals in **Approvals required**. The minimum value is `0`.
-   - (Optional) Search for users or groups that will be [eligible to approve](#eligible-approvers)
+   - (Optional) Search for users or groups that are [eligible to approve](#eligible-approvers)
     merge requests and click the **Add** button to add them as approvers. Before typing
-     in the search field, approvers will be suggested based on the previous authors of
+     in the search field, approvers are suggested based on the previous authors of
     the files being changed by the merge request.
   - (Optional) Click the **{remove}** **Remove** button next to a group or user to delete it from
     the rule.
 1. Click **Add approval rule** or **Update approval rule**.
 When [approval rule overrides](#prevent-overriding-default-approvals) are allowed,
-changes to these default rules will **not** be applied to existing merge
+changes to these default rules are not applied to existing merge
 requests, except for changes to the [target branch](#scoped-to-protected-branch) of
 the rule.
 When approval rule overrides are not allowed, all changes to these default rules
-will be applied to existing merge requests. Any approval rules that had previously been
+are applied to existing merge requests. Any approval rules that had previously been
 manually [overridden](#editing--overriding-approval-rules-per-merge-request) during a
-period when approval rule overrides where allowed, will not be modified.
+period when approval rule overrides where allowed, are not modified.
 NOTE:
 If a merge request targets a different project, such as from a fork to the upstream project,
-the default approval rules will be taken from the target (upstream) project, not the
+the default approval rules are taken from the target (upstream) project, not the
 source (fork).
 ##### Editing / overriding approval rules per merge request
@@ -193,8 +195,8 @@ the same steps as [Adding / editing a default approval rule](#adding--editing-a-
 #### Set up an optional approval rule
-MR approvals can be configured to be optional.
+MR approvals can be configured to be optional, which can help if you're working
-This can be useful if you're working on a team where approvals are appreciated, but not required.
+on a team where approvals are appreciated, but not required.
 To configure an approval to be optional, set the number of required approvals in **Approvals required** to `0`.
@@ -209,16 +211,16 @@ as well as multiple default approval rules per project.
 Adding or editing multiple default rules is identical to
 [adding or editing a single default approval rule](#adding--editing-a-default-approval-rule),
-except the **Add approval rule** button will be available to add more rules, even after
+except the **Add approval rule** button is available to add more rules, even after
 a rule is already defined.
 Similarly, editing or overriding multiple approval rules per merge request is identical
 to [editing or overriding approval rules per merge request](#editing--overriding-approval-rules-per-merge-request),
-except the **Add approval rule** button will be available to add more rules, even after
+except the **Add approval rule** button is available to add more rules, even after
 a rule is already defined.
-When an [eligible approver](#eligible-approvers) approves a merge request, it will
+When an [eligible approver](#eligible-approvers) approves a merge request, it
-reduce the number of approvals left for all rules that the approver belongs to.
+reduces the number of approvals left for all rules that the approver belongs to.
 ![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png)
@@ -267,7 +269,7 @@ The merge request author is not allowed to approve their own merge request if
 [**Prevent author approval**](#allowing-merge-request-authors-to-approve-their-own-merge-requests)
 is enabled in the project settings.
-Once the approval rules have been met, the merge request can be merged if there is nothing
+After the approval rules have been met, the merge request can be merged if there is nothing
 else blocking it. Note that the merge request could still be blocked by other conditions,
 such as merge conflicts, [pending discussions](../../discussions/index.md#only-allow-merge-requests-to-be-merged-if-all-threads-are-resolved),
 or a [failed CI/CD pipeline](merge_when_pipeline_succeeds.md).
@@ -289,7 +291,7 @@ To prevent that from happening:
 #### Resetting approvals on push
 You can force all approvals on a merge request to be removed when new commits are
-pushed to the source branch of the merge request. If disabled, approvals will persist
+pushed to the source branch of the merge request. If disabled, approvals persist
 even if there are changes added to the merge request. To enable this feature:
 1. Check the **Require new approvals when new commits are added to an MR.**
@@ -298,7 +300,7 @@ even if there are changes added to the merge request. To enable this feature:
 NOTE:
 Approvals do not get reset when [rebasing a merge request](fast_forward_merge.md)
-from the UI. However, approvals will be reset if the target branch is changed.
+from the UI. However, approvals are reset if the target branch is changed.
 #### Allowing merge request authors to approve their own merge requests
@@ -330,7 +332,7 @@ enable this feature:
 NOTE:
 To require authentication when approving a merge request, you must enable
 **Password authentication enabled for web interface** under [sign-in restrictions](../../admin_area/settings/sign_in_restrictions.md#password-authentication-enabled).
-in the Admin area.
+in the Admin Area.
 You can force the approver to enter a password in order to authenticate before adding
 the approval. This enables an Electronic Signature for approvals such as the one defined

--- a/doc/user/project/merge_requests/resolve_conflicts.md
+++ b/doc/user/project/merge_requests/resolve_conflicts.md
@@ -10,13 +10,13 @@ type: reference, concepts
 Merge conflicts occur when two branches have different changes that cannot be
 merged automatically.
-Git is able to automatically merge changes between branches in most cases, but
+Git can merge changes between branches in most cases, but
-there are situations where Git will require your assistance to resolve the
+occasionally Git requires your assistance to resolve the
 conflicts manually. Typically, this is necessary when people change the same
 parts of the same files.
-GitLab will prevent merge requests from being merged until all conflicts are
+GitLab prevents merge requests from being merged until all conflicts are
-resolved. Conflicts can be resolved locally, or in many cases within GitLab
+resolved. Conflicts can be resolved locally, or in many cases in GitLab
 (see [conflicts available for resolution](#conflicts-available-for-resolution)
 for information on when this is available).
@@ -24,35 +24,30 @@ for information on when this is available).
 NOTE:
 GitLab resolves conflicts by creating a merge commit in the source branch that
-is not automatically merged into the target branch. This allows the merge
+is not automatically merged into the target branch. The merge
-commit to be reviewed and tested before the changes are merged, preventing
+commit can be reviewed and tested before the changes are merged. This prevents
 unintended changes entering the target branch without review or breaking the
 build.
 ## Resolve conflicts: interactive mode
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5479) in GitLab 8.11.
+Clicking **Resolve Conflicts** displays a list of files with conflicts, with conflict sections
-Clicking this will show a list of files with conflicts, with conflict sections
 highlighted:
 ![Conflict section](img/conflict_section.png)
-Once all conflicts have been marked as using 'ours' or 'theirs', the conflict
+After all conflicts have been marked as using 'ours' or 'theirs', the conflict
-can be resolved. This will perform a merge of the target branch of the merge
+can be resolved. Resolving conflicts merges the target branch of the merge
-request into the source branch, resolving the conflicts using the options
+request into the source branch, using the options
 chosen. If the source branch is `feature` and the target branch is `master`,
 this is similar to performing `git checkout feature; git merge master` locally.
 ## Resolve conflicts: inline editor
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6374) in GitLab 8.13.
+Some merge conflicts are more complex, requiring you to manually modify a file to
+resolve them. Use the merge conflict resolution editor to resolve complex
-The merge conflict resolution editor allows for more complex merge conflicts,
+conflicts in the GitLab interface. Click **Edit inline** to open the editor.
-which require the user to manually modify a file in order to resolve a conflict,
+After you're sure about your changes, click **Commit to source branch**.
-to be solved right form the GitLab interface. Use the **Edit inline** button
-to open the editor. Once you're sure about your changes, hit the
-**Commit to source branch** button.
 ![Merge conflict editor](img/merge_conflict_editor.png)
@@ -66,13 +61,16 @@ GitLab allows resolving conflicts in a file where all of the below are true:
 - The file, with conflict markers added, is not over 200 KB in size
 - The file exists under the same path in both branches
-If any file with conflicts in that merge request does not meet all of these
+If any file in your merge request containing conflicts can't meet all of these
-criteria, the conflicts for that merge request cannot be resolved in the UI.
+criteria, you can't resolve the merge conflict in the UI.
 Additionally, GitLab does not detect conflicts in renames away from a path. For
-example, this will not create a conflict: on branch `a`, doing `git mv file1
+example, this does not create a conflict:
-file2`; on branch `b`, doing `git mv file1 file3`. Instead, both files will be
-present in the branch after the merge request is merged.
+1. On branch `a`, doing `git mv file1 file2`
+1. On branch `b`, doing `git mv file1 file3`.
+Instead, both files are present in the branch after the merge request is merged.
 <!-- ## Troubleshooting

--- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
+++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
@@ -13,10 +13,10 @@ which is then reviewed, and accepted (or rejected).
 ## View project merge requests
-View all the merge requests within a project by navigating to **Project > Merge Requests**.
+View all the merge requests in a project by navigating to **Project > Merge Requests**.
-When you access your project's merge requests, GitLab will present them in a list,
+When you access your project's merge requests, GitLab displays them in a list.
-and you can use the tabs available to quickly filter by open and closed. You can also [search and filter the results](../../search/index.md#filtering-issue-and-merge-request-lists).
+Use the tabs to quickly filter by open and closed. You can also [search and filter the results](../../search/index.md#filtering-issue-and-merge-request-lists).
 ![Project merge requests list view](img/project_merge_requests_list_view_v13_5.png)
@@ -32,7 +32,7 @@ You can [search and filter the results](../../search/index.md#filtering-issue-an
 A merge commit is created for every merge, but the branch is only merged if
 a fast-forward merge is possible. This ensures that if the merge request build
-succeeded, the target branch build will also succeed after merging.
+succeeded, the target branch build also succeeds after the merge.
 Navigate to a project's settings, select the **Merge commit with semi-linear history**
 option under **Merge Requests: Merge method** and save your changes.
@@ -80,12 +80,15 @@ Click **Expand file** on any file to view the changes for that file.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/222790) in GitLab 13.2.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/229848) in GitLab 13.7.
-For larger merge requests it might sometimes be useful to review single files at a time. To enable,
+For larger merge requests, consider reviewing one file at a time. To enable this feature:
-from your avatar on the top-right navigation bar, click **Settings**, and go to **Preferences** on the left
-sidebar. Scroll down to the **Behavior** section and select **Show one file at a time on merge request's Changes tab**.
-Click **Save changes** to apply.
-From there, when reviewing merge requests' **Changes** tab, you will see only one file at a time. You can then click the buttons **Prev** and **Next** to view the other files changed.
+1. In the top right corner of the navigation bar, click your user avatar.
+1. Click **Settings**.
+1. In the left sidebar, go to **Preferences**.
+1. Scroll to the **Behavior** section and select **Show one file at a time on merge request's Changes tab**.
+1. Click **Save changes** to apply.
+After you enable this setting, GitLab displays only one file at a time in the **Changes** tab when you review merge requests. You can click **Prev** and **Next** to view other changed files.
 ![File-by-file diff navigation](img/file_by_file_v13_2.png)
@@ -104,10 +107,14 @@ browser's cookies or change this behavior again.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/18140) in GitLab 13.0.
-To seamlessly navigate among commits in a merge request, from the **Commits** tab, click one of
+To seamlessly navigate among commits in a merge request:
-the commits to open the single-commit view. From there, you can navigate among the commits
-by clicking the **Prev** and **Next** buttons on the top-right of the page or by using the
+1. Click the **Commits** tab.
-<kbd>X</kbd> and <kbd>C</kbd> keyboard shortcuts.
+1. Click a commit to open it in the single-commit view.
+1. Navigate through the commits by either:
+   - Clicking **Prev** and **Next** buttons on the top-right of the page.
+   - Using the <kbd>X</kbd> and <kbd>C</kbd> keyboard shortcuts.
 ![Merge requests commit navigation](img/commit_nav_v13_4.png)
@@ -120,7 +127,7 @@ to expand the entire file.
 ![Incrementally expand merge request diffs](img/incrementally_expand_merge_request_diffs_v12_2.png)
-[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/205401) in GitLab 13.1, when viewing a
+In GitLab [versions 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/205401), when viewing a
 merge request's **Changes** tab, if a certain file was only renamed, you can expand it to see the
 entire content by clicking **Show file contents**.
@@ -145,7 +152,7 @@ whitespace changes.
 > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-views). **(FREE SELF)**
 When reviewing a merge request with many files multiple times, it may be useful to the reviewer
-to focus on new changes and ignore the files that they have already reviewed and don't want to 
+to focus on new changes and ignore the files that they have already reviewed and don't want to
 see anymore unless they are changed again.
 To mark a file as viewed:
@@ -154,7 +161,7 @@ To mark a file as viewed:
 1. On the right-top of the file, locate the **Viewed** checkbox.
 1. Check it to mark the file as viewed.
-Once checked, the file will remain marked for that reviewer unless there are newly introduced 
+Once checked, the file remains marked for that reviewer unless there are newly introduced
 changes to its content or the checkbox is unchecked.
 ### Enable or disable file views **(FREE SELF)**
@@ -180,8 +187,9 @@ Feature.disable(:local_file_reviews)
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/13950) in GitLab 11.5.
-GitLab provides a way of leaving comments in any part of the file being changed
+In a merge request, you can leave comments in any part of the file being changed.
-in a Merge Request. To do so, click the **{comment}** **comment** icon in the gutter of the Merge Request diff UI to expand the diff lines and leave a comment, just as you would for a changed line.
+In the Merge Request Diff UI, click the **{comment}** **comment** icon in the gutter
+to expand the diff lines and leave a comment, just as you would for a changed line.
 ![Comment on any diff file line](img/comment-on-any-diff-line.png)
@@ -231,31 +239,30 @@ Feature.enable(:multiline_comments)
 ## Pipeline status in merge requests widgets
 If you've set up [GitLab CI/CD](../../../ci/README.md) in your project,
-you will be able to see:
+you can see:
 - Both pre-merge and post-merge pipelines and the environment information if any.
 - Which deployments are in progress.
-If there's an [environment](../../../ci/environments/index.md) and the application is
+If an application is successfully deployed to an
-successfully deployed to it, the deployed environment and the link to the
+[environment](../../../ci/environments/index.md), the deployed environment and the link to the
-Review App will be shown as well.
+Review App are both shown.
 NOTE:
-When the default branch (for example, `main`) is red due to a failed CI pipeline, the `merge` button
+When the pipeline fails in a merge request but it can still be merged,
-When the pipeline fails in a merge request but it can be merged nonetheless,
+the **Merge** button is colored red.
-the **Merge** button will be colored in red.
 ### Post-merge pipeline status
 When a merge request is merged, you can see the post-merge pipeline status of
 the branch the merge request was merged into. For example, when a merge request
-is merged into the master branch and then triggers a deployment to the staging
+is merged into the `master` branch and then triggers a deployment to the staging
 environment.
-Deployments that are ongoing will be shown, as well as the deploying/deployed state
+Ongoing deployments are shown, and the state (deploying or deployed)
 for environments. If it's the first time the branch is deployed, the link
-will return a `404` error until done. During the deployment, the stop button will
+returns a `404` error until done. During the deployment, the stop button is
-be disabled. If the pipeline fails to deploy, the deployment information will be hidden.
+disabled. If the pipeline fails to deploy, the deployment information is hidden.
 ![Merge request pipeline](img/merge_request_pipeline.png)
@@ -263,14 +270,15 @@ For more information, [read about pipelines](../../../ci/pipelines/index.md).
 ### Merge when pipeline succeeds (MWPS)
-Set a merge request that looks ready to merge to [merge automatically when CI pipeline succeeds](merge_when_pipeline_succeeds.md).
+Set a merge request that looks ready to merge to
+[merge automatically when CI pipeline succeeds](merge_when_pipeline_succeeds.md).
 ### Live preview with Review Apps
 If you configured [Review Apps](https://about.gitlab.com/stages-devops-lifecycle/review-apps/) for your project,
-you can preview the changes submitted to a feature-branch through a merge request
+you can preview the changes submitted to a feature branch through a merge request
-in a per-branch basis. No need to checkout the branch, install and preview locally;
+on a per-branch basis. You don't need to checkout the branch, install, and preview locally.
-all your changes will be available to preview by anyone with the Review Apps link.
+All your changes are available to preview by anyone with the Review Apps link.
 With GitLab [Route Maps](../../../ci/review_apps/index.md#route-maps) set, the
 merge request widget takes you directly to the pages changed, making it easier and
@@ -280,21 +288,26 @@ faster to preview proposed modifications.
 ## Associated features
-There is also a large number of features to associated to merge requests:
+These features are associated with merge requests:
-| Feature                                                                                                                                               | Description                                                                                                                                              |
+- [Bulk editing merge requests](../../project/bulk_editing.md):
-|-------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
+  Update the attributes of multiple merge requests simultaneously.
-| [Bulk editing merge requests](../../project/bulk_editing.md)                                                                                          | Update the attributes of multiple merge requests simultaneously.                                                                                         |
+- [Cherry-pick changes](cherry_pick_changes.md):
-| [Cherry-pick changes](cherry_pick_changes.md)                                                                                                         | Cherry-pick any commit in the UI by simply clicking the **Cherry-pick** button in a merged merge requests or a commit.                                   |
+  Cherry-pick any commit in the UI by clicking the **Cherry-pick** button in a merged merge requests or a commit.
-| [Fast-forward merge requests](fast_forward_merge.md)                                                                                                  | For a linear Git history and a way to accept merge requests without creating merge commits                                                               |
+- [Fast-forward merge requests](fast_forward_merge.md):
-| [Find the merge request that introduced a change](versions.md)                                                                                        | When viewing the commit details page, GitLab will link to the merge request(s) containing that commit.                                                   |
+  For a linear Git history and a way to accept merge requests without creating merge commits
-| [Merge requests versions](versions.md)                                                                                                                | Select and compare the different versions of merge request diffs                                                                                         |
+- [Find the merge request that introduced a change](versions.md):
-| [Resolve conflicts](resolve_conflicts.md)                                                                                                             | GitLab can provide the option to resolve certain merge request conflicts in the GitLab UI.                                                               |
+  When viewing the commit details page, GitLab links to the merge request(s) containing that commit.
-| [Revert changes](revert_changes.md)                                                                                                                   | Revert changes from any commit from within a merge request.                                                                                              |
+- [Merge requests versions](versions.md):
+  Select and compare the different versions of merge request diffs
+- [Resolve conflicts](resolve_conflicts.md):
+  GitLab can provide the option to resolve certain merge request conflicts in the GitLab UI.
+- [Revert changes](revert_changes.md):
+  Revert changes from any commit from a merge request.
 ## Troubleshooting
-Sometimes things don't go as expected in a merge request, here are some
+Sometimes things don't go as expected in a merge request. Here are some
 troubleshooting steps.
 ### Merge request cannot retrieve the pipeline status
@@ -304,7 +317,7 @@ This can occur if Sidekiq doesn't pick up the changes fast enough.
 #### Sidekiq
 Sidekiq didn't process the CI state change fast enough. Please wait a few
-seconds and the status will update automatically.
+seconds and the status should update automatically.
 #### Bug
@@ -320,12 +333,9 @@ Merge Request again.
 ## Tips
-Here are some tips that will help you be more efficient with merge requests in
+Here are some tips to help you be more efficient with merge requests in
 the command line.
-NOTE:
-This section might move in its own document in the future.
 ### Copy the branch name for local checkout
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23767) in GitLab 13.4.
@@ -334,7 +344,7 @@ The merge request sidebar contains the branch reference for the source branch
 used to contribute changes for this merge request.
 To copy the branch reference into your clipboard, click the **Copy branch name** button
-(**{copy-to-clipboard}**) in the right sidebar. You can then use it to checkout the branch locally
+(**{copy-to-clipboard}**) in the right sidebar. Use it to checkout the branch locally
 via command line by running `git checkout <branch-name>`.
 ### Checkout merge requests locally through the `head` ref
@@ -343,7 +353,7 @@ A merge request contains all the history from a repository, plus the additional
 commits added to the branch associated with the merge request. Here's a few
 ways to checkout a merge request locally.
-Please note that you can checkout a merge request locally even if the source
+You can checkout a merge request locally even if the source
 project is a fork (even a private fork) of the target project.
 This relies on the merge request `head` ref (`refs/merge-requests/:iid/head`)
@@ -352,10 +362,10 @@ request via its ID instead of its branch.
 [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223156) in GitLab
 13.4, 14 days after a merge request gets closed or merged, the merge request
-`head` ref will be deleted. This means that the merge request will not be available
+`head` ref is deleted. This means that the merge request is not available
 for local checkout via the merge request `head` ref anymore. The merge request
-can still be re-opened. Also, as long as the merge request's branch
+can still be re-opened. If the merge request's branch
-exists, you can still check out the branch as it won't be affected.
+exists, you can still check out the branch, as it isn't affected.
 #### Checkout locally by adding a Git alias
@@ -374,7 +384,7 @@ from the `origin` remote, do:
 git mr origin 5
 ```
-This will fetch the merge request into a local `mr-origin-5` branch and check
+This fetches the merge request into a local `mr-origin-5` branch and check
 it out.
 #### Checkout locally by modifying `.git/config` for a given repository

--- a/doc/user/project/merge_requests/work_in_progress_merge_requests.md
+++ b/doc/user/project/merge_requests/work_in_progress_merge_requests.md
@@ -9,8 +9,8 @@ type: reference, concepts
 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 **Draft**. This will disable the "Merge" button, preventing it from
+it as a **Draft**. This disables the **Merge** button, preventing it from
-being merged, and it will stay disabled until the "Draft" flag has been removed.
+being merged. It stays disabled until the **Draft** flag has been removed.
 ![Blocked Merge Button](img/draft_blocked_merge_button_v13_2.png)
@@ -22,7 +22,7 @@ To run pipelines for merged results, you must [remove the draft status](#removin
 ## Adding the "Draft" flag to a merge request
-> - [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.
+> - [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** is scheduled for removal in GitLab 14.0.
 > - **Mark as draft** and **Mark as ready** buttons [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227421) in GitLab 13.5.
 There are several ways to flag a merge request as a Draft:
@@ -30,15 +30,15 @@ There are several ways to flag a merge request as a Draft:
 - Click the **Mark as draft** button on the top-right corner of the merge request's page.
 - 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.
+  description has 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).
+  **WIP** still works but was deprecated in favor of **Draft**. It is scheduled for removal in the next major version (GitLab 14.0).
 - Add the `/draft` (or `/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.
+  to change the status back. Note that any other text in the comment is discarded.
 - Add `draft:`, `Draft:`, `fixup!`, or `Fixup!` to the beginning 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.
+  commit has no effect.
 ## Removing the "Draft" flag from a merge request
@@ -48,10 +48,10 @@ Similar to above, when a Merge Request is ready to be merged, you can remove the
 - Click the **Mark as ready** button on the top-right corner of the merge request's page.
 - 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.
+  request's description, has the same effect.
 - Add the `/draft` (or `/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.
+  to change the status back. Note that any other text in the comment is discarded.
 - 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
@@ -60,8 +60,8 @@ Similar to above, when a Merge Request is ready to be merged, you can remove the
 ## Including/excluding WIP merge requests when searching
 When viewing/searching the merge requests list, you can choose to include or exclude
-WIP merge requests by adding a "WIP" filter in the search box, and choosing "Yes"
+WIP merge requests. Add a **WIP** filter in the search box, and choose **Yes**
-(to include) or "No" (to exclude).
+to include, or **No** to exclude.
 ![Filter WIP MRs](img/filter_wip_merge_requests.png)