Addressing issues flagged by Vale

doc/administration/auth/oidc.md

@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 GitLab can use [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) as an OmniAuth provider.
 
 To enable the OpenID Connect OmniAuth provider, you must register your application with an OpenID Connect provider.
-The OpenID Connect will provide you with a client details and secret for you to use.
+The OpenID Connect provides you with a client's details and secret for you to use.
 
 1. On your GitLab server, open the configuration file.
 
@@ -86,21 +86,21 @@ The OpenID Connect will provide you with a client details and secret for you to
    and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).
 
 1. For the configuration above, change the values for the provider to match your OpenID Connect client setup. Use the following as a guide:
-   - `<your_oidc_label>` is the label that will be displayed on the login page.
-   - `<custom_provider_icon>` (optional) is the icon that will be displayed on the login page. Icons for the major social login platforms are built-in into GitLab,
+   - `<your_oidc_label>` is the label that appears on the login page.
+   - `<custom_provider_icon>` (optional) is the icon that appears on the login page. Icons for the major social login platforms are built-in into GitLab,
      but can be overridden by specifying this parameter. Both local paths and absolute URLs are accepted.
    - `<your_oidc_url>` (optional) is the URL that points to the OpenID Connect provider. For example, `https://example.com/auth/realms/your-realm`.
      If this value is not provided, the URL is constructed from the `client_options` in the following format: `<client_options.scheme>://<client_options.host>:<client_options.port>`.
-   - If `discovery` is set to `true`, the OpenID Connect provider will try to auto discover the client options using `<your_oidc_url>/.well-known/openid-configuration`. Defaults to `false`.
+   - If `discovery` is set to `true`, the OpenID Connect provider attempts to auto discover the client options using `<your_oidc_url>/.well-known/openid-configuration`. Defaults to `false`.
    - `client_auth_method` (optional) specifies the method used for authenticating the client with the OpenID Connect provider.
      - Supported values are:
        - `basic` - HTTP Basic Authentication
        - `jwt_bearer` - JWT based authentication (private key and client secret signing)
        - `mtls` - Mutual TLS or X.509 certificate validation
-       - Any other value will POST the client ID and secret in the request body
+       - Any other value POSTs the client ID and secret in the request body
      - If not specified, defaults to `basic`.
-   - `<uid_field>` (optional) is the field name from the `user_info.raw_attributes` details that will be used as `uid` value. For example, `preferred_username`.
-     If this value is not provided or the field with the configured value is missing from the `user_info.raw_attributes` details, the `uid` will use the `sub` field.
+   - `<uid_field>` (optional) is the field name from the `user_info.raw_attributes` that defines the value for `uid`. For example, `preferred_username`.
+     If this value is not provided or the field with the configured value is missing from the `user_info.raw_attributes` details, the `uid` uses the `sub` field.
    - `send_scope_to_token_endpoint` is `true` by default. In other words, the `scope` parameter is normally included in requests to the token endpoint.
      However, if your OpenID Connect provider does not accept the `scope` parameter in such requests, set this to `false`.
    - `client_options` are the OpenID Connect client-specific options. Specifically:
@@ -119,9 +119,9 @@ The OpenID Connect will provide you with a client details and secret for you to
    for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
 On the sign in page, there should now be an OpenID Connect icon below the regular sign in form.
-Click the icon to begin the authentication process. The OpenID Connect provider will ask the user to
+Click the icon to begin the authentication process. The OpenID Connect provider asks the user to
 sign in and authorize the GitLab application (if confirmation required by the client). If everything goes well, the user
-will be redirected to GitLab and will be signed in.
+is redirected to GitLab and signed in.
 
 ## Example configurations
 

doc/user/project/import/svn.md

@@ -38,15 +38,15 @@ directly in a file system level.
    follow [this article](http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html).
 1. Download SubGit from <https://subgit.com/download>.
 1. Unpack the downloaded SubGit zip archive to the `/opt` directory. The `subgit`
-   command will be available at `/opt/subgit-VERSION/bin/subgit`.
+   command is available at `/opt/subgit-VERSION/bin/subgit`.
 
 ### SubGit configuration
 
 The first step to mirror you SVN repository in GitLab is to create a new empty
-project which will be used as a mirror. For Omnibus installations the path to
-the repository will be located at
+project that is used as a mirror. For Omnibus installations the path to
+the repository is 
 `/var/opt/gitlab/git-data/repositories/USER/REPO.git` by default. For
-installations from source, the default repository directory will be
+installations from source, the default repository directory is 
 `/home/git/repositories/USER/REPO.git`. For convenience, assign this path to a
 variable:
 
@@ -54,7 +54,7 @@ variable:
 GIT_REPO_PATH=/var/opt/gitlab/git-data/repositories/USER/REPOS.git
 ```
 
-SubGit will keep this repository in sync with a remote SVN project. For
+SubGit keeps this repository in sync with a remote SVN project. For
 convenience, assign your remote SVN project URL to a variable:
 
 ```shell
@@ -89,9 +89,9 @@ initial translation of existing SVN revisions into the Git repository:
 subgit install $GIT_REPO_PATH
 ```
 
-After the initial translation is completed, the Git repository and the SVN
-project will be kept in sync by `subgit` - new Git commits will be translated to
-SVN revisions and new SVN revisions will be translated to Git commits. Mirror
+After the initial translation is completed, `subgit` keeps the Git repository and the SVN
+project sync - new Git commits are translated to
+SVN revisions and new SVN revisions are translated to Git commits. Mirror
 works transparently and does not require any special commands.
 
 If you would prefer to perform one-time cut over migration with `subgit`, use
@@ -134,12 +134,12 @@ sudo apt-get install git-core git-svn ruby
 ```
 
 Optionally, prepare an authors file so `svn2git` can map SVN authors to Git authors.
-If you choose not to create the authors file then commits will not be attributed
+If you choose not to create the authors file then commits are not attributed
 to the correct GitLab user. Some users may not consider this a big issue while
-others will want to ensure they complete this step. If you choose to map authors
-you will be required to map every author that is present on changes in the SVN
-repository. If you don't, the conversion will fail and you will have to update
-the author file accordingly. The following command will search through the
+others want to ensure they complete this step. If you choose to map authors,
+you must map every author present on changes in the SVN
+repository. If you don't, the conversion fails and you have to update
+the author file accordingly. The following command searches through the
 repository and output a list of authors.
 
 ```shell
@@ -159,7 +159,7 @@ not nested) the conversion is simple. For a non-standard repository see
 [svn2git documentation](https://github.com/nirvdrum/svn2git). The following
 command will checkout the repository and do the conversion in the current
 working directory. Be sure to create a new directory for each repository before
-running the `svn2git` command. The conversion process will take some time.
+running the `svn2git` command. The conversion process takes some time.
 
 ```shell
 svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
@@ -167,13 +167,13 @@ svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
 
 If your SVN repository requires a username and password add the
 `--username <username>` and `--password <password>` flags to the above command.
-`svn2git` also supports excluding certain file paths, branches, tags, etc. See
+`svn2git` also supports excluding certain file paths, branches, tags, and so on. See
 [svn2git documentation](https://github.com/nirvdrum/svn2git) or run
 `svn2git --help` for full documentation on all of the available options.
 
-Create a new GitLab project, where you will eventually push your converted code.
+Create a new GitLab project, into which you push your converted code.
 Copy the SSH or HTTP(S) repository URL from the project page. Add the GitLab
-repository as a Git remote and push all the changes. This will push all commits,
+repository as a Git remote and push all the changes. This pushes all commits,
 branches and tags.
 
 ```shell