More word and line revisions to Create docset

Revise words, lines, and paragraphs to bring them closer to GitLab
tone and style. One major change in this commit swaps a two-column
table for an unordered list for ease of editing.

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
-request thread crosslinking the new commit and the existing merge request.
+When you cherry-pick a merge commit, GitLab displays a system note to the related merge
+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
-first parent. If you want to use a different mainline then you need to do that
+When cherry-picking merge commits, the mainline is always the
+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

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
-there are situations where Git will require your assistance to resolve the
+Git can merge changes between branches in most cases, but
+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
-resolved. Conflicts can be resolved locally, or in many cases within GitLab
+GitLab prevents merge requests from being merged until all conflicts are
+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
-commit to be reviewed and tested before the changes are merged, preventing
+is not automatically merged into the target branch. The merge
+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 this will show a list of files with conflicts, with conflict sections
+Clicking **Resolve Conflicts** displays 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
-can be resolved. This will perform a merge of the target branch of the merge
-request into the source branch, resolving the conflicts using the options
+After all conflicts have been marked as using 'ours' or 'theirs', the conflict
+can be resolved. Resolving conflicts merges the target branch of the merge
+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.
-
-The merge conflict resolution editor allows for more complex merge conflicts,
-which require the user to manually modify a file in order to resolve a conflict,
-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.
+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
+conflicts in the GitLab interface. Click **Edit inline** to open the editor.
+After you're sure about your changes, click **Commit to source branch**.
 
 ![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
-criteria, the conflicts for that merge request cannot be resolved in the UI.
+If any file in your merge request containing conflicts can't meet all of these
+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
-file2`; on branch `b`, doing `git mv file1 file3`. Instead, both files will be
-present in the branch after the merge request is merged.
+example, this does not create a conflict:
+
+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
 

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
-being merged, and it will stay disabled until the "Draft" flag has been removed.
+it as a **Draft**. This disables the **Merge** button, preventing it from
+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"
-(to include) or "No" (to exclude).
+WIP merge requests. Add a **WIP** filter in the search box, and choose **Yes**
+to include, or **No** to exclude.
 
 ![Filter WIP MRs](img/filter_wip_merge_requests.png)