Yet more Create word / line revisions

Continuing to clean up the Create docset for tone and phrasing.

doc/administration/merge_request_diffs.md

@@ -225,8 +225,8 @@ of some merge request diffs when [external diffs in object storage](#object-stor
 were enabled. This mainly affected imported merge requests, and was resolved
 with [this merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31005).
 
-If you are using object storage, have never used on-disk storage for external
-diffs, the "changes" tab for some merge requests fails to load with a 500 error,
+If you are using object storage, or have never used on-disk storage for external
+diffs, the **Changes** tab for some merge requests fails to load with a 500 error,
 and the exception for that error is of this form:
 
 ```plain

doc/administration/static_objects_external_storage.md

@@ -9,8 +9,8 @@ type: reference
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31025) in GitLab 12.3.
 
-GitLab can be configured to serve repository static objects (for example, archives or raw blobs) from an external
-storage, such as a Content Delivery Network (CDN).
+You can configure GitLab to serve repository static objects, like archives or raw blobs,
+from an external storage, such as a Content Delivery Network (CDN).
 
 ## Configuring
 
@@ -19,19 +19,22 @@ To configure external storage for static objects:
 1. Navigate to **Admin Area > Settings > Repository**.
 1. Expand the **Repository static objects** section.
 1. Enter the base URL and an arbitrary token. When you [set up external storage](#set-up-external-storage),
-you'll use a script that uses these values as `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
+   use a script that sets these values as `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
 
 The token is required to distinguish requests coming from the external storage, so users don't
-circumvent the external storage and go for the application directly. The token is expected to be
-set in the `X-Gitlab-External-Storage-Token` header in requests originating from the external
-storage.
+circumvent the external storage and access the application directly. GitLab expects
+this token to be set in the `X-Gitlab-External-Storage-Token` header in requests
+originating from the external storage.
 
 ## Serving private static objects
 
-GitLab will append a user-specific token for static object URLs that belong to private projects,
-so an external storage can be authenticated on behalf of the user. When processing requests originating
-from the external storage, GitLab will look for the token in the `token` query parameter or in
-the `X-Gitlab-Static-Object-Token` header to check the user's ability to access the requested object.
+GitLab appends a user-specific token for static object URLs belonging to private projects,
+so an external storage can be authenticated on the user's behalf. When processing requests originating
+from the external storage, GitLab checks the following places to confirm the user may
+access the requested object:
+
+- The `token` query parameter.
+- The `X-Gitlab-Static-Object-Token` header.
 
 ## Requests flow example
 
@@ -66,8 +69,8 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr
 1. In the following script, set the following values for the first two constants:
 
    - `ORIGIN_HOSTNAME`: the hostname of your GitLab installation.
-   - `STORAGE_TOKEN`: any arbitrary secure token (e.g. you can get one by running
-     `pwgen -cn1 64` on a UNIX machine). Save this token for the admin panel, as
+   - `STORAGE_TOKEN`: any arbitrary secure token. You can get a token by running
+     `pwgen -cn1 64` on a UNIX machine. Save this token for the admin panel, as
      described in the [configuring](#configuring) section.
 
      ```javascript

doc/api/project_snippets.md

@@ -225,8 +225,8 @@ Parameters:
 
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
 - `snippet_id` (required) - The ID of a project's snippet
-- `ref` (required) - The name of a branch, tag or commit e.g. master
-- `file_path` (required) - The URL-encoded path to the file, e.g. snippet%2Erb
+- `ref` (required) - The name of a branch, tag or commit, such as `master`
+- `file_path` (required) - The URL-encoded path to the file, such as `snippet%2Erb`
 
 Example request:
 
@@ -239,7 +239,7 @@ curl "https://gitlab.com/api/v4/projects/1/snippets/2/files/master/snippet%2Erb/
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/29508) in GitLab 9.4.
 
-Available only for admins.
+Available only for users with Administrator [permissions](../user/permissions.md).
 
 ```plaintext
 GET /projects/:id/snippets/:snippet_id/user_agent_detail

doc/raketasks/migrate_snippets.md

@@ -4,25 +4,24 @@ group: Editor
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Migration to Versioned Snippets **(CORE ONLY)**
+# Migration to versioned snippets **(CORE ONLY)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215861) in GitLab 13.0.
 
 In GitLab 13.0, [GitLab Snippets are backed by Git repositories](../user/snippets.md#versioned-snippets).
-This means that the snippet content will be stored in the repository
-and users can update it directly through Git.
+Snippet content is stored in the repository, and users can update it directly through Git.
 
-Nevertheless, existing GitLab Snippets have to be migrated to this new functionality.
-For each snippet, a new repository is created and the snippet content is committed
-to the repository inside a file whose name is the filename used in the snippet
-as well.
+Nevertheless, existing GitLab Snippets must be migrated to this new feature.
+For each snippet:
 
-GitLab performs this migration through a [Background Migration](../development/background_migrations.md)
-automatically when the GitLab instance is upgrade to 13.0 or a higher version.
-However, if the migration fails for any of the snippets, they still need
-to be migrated individually.
+- A new repository is created.
+- A file is created in the repository, using the snippet filename.
+- The snippet is committed to the repository.
 
-The following Rake tasks will help with that process.
+GitLab performs this migration through a [Background Migration](../development/background_migrations.md)
+when the GitLab instance is upgraded to 13.0 or a higher version.
+However, if the migration fails for any of the snippets, they must be migrated individually.
+The following Rake tasks help with that process.
 
 ## Migrate specific snippets to Git
 

doc/user/project/repository/file_finder.md

@@ -17,8 +17,8 @@ project.
 
 ![Find file button](img/file_finder_find_button_v12_10.png)
 
-For those who prefer to keep their fingers on the keyboard, there is a
-[shortcut button](../../shortcuts.md) as well, which you can invoke from _anywhere_
+If you prefer to keep their fingers on the keyboard, use the
+[shortcut button](../../shortcuts.md), which you can invoke from anywhere
 in a project.
 
 Press `t` to launch the File search function when in **Issues**,