Remove future tense from Release docs

doc/administration/pages/index.md

@@ -38,20 +38,20 @@ which you can set it up:
 - Run the Pages daemon in the same server as GitLab, listening on a **secondary IP**.
 - Run the Pages daemon in a [separate server](#running-gitlab-pages-on-a-separate-server). In that case, the
    [Pages path](#change-storage-path) must also be present in the server that
-   the Pages daemon is installed, so you will have to share it via network.
+   the Pages daemon is installed, so you must share it through the network.
 - Run the Pages daemon in the same server as GitLab, listening on the same IP
-   but on different ports. In that case, you will have to proxy the traffic with
+   but on different ports. In that case, you must proxy the traffic with
    a load balancer. If you choose that route note that you should use TCP load
-   balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
-   pages will not be able to be served with user provided certificates. For
+   balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the
+   pages can't be served with user-provided certificates. For
    HTTP it's OK to use HTTP or TCP load balancing.
 
-In this document, we will proceed assuming the first option. If you are not
+In this document, we proceed assuming the first option. If you are not
 supporting custom domains a secondary IP is not needed.
 
 ## Prerequisites
 
-Before proceeding with the Pages configuration, you will need to:
+Before proceeding with the Pages configuration, you must:
 
 1. Have a domain for Pages that is not a subdomain of your GitLab instance domain.
 
@@ -69,7 +69,7 @@ Before proceeding with the Pages configuration, you will need to:
 1. (Only for custom domains) Have a **secondary IP**.
 
 NOTE:
-If your GitLab instance and the Pages daemon are deployed in a private network or behind a firewall, your GitLab Pages websites will only be accessible to devices/users that have access to the private network.
+If your GitLab instance and the Pages daemon are deployed in a private network or behind a firewall, your GitLab Pages websites are only accessible to devices/users that have access to the private network.
 
 ### Add the domain to the Public Suffix List
 
@@ -97,8 +97,8 @@ host that GitLab runs. For example, an entry would look like this:
 *.example.io. 1800 IN AAAA 2001::1
 ```
 
-where `example.io` is the domain under which GitLab Pages will be served
-and `192.0.2.1` is the IPv4 address of your GitLab instance and `2001::1` is the
+Where `example.io` is the domain GitLab Pages is served from,
+`192.0.2.1` is the IPv4 address of your GitLab instance, and `2001::1` is the
 IPv6 address. If you don't have IPv6, you can omit the AAAA record.
 
 NOTE:
@@ -123,7 +123,7 @@ since that is needed in all configurations.
 URL scheme: `http://<namespace>.example.io/<project_slug>`
 
 This is the minimum setup that you can use Pages with. It is the base for all
-other setups as described below. NGINX will proxy all requests to the daemon.
+other setups as described below. NGINX proxies all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
 1. Set the external URL for GitLab Pages in `/etc/gitlab/gitlab.rb`:
@@ -147,7 +147,7 @@ Watch the [video tutorial](https://youtu.be/dD8c7WNcc6s) for this configuration.
 
 URL scheme: `https://<namespace>.example.io/<project_slug>`
 
-NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
+NGINX proxies all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
 
 1. Place the certificate and key inside `/etc/gitlab/ssl`
@@ -168,8 +168,8 @@ outside world.
 
 ### Additional configuration for Docker container
 
-The GitLab Pages daemon will not have permissions to bind mounts when it runs
-in a Docker container. To overcome this issue you'll need to change the chroot
+The GitLab Pages daemon doesn't have permissions to bind mounts when it runs
+in a Docker container. To overcome this issue, you must change the chroot
 behavior:
 
 1. Edit `/etc/gitlab/gitlab.rb`.
@@ -189,7 +189,7 @@ The [GitLab Pages README](https://gitlab.com/gitlab-org/gitlab-pages#caveats) ha
 
 Below is a table of all configuration settings known to Pages in Omnibus GitLab,
 and what they do. These options can be adjusted in `/etc/gitlab/gitlab.rb`,
-and will take effect after you [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+and take effect after you [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 Most of these settings don't need to be configured manually unless you need more granular
 control over how the Pages daemon runs and serves content in your environment.
 
@@ -218,7 +218,7 @@ control over how the Pages daemon runs and serves content in your environment.
 | `inplace_chroot` |  On [systems that don't support bind-mounts](index.md#additional-configuration-for-docker-container), this instructs GitLab Pages to chroot into its `pages_path` directory. Some caveats exist when using inplace chroot; refer to the GitLab Pages [README](https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md#caveats) for more information.
 | `insecure_ciphers` |  Use default list of cipher suites, may contain insecure ones like 3DES and RC4.
 | `internal_gitlab_server` | Internal GitLab server address used exclusively for API requests. Useful if you want to send that traffic over an internal load balancer. Defaults to GitLab `external_url`.
-| `listen_proxy` |  The addresses to listen on for reverse-proxy requests. Pages will bind to these addresses' network socket and receives incoming requests from it. Sets the value of `proxy_pass` in `$nginx-dir/conf/gitlab-pages.conf`.
+| `listen_proxy` |  The addresses to listen on for reverse-proxy requests. Pages binds to these addresses' network sockets and receives incoming requests from them. Sets the value of `proxy_pass` in `$nginx-dir/conf/gitlab-pages.conf`.
 | `log_directory` |  Absolute path to a log directory.
 | `log_format` |  The log output format: `text` or `json`.
 | `log_verbose` |  Verbose logging, true/false.
@@ -250,7 +250,7 @@ control over how the Pages daemon runs and serves content in your environment.
 In addition to the wildcard domains, you can also have the option to configure
 GitLab Pages to work with custom domains. Again, there are two options here:
 support custom domains with and without TLS certificates. The easiest setup is
-that without TLS certificates. In either case, you'll need a **secondary IP**. If
+that without TLS certificates. In either case, you need a **secondary IP**. If
 you have IPv6 as well as IPv4 addresses, you can use them both.
 
 ### Custom domains
@@ -321,7 +321,7 @@ world. Custom domains and TLS are supported.
 
 To prevent malicious users from hijacking domains that don't belong to them,
 GitLab supports [custom domain verification](../../user/project/pages/custom_domains_ssl_tls_certification/index.md#steps).
-When adding a custom domain, users will be required to prove they own it by
+When adding a custom domain, users are required to prove they own it by
 adding a GitLab-controlled verification code to the DNS records for that domain.
 
 If your user base is private or otherwise trusted, you can disable the
@@ -337,11 +337,11 @@ This setting is enabled by default.
 allows users to add Let's Encrypt SSL certificates for GitLab Pages
 sites served under a custom domain.
 
-To enable it, you'll need to:
+To enable it, you must:
 
-1. Choose an email on which you will receive notifications about expiring domains.
+1. Choose an email address on which you want to receive notifications about expiring domains.
 1. Navigate to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
-1. Enter the email for receiving notifications and accept Let's Encrypt's Terms of Service as shown below.
+1. Enter the email address for receiving notifications and accept Let's Encrypt's Terms of Service as shown below.
 1. Click **Save changes**.
 
 ![Let's Encrypt settings](img/lets_encrypt_integration_v12_1.png)
@@ -384,7 +384,7 @@ all the App nodes and Sidekiq nodes.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32095) in GitLab 12.7.
 
 You can enforce [Access Control](#access-control) for all GitLab Pages websites hosted
-on your GitLab instance. By doing so, only logged-in users will have access to them.
+on your GitLab instance. By doing so, only logged-in users have access to them.
 This setting overrides Access Control set by users in individual projects.
 
 This can be useful to preserve information published with Pages websites to the users
@@ -417,7 +417,7 @@ internet connectivity is gated by a proxy. To use a proxy for GitLab Pages:
 
 When using certificates issued by a custom CA, [Access Control](../../user/project/pages/pages_access_control.md#gitlab-pages-access-control) and
 the [online view of HTML job artifacts](../../ci/pipelines/job_artifacts.md#browsing-artifacts)
-will fail to work if the custom CA is not recognized.
+fails to work if the custom CA is not recognized.
 
 This usually results in this error:
 `Post /oauth/token: x509: certificate signed by unknown authority`.
@@ -602,7 +602,7 @@ database encryption. Proceed with caution.
    changes to take effect. The `gitlab-secrets.json` file is now updated with the
    new configuration.
 
-1. Set up a new server. This will become the **Pages server**.
+1. Set up a new server. This becomes the **Pages server**.
 
 1. Create an [NFS share](../nfs.md)
    on the **Pages server** and configure this share to
@@ -668,7 +668,7 @@ Pages server.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217912) in GitLab 13.3.
 
 GitLab Pages can use different sources to get domain configuration.
-The default value is `nil`; however, GitLab Pages will default to `auto`.
+The default value is `nil`. However, GitLab Pages defaults to `auto`.
 
    ```ruby
    gitlab_pages['domain_config_source'] = nil
@@ -806,10 +806,10 @@ provided at `/etc/ssl/ca-bundle.pem`. It's
 from `/opt/gitlab/embedded/ssl/certs/cacert.pem`
 as part of starting up Pages.
 
-If the permissions on the source file are incorrect (they should be `0644`) then
-the file inside the chroot jail will also be wrong.
+If the permissions on the source file are incorrect (they should be `0644`), then
+the file inside the chroot jail is also wrong.
 
-Pages will log errors in `/var/log/gitlab/gitlab-pages/current` like:
+Pages logs errors in `/var/log/gitlab/gitlab-pages/current` like:
 
 ```plaintext
 x509: failed to load system roots and no roots provided

doc/administration/pages/source.md

@@ -17,8 +17,8 @@ You are encouraged to read the [Omnibus documentation](index.md) as it provides
 some invaluable information to the configuration of GitLab Pages. Please proceed
 to read it before going forward with this guide.
 
-We also highly recommend that you use the Omnibus GitLab packages, as we
-optimize them specifically for GitLab, and we will take care of upgrading GitLab
+We also highly recommend that you use the Omnibus GitLab packages. We
+optimize them specifically for GitLab, and we take care of upgrading GitLab
 Pages to the latest supported version.
 
 ## Overview
@@ -38,22 +38,22 @@ which you can set it up:
 1. Run the Pages daemon in the same server as GitLab, listening on a secondary IP.
 1. Run the Pages daemon in a separate server. In that case, the
    [Pages path](#change-storage-path) must also be present in the server that
-   the Pages daemon is installed, so you will have to share it via network.
+   the Pages daemon is installed, so you must share it through the network.
 1. Run the Pages daemon in the same server as GitLab, listening on the same IP
-   but on different ports. In that case, you will have to proxy the traffic with
-   a load balancer. If you choose that route note that you should use TCP load
-   balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
-   pages will not be able to be served with user provided certificates. For
-   HTTP it's OK to use HTTP or TCP load balancing.
+   but on different ports. In that case, you must proxy the traffic with
+   a load balancer. If you choose that route, note that you should use TCP load
+   balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing), the
+   pages aren't able to be served with user-provided certificates. For
+   HTTP, it's OK to use HTTP or TCP load balancing.
 
-In this document, we will proceed assuming the first option. If you are not
-supporting custom domains a secondary IP is not needed.
+In this document, we proceed assuming the first option. If you aren't
+supporting custom domains, a secondary IP isn't needed.
 
 ## Prerequisites
 
 Before proceeding with the Pages configuration, make sure that:
 
-1. You have a separate domain under which GitLab Pages will be served. In
+1. You have a separate domain to serve GitLab Pages from. In
    this document we assume that to be `example.io`.
 1. You have configured a **wildcard DNS record** for that domain.
 1. You have installed the `zip` and `unzip` packages in the same server that
@@ -74,7 +74,7 @@ host that GitLab runs. For example, an entry would look like this:
 *.example.io. 1800 IN A 192.0.2.1
 ```
 
-where `example.io` is the domain under which GitLab Pages will be served
+Where `example.io` is the domain to serve GitLab Pages from,
 and `192.0.2.1` is the IP address of your GitLab instance.
 
 NOTE:
@@ -97,7 +97,7 @@ since that is needed in all configurations.
 URL scheme: `http://<namespace>.example.io/<project_slug>`
 
 This is the minimum setup that you can use Pages with. It is the base for all
-other setups as described below. NGINX will proxy all requests to the daemon.
+other setups as described below. NGINX proxies all requests to the daemon.
 The Pages daemon doesn't listen to the outside world.
 
 1. Install the Pages daemon:
@@ -117,7 +117,7 @@ The Pages daemon doesn't listen to the outside world.
    ```
 
 1. Edit `gitlab.yml` and under the `pages` setting, set `enabled` to `true` and
-   the `host` to the FQDN under which GitLab Pages will be served:
+   the `host` to the FQDN to serve GitLab Pages from:
 
    ```yaml
    ## GitLab Pages
@@ -159,7 +159,7 @@ The Pages daemon doesn't listen to the outside world.
 
 URL scheme: `https://<namespace>.example.io/<project_slug>`
 
-NGINX will proxy all requests to the daemon. Pages daemon doesn't listen to the
+NGINX proxies all requests to the daemon. Pages daemon doesn't listen to the
 outside world.
 
 1. Install the Pages daemon:
@@ -238,8 +238,8 @@ world. Custom domains are supported, but no TLS.
    ```
 
 1. Edit `gitlab.yml` to look like the example below. You need to change the
-   `host` to the FQDN under which GitLab Pages will be served. Set
-   `external_http` to the secondary IP on which the pages daemon will listen
+   `host` to the FQDN to serve GitLab Pages from. Set
+   `external_http` to the secondary IP on which the pages daemon listens
    for connections:
 
    ```yaml
@@ -303,9 +303,9 @@ world. Custom domains and TLS are supported.
    ```
 
 1. Edit `gitlab.yml` to look like the example below. You need to change the
-   `host` to the FQDN under which GitLab Pages will be served. Set
+   `host` to the FQDN to serve GitLab Pages from. Set
    `external_http` and `external_https` to the secondary IP on which the pages
-   daemon will listen for connections:
+   daemon listens for connections:
 
    ```yaml
    ## GitLab Pages

doc/api/deploy_keys.md

@@ -109,8 +109,8 @@ Example response:
 
 Creates a new deploy key for a project.
 
-If the deploy key already exists in another project, it will be joined to current
-project only if original one is accessible by the same user.
+If the deploy key already exists in another project, it's joined to the current
+project only if the original one is accessible by the same user.
 
 ```plaintext
 POST /projects/:id/deploy_keys
@@ -171,7 +171,7 @@ Example response:
 
 ## Delete deploy key
 
-Removes a deploy key from the project. If the deploy key is used only for this project, it will be deleted from the system.
+Removes a deploy key from the project. If the deploy key is used only for this project, it's deleted from the system.
 
 ```plaintext
 DELETE /projects/:id/deploy_keys/:key_id

doc/api/deployments.md

@@ -379,7 +379,7 @@ This API retrieves the list of merge requests shipped with a given deployment:
 GET /projects/:id/deployments/:deployment_id/merge_requests
 ```
 
-It supports the same parameters as the [Merge Requests API](merge_requests.md#list-merge-requests) and will return a response using the same format:
+It supports the same parameters as the [Merge Requests API](merge_requests.md#list-merge-requests) and returns a response using the same format:
 
 ```shell
 curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/deployments/42"

doc/api/features.md

@@ -111,8 +111,8 @@ Example response:
 
 ## Set or create a feature
 
-Set a feature's gate value. If a feature with the given name doesn't exist yet
-it will be created. The value can be a boolean, or an integer to indicate
+Set a feature's gate value. If a feature with the given name doesn't exist yet,
+it's created. The value can be a boolean, or an integer to indicate
 percentage of time.
 
 ```plaintext

doc/api/releases/index.md

@@ -360,16 +360,16 @@ POST /projects/:id/releases
 | -------------------| --------------- | --------                    | -------------------------------------------------------------------------------------------------------------------------------- |
 | `id`               | integer/string  | yes                         | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding).                                              |
 | `name`             | string          | no                          | The release name.                                                                                                                |
-| `tag_name`         | string          | yes                         | The tag where the release will be created from.                                                                                  |
+| `tag_name`         | string          | yes                         | The tag where the release is created from.                                                                                  |
 | `description`      | string          | no                          | The description of the release. You can use [Markdown](../../user/markdown.md).                                                  |
-| `ref`              | string          | yes, if `tag_name` doesn't exist | If a tag specified in `tag_name` doesn't exist, the release will be created from `ref` and tagged with `tag_name`. It can be a commit SHA, another tag name, or a branch name. |
+| `ref`              | string          | yes, if `tag_name` doesn't exist | If a tag specified in `tag_name` doesn't exist, the release is created from `ref` and tagged with `tag_name`. It can be a commit SHA, another tag name, or a branch name. |
 | `milestones`       | array of string | no                          | The title of each milestone the release is associated with. [GitLab Premium](https://about.gitlab.com/pricing/) customers can specify group milestones.                                                                      |
 | `assets:links`     | array of hash   | no                          | An array of assets links.                                                                                                        |
 | `assets:links:name`| string          | required by: `assets:links` | The name of the link. Link names must be unique within the release.                                                              |
 | `assets:links:url` | string          | required by: `assets:links` | The URL of the link. Link URLs must be unique within the release.                                                                |
 | `assets:links:filepath` | string     | no | Optional path for a [Direct Asset link](../../user/project/releases/index.md#permanent-links-to-release-assets).
 | `assets:links:link_type` | string     | no | The type of the link: `other`, `runbook`, `image`, `package`. Defaults to `other`.
-| `released_at`      | datetime        | no                          | The date when the release will be/was ready. Defaults to the current time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). |
+| `released_at`      | datetime        | no                          | The date when the release is/was ready. Defaults to the current time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`). |
 
 Example request:
 
@@ -493,7 +493,7 @@ Example response:
 Group milestones associated with the project may be specified in the `milestones`
 array for [Create a release](#create-a-release) and [Update a release](#update-a-release)
 API calls. Only milestones associated with the project's group may be specified, and
-adding milestones for ancestor groups will raise an error.
+adding milestones for ancestor groups raises an error.
 
 ## Collect release evidence **(PREMIUM ONLY)**
 
@@ -537,7 +537,7 @@ PUT /projects/:id/releases/:tag_name
 | `name`        | string          | no       | The release name.                                                                                           |
 | `description` | string          | no       | The description of the release. You can use [Markdown](../../user/markdown.md).                             |
 | `milestones`  | array of string | no       | The title of each milestone to associate with the release. [GitLab Premium](https://about.gitlab.com/pricing/) customers can specify group milestones. To remove all milestones from the release, specify `[]`. |
-| `released_at` | datetime        | no       | The date when the release will be/was ready. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`).          |
+| `released_at` | datetime        | no       | The date when the release is/was ready. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`).          |
 
 Example request:
 
@@ -631,7 +631,7 @@ Example response:
 
 ## Delete a Release
 
-Delete a Release. Deleting a Release will not delete the associated tag.
+Delete a Release. Deleting a Release doesn't delete the associated tag.
 
 ```plaintext
 DELETE /projects/:id/releases/:tag_name
@@ -717,6 +717,6 @@ Example response:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/38105) in GitLab 12.1.
 
-A release with a `released_at` attribute set to a future date will be labeled an **Upcoming Release** in the UI:
+A release with a `released_at` attribute set to a future date is labeled an **Upcoming Release** in the UI:
 
 ![Upcoming release](img/upcoming_release_v12_1.png)

doc/ci/cloud_deployment/index.md

@@ -11,10 +11,9 @@ Interacting with a major cloud provider may have become a much needed task that'
 part of your delivery process. With GitLab you can
 [deploy your application anywhere](https://about.gitlab.com/stages-devops-lifecycle/deploy-targets/).
 
-For some specific deployment targets, GitLab makes this process less painful by providing Docker images
-that come with the needed libraries and tools pre-installed.
-By referencing them in your CI/CD pipeline, you'll be able to interact with your chosen
-cloud provider more easily.
+For some specific deployment targets, GitLab makes this process less painful by providing Docker
+images with the needed libraries and tools pre-installed. By referencing them in your
+CI/CD pipeline, you can interact with your chosen cloud provider more easily.
 
 ## AWS
 
@@ -36,7 +35,7 @@ Some credentials are required to be able to run `aws` commands:
 1. Select your newly created user to access its details. Navigate to **Security credentials > Create a new access key**.
 
    NOTE:
-   A new **Access key ID** and **Secret access key** pair will be generated. Please take a note of them right away.
+   A new **Access key ID** and **Secret access key** are generated. Please take a note of them right away.
 
 1. In your GitLab project, go to **Settings > CI / CD**. Set the following as
    [environment variables](../variables/README.md#gitlab-cicd-environment-variables)
@@ -170,14 +169,14 @@ After you have these prerequisites ready, follow these steps:
 
 1. Commit and push your updated `.gitlab-ci.yml` to your project's repository, and you're done!
 
-   Your application Docker image will be rebuilt and pushed to the GitLab registry.
+   Your application Docker image is rebuilt and pushed to the GitLab registry.
    If your image is located in a private registry, make sure your task definition is
    [configured with a `repositoryCredentials` attribute](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth.html).
 
-   Then the targeted task definition will be updated with the location of the new
-   Docker image, and a new revision will be created in ECS as result.
+   Then the targeted task definition is updated with the location of the new
+   Docker image, and a new revision is created in ECS as result.
 
-   Finally, your AWS ECS service will be updated with the new revision of the
+   Finally, your AWS ECS service is updated with the new revision of the
    task definition, making the cluster pull the newest version of your
    application.
 
@@ -190,7 +189,7 @@ and [`Jobs/Deploy/ECS.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blo
 used along with the main template. They may move or change unexpectedly causing your
 pipeline to fail if you didn't include the main template. Also, the job names within
 these templates may change. Do not override these jobs names in your own pipeline,
-as the override will stop working when the name changes.
+as the override stops working when the name changes.
 
 Alternatively, if you don't wish to use the `AWS/Deploy-ECS.gitlab-ci.yml` template
 to deploy to AWS ECS, you can always use our

doc/ci/environments/deployment_safety.md

@@ -107,6 +107,7 @@ build:service-b:
     name: production
 ```
 
-The [Skip outdated deployment jobs](../pipelines/settings.md#skip-outdated-deployment-jobs) might not work well with this configuration, and will need to be disabled.
+The [Skip outdated deployment jobs](../pipelines/settings.md#skip-outdated-deployment-jobs) might
+not work well with this configuration, and must be disabled.
 
 There is a [plan to introduce a new annotation for environments](https://gitlab.com/gitlab-org/gitlab/-/issues/208655) to address this issue.

doc/ci/environments/incremental_rollouts.md

@@ -44,8 +44,8 @@ allows more control over the this feature. The steps in an incremental rollout d
 number of pods that are defined for the deployment, which are configured when the Kubernetes
 cluster is created.
 
-For example, if your application has 10 pods and a 10% rollout job is run, the new instance of the
-application will be deployed to a single pod while the remaining 9 will present the previous instance.
+For example, if your application has 10 pods and a 10% rollout job runs, the new instance of the
+application is deployed to a single pod while the remaining nine are present the previous instance.
 
 First we [define the template as manual](https://gitlab.com/gl-release/incremental-rollout-example/blob/master/.gitlab-ci.yml#L100-103):
 
@@ -65,7 +65,7 @@ rollout 10%:
     ROLLOUT_PERCENTAGE: 10
 ```
 
-When the jobs are built, a **play** button will appear next to the job's name. Click the **play** button
+When the jobs are built, a **play** button appears next to the job's name. Click the **play** button
 to release each stage of pods. You can also rollback by running a lower percentage job. Once 100%
 is reached, you cannot roll back using this method. It is still possible to roll back by redeploying
 the old version using the **Rollback** button on the environment page.
@@ -79,13 +79,13 @@ available, demonstrating manually triggered incremental rollouts.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7545) in GitLab 11.4.
 
-Timed rollouts behave in the same way as manual rollouts, except that each job is defined with a delay
-in minutes before it will deploy. Clicking on the job will reveal the countdown.
+Timed rollouts behave in the same way as manual rollouts, except that each job is defined with a
+delay in minutes before it deploys. Clicking the job reveals the countdown.
 
 ![Timed rollout](img/timed_rollout_v12_7.png)
 
-It is possible to combine this functionality with manual incremental rollouts so that the job will
-countdown and then deploy.
+It is possible to combine this functionality with manual incremental rollouts so that the job
+counts down and then deploys.
 
 First we [define the template as timed](https://gitlab.com/gl-release/timed-rollout-example/blob/master/.gitlab-ci.yml#L86-89):
 

doc/ci/environments/index.md

@@ -28,7 +28,7 @@ This helps find bugs in your software, and also in the deployment process as wel
 
 GitLab CI/CD is capable of not only testing or building your projects, but also
 deploying them in your infrastructure, with the added benefit of giving you a
-way to track your deployments. In other words, you will always know what is
+way to track your deployments. In other words, you always know what is
 currently being deployed or has been deployed on your servers.
 
 It's important to know that:
@@ -102,12 +102,12 @@ We have defined three [stages](../yaml/README.md#stages):
 - `build`
 - `deploy`
 
-The jobs assigned to these stages will run in this order. If any job fails, then
-the pipeline fails and jobs that are assigned to the next stage won't run.
+The jobs assigned to these stages run in this order. If any job fails, then
+the pipeline fails and jobs that are assigned to the next stage don't run.
 
 In our case:
 
-- The `test` job will run first.
+- The `test` job runs first.
 - Then the `build` job.
 - Lastly the `deploy_staging` job.
 
@@ -127,13 +127,13 @@ numbers, spaces, and `-`, `_`, `/`, `{`, `}`, or `.`. Also, it must not start no
 
 In summary, with the above `.gitlab-ci.yml` we have achieved the following:
 
-- All branches will run the `test` and `build` jobs.
-- The `deploy_staging` job will run [only](../yaml/README.md#onlyexcept-basic) on the `master`
+- All branches run the `test` and `build` jobs.
+- The `deploy_staging` job runs [only](../yaml/README.md#onlyexcept-basic) on the `master`
   branch, which means all merge requests that are created from branches don't
   get deployed to the staging server.
-- When a merge request is merged, all jobs will run and the `deploy_staging`
-  job will deploy our code to a staging server while the deployment
-  will be recorded in an environment named `staging`.
+- When a merge request is merged, all jobs run and the `deploy_staging`
+  job deploys our code to a staging server while the deployment
+  is recorded in an environment named `staging`.
 
 #### Environment variables and runners
 
@@ -147,8 +147,8 @@ two forms:
 
 If you change the name of an existing environment, the:
 
-- `$CI_ENVIRONMENT_NAME` variable will be updated with the new environment name.
-- `$CI_ENVIRONMENT_SLUG` variable will remain unchanged to prevent unintended side
+- `$CI_ENVIRONMENT_NAME` variable is updated with the new environment name.
+- `$CI_ENVIRONMENT_SLUG` variable remains unchanged to prevent unintended side
   effects.
 
 Starting with GitLab 9.3, the environment URL is exposed to the runner via
@@ -214,13 +214,13 @@ It parses the `deploy.env` report artifact, registers a list of variables as run
 uses it for expanding `environment:url: $DYNAMIC_ENVIRONMENT_URL` and sets it to the environment URL.
 You can also specify a static part of the URL at `environment:url:`, such as
 `https://$DYNAMIC_ENVIRONMENT_URL`. If the value of `DYNAMIC_ENVIRONMENT_URL` is
-`example.com`, the final result will be `https://example.com`.
+`example.com`, the final result is `https://example.com`.
 
 The assigned URL for the `review/your-branch-name` environment is [visible in the UI](#using-the-environment-url).
 
 Note the following:
 
-- `stop_review` doesn't generate a dotenv report artifact, so it won't recognize the
+- `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the
   `DYNAMIC_ENVIRONMENT_URL` variable. Therefore you shouldn't set `environment:url:` in the
   `stop_review` job.
 - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
@@ -280,7 +280,7 @@ deploy_prod:
 The `when: manual` action:
 
 - Exposes a "play" button in the GitLab UI for that job.
-- Means the `deploy_prod` job will only be triggered when the "play" button is clicked.
+- Means the `deploy_prod` job is only triggered when the "play" button is clicked.
 
 You can find the "play" button in the pipelines, environments, deployments, and jobs views.
 
@@ -330,7 +330,7 @@ For more information, see [Where variables can be used](../variables/where_varia
 Runners expose various [environment variables](../variables/README.md) when a job runs, so
 you can use them as environment names.
 
-In the following example, the job will deploy to all branches except `master`:
+In the following example, the job deploys to all branches except `master`:
 
 ```yaml
 deploy_review:
@@ -363,7 +363,7 @@ For the value of:
   may contain a `/` or other characters that would be invalid in a domain name or URL,
   so we use `$CI_ENVIRONMENT_SLUG` to guarantee that we get a valid URL.
 
-  For example, given a `$CI_COMMIT_REF_NAME` of `100-Do-The-Thing`, the URL will be something
+  For example, given a `$CI_COMMIT_REF_NAME` of `100-Do-The-Thing`, the URL is something
   like `https://100-do-the-4f99a2.example.com`. Again, the way you set up
   the web server to serve these requests is based on your setup.
 
@@ -396,7 +396,7 @@ The following configuration options are supported:
 
 - [`namespace`](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
 
-In the following example, the job will deploy your application to the
+In the following example, the job deploys your application to the
 `production` Kubernetes namespace.
 
 ```yaml
@@ -414,7 +414,7 @@ deploy:
 ```
 
 When deploying to a Kubernetes cluster using the GitLab Kubernetes integration,
-information about the cluster and namespace will be displayed above the job
+information about the cluster and namespace is displayed above the job
 trace on the deployment job page:
 
 ![Deployment cluster information](../img/environments_deployment_cluster_v12_8.png)
@@ -502,7 +502,7 @@ deploy_prod:
 A more realistic example would also include copying files to a location where a
 webserver (for example, NGINX) could then access and serve them.
 
-The example below will copy the `public` directory to `/srv/nginx/$CI_COMMIT_REF_SLUG/public`:
+The example below copies the `public` directory to `/srv/nginx/$CI_COMMIT_REF_SLUG/public`:
 
 ```yaml
 review_app:
@@ -514,7 +514,7 @@ review_app:
     url: https://$CI_COMMIT_REF_SLUG.example.com
 ```
 
-This example requires that NGINX and GitLab Runner are set up on the server this job will run on.
+This example requires that NGINX and GitLab Runner are set up on the server this job runs on.
 
 See the [limitations](#limitations) section for some edge cases regarding the naming of your
 branches and Review Apps.
@@ -526,10 +526,10 @@ The complete example provides the following workflow to developers:
 - Push the branch to GitLab.
 - Create a merge request.
 
-Behind the scenes, the runner will:
+Behind the scenes, the runner:
 
-- Pick up the changes and start running the jobs.
-- Run the jobs sequentially as defined in `stages`:
+- Picks up the changes and starts running the jobs.
+- Runs the jobs sequentially as defined in `stages`:
   - First, run the tests.
   - If the tests succeed, build the app.
   - If the build succeeds, the app is deployed to an environment with a name specific to the
@@ -587,7 +587,7 @@ deployments, but an environment can have multiple deployments.
 > - The environments page can only be viewed by users with [Reporter permission](../../user/permissions.md#project-members-permissions)
 >   and above. For more information on permissions, see the [permissions documentation](../../user/permissions.md).
 > - Only deploys that happen after your `.gitlab-ci.yml` is properly configured
->   will show up in the **Environment** and **Last deployment** lists.
+>   show up in the **Environment** and **Last deployment** lists.
 
 ### Viewing deployment history
 
@@ -619,7 +619,7 @@ To retry or rollback a deployment:
 #### What to expect with a rollback
 
 Pressing the **Rollback** button on a specific commit triggers a _new_ deployment with its own
-unique job ID. This means that you will see a new deployment that points to the commit you're
+unique job ID. This new deployment points to the commit you're
 rolling back to.
 
 Note that the defined deployment process in the job's `script` determines whether the rollback
@@ -698,20 +698,20 @@ stop_review:
 
 If you can't use [Pipelines for merge requests](../merge_request_pipelines/index.md),
 setting the [`GIT_STRATEGY`](../runners/README.md#git-strategy) to `none` is necessary in the
-`stop_review` job so that the [runner](https://docs.gitlab.com/runner/) won't
+`stop_review` job so that the [runner](https://docs.gitlab.com/runner/) doesn't
 try to check out the code after the branch is deleted.
 
 When you have an environment that has a stop action defined (typically when
-the environment describes a Review App), GitLab will automatically trigger a
+the environment describes a Review App), GitLab automatically triggers a
 stop action when the associated branch is deleted. The `stop_review` job must
 be in the same `stage` as the `deploy_review` job in order for the environment
 to automatically stop.
 
 Additionally, both jobs should have matching [`rules`](../yaml/README.md#onlyexcept-basic)
 or [`only/except`](../yaml/README.md#onlyexcept-basic) configuration. In the example
-above, if the configuration is not identical, the `stop_review` job might not be
-included in all pipelines that include the `deploy_review` job, and it will not be
-possible to trigger the `action: stop` to stop the environment automatically.
+above, if the configuration isn't identical, the `stop_review` job might not be
+included in all pipelines that include the `deploy_review` job, and it isn't
+possible to trigger `action: stop` to stop the environment automatically.
 
 You can read more in the [`.gitlab-ci.yml` reference](../yaml/README.md#environmenton_stop).
 
@@ -767,7 +767,7 @@ stop_review_app:
 ```
 
 As long as a merge request is active and keeps getting new commits,
-the review app will not stop, so developers don't need to worry about
+the review app doesn't stop, so developers don't need to worry about
 re-initiating review app.
 
 On the other hand, since `stop_review_app` is set to `auto_stop_in: 1 week`,
@@ -777,8 +777,8 @@ GitLab automatically triggers the `stop_review_app` job to stop the environment.
 You can also check the expiration date of environments through the GitLab UI. To do so,
 go to **Operations > Environments > Environment**. You can see the auto-stop period
 at the left-top section and a pin-mark button at the right-top section. This pin-mark
-button can be used to prevent auto-stopping the environment. By clicking this button, the `auto_stop_in` setting is over-written
-and the environment will be active until it's stopped manually.
+button can be used to prevent auto-stopping the environment. By clicking this button, the
+`auto_stop_in` setting is overwritten and the environment is active until it's stopped manually.
 
 ![Environment auto stop](../img/environment_auto_stop_v12_8.png)
 
@@ -820,8 +820,8 @@ build with the specified environment runs. Newer deployments can also
 You may want to specify an environment keyword to
 [protect builds from unauthorized access](protected_environments.md), or to get
 access to [scoped variables](#scoping-environments-with-specs). In these cases,
-you can use the `action: prepare` keyword to ensure deployments won't be created,
-and no builds would be canceled:
+you can use the `action: prepare` keyword to ensure deployments aren't created,
+and no builds are canceled:
 
 ```yaml
 build:
@@ -929,13 +929,13 @@ dashboard to appear, you need to Configure Prometheus to collect at least one
 
 In GitLab 9.2 and later, all deployments to an environment are shown directly on the monitoring dashboard.
 
-Once configured, GitLab will attempt to retrieve [supported performance metrics](../../user/project/integrations/prometheus_library/index.md)
+Once configured, GitLab attempts to retrieve [supported performance metrics](../../user/project/integrations/prometheus_library/index.md)
 for any environment that has had a successful deployment. If monitoring data was
-successfully retrieved, a **Monitoring** button will appear for each environment.
+successfully retrieved, a **Monitoring** button appears for each environment.
 
 ![Environment Detail with Metrics](../img/deployments_view.png)
 
-Clicking on the **Monitoring** button will display a new page showing up to the last
+Clicking the **Monitoring** button displays a new page showing up to the last
 8 hours of performance data. It may take a minute or two for data to appear
 after initial deployment.
 
@@ -962,10 +962,10 @@ of your web browser. To enable it, follow the instructions given in the service
 documentation.
 
 Note that container-based deployments often lack basic tools (like an editor), and may
-be stopped or restarted at any time. If this happens, you will lose all your
+be stopped or restarted at any time. If this happens, you lose all your
 changes. Treat this as a debugging tool, not a comprehensive online IDE.
 
-Once enabled, your environments will gain a "terminal" button:
+Once enabled, your environments gain a **Terminal** button:
 
 ![Terminal button on environment index](../img/environments_terminal_button_on_index.png)
 
@@ -973,12 +973,12 @@ You can also access the terminal button from the page for a specific environment
 
 ![Terminal button for an environment](../img/environments_terminal_button_on_show.png)
 
-Wherever you find it, clicking the button will take you to a separate page to
+Wherever you find it, clicking the button takes you to a separate page to
 establish the terminal session:
 
 ![Terminal page](../img/environments_terminal_page.png)
 
-This works just like any other terminal. You'll be in the container created
+This works like any other terminal. You're in the container created
 by your deployment so you can:
 
 - Run shell commands and get responses in real time.
@@ -1008,9 +1008,8 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 You can limit the environment scope of a variable by
 defining which environments it can be available for.
 
-Wildcards can be used, and the default environment scope is `*`, which means
-any jobs will have this variable, not matter if an environment is defined or
-not.
+Wildcards can be used and the default environment scope is `*`. This means that
+any jobs can have this variable regardless of whether an environment is defined.
 
 For example, if the environment scope is `production`, then only the jobs
 having the environment `production` defined would have this specific variable.
@@ -1057,7 +1056,7 @@ environment's operational health.
 ## Limitations
 
 In the `environment: name`, you are limited to only the [predefined environment variables](../variables/predefined_variables.md).
-Re-using variables defined inside `script` as part of the environment name will not work.
+Re-using variables defined inside `script` as part of the environment name doesn't work.
 
 ## Further reading
 

doc/ci/environments/protected_environments.md

@@ -36,14 +36,14 @@ To protect an environment:
 1. In the **Allowed to Deploy** dropdown menu, select the role, users, or groups you
    want to give deploy access to. Keep in mind that:
    - There are two roles to choose from:
-     - **Maintainers**: will allow access to all maintainers in the project.
-     - **Developers**: will allow access to all maintainers and all developers in the project.
+     - **Maintainers**: Allows access to all maintainers in the project.
+     - **Developers**: Allows access to all maintainers and all developers in the project.
    - You can only select groups that are already associated with the project.
-   - Only users that have at least Developer permission level will appear in
+   - Only users that have at least the Developer permission level appear in
      the **Allowed to Deploy** dropdown menu.
 1. Click the **Protect** button.
 
-The protected environment will now appear in the list of protected environments.
+The protected environment now appears in the list of protected environments.
 
 ### Use the API to protect an environment
 

doc/ci/examples/authenticating-with-hashicorp-vault/index.md

@@ -19,14 +19,14 @@ To learn more, read [Using external secrets in CI](../../secrets/index.md).
 
 This tutorial assumes you are familiar with GitLab CI/CD and Vault.
 
-To follow along, you will need:
+To follow along, you must have:
 
 - An account on GitLab.
 - A running Vault server and access to it is required to configure authentication and create roles
   and policies. For HashiCorp Vaults, this can be the Open Source or Enterprise version.
 
 NOTE:
-You will need to replace the `vault.example.com` URL below with the URL of your Vault server and `gitlab.example.com` with the URL of your GitLab instance.
+You must replace the `vault.example.com` URL below with the URL of your Vault server, and `gitlab.example.com` with the URL of your GitLab instance.
 
 ## How it works
 
@@ -57,7 +57,7 @@ The JWT's payload looks like this:
 }
 ```
 
-The JWT is encoded by using RS256 and signed with a dedicated private key. The expire time for the token will be set to job's timeout, if specified, or 5 minutes if it is not. The key used to sign this token may change without any notice. In such case retrying the job will generate new JWT using the current signing key.
+The JWT is encoded by using RS256 and signed with a dedicated private key. The expire time for the token is set to job's timeout, if specified, or 5 minutes if it is not. The key used to sign this token may change without any notice. In such case retrying the job generates new JWT using the current signing key.
 
 You can use this JWT and your instance's JWKS endpoint (`https://gitlab.example.com/-/jwks`) to authenticate with a Vault server that is configured to allow the JWT Authentication method for authentication.
 
@@ -111,7 +111,7 @@ EOF
 Success! Uploaded policy: myproject-production
 ```
 
-You'll also need roles that will link the JWT with these policies.
+You also need roles that link the JWT with these policies.
 
 One for staging named `myproject-staging`:
 
@@ -151,7 +151,7 @@ $ vault write auth/jwt/role/myproject-production - <<EOF
 EOF
 ```
 
-This example uses [bound_claims](https://www.vaultproject.io/api/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims will be allowed to authenticate.
+This example uses [bound_claims](https://www.vaultproject.io/api/auth/jwt#bound_claims) to specify that only a JWT with matching values for the specified claims is allowed to authenticate.
 
 Combined with [protected branches](../../../user/project/protected_branches.md), you can restrict who is able to authenticate and read the secrets.
 
@@ -159,7 +159,7 @@ Combined with [protected branches](../../../user/project/protected_branches.md),
 
 [user_claim](https://www.vaultproject.io/api/auth/jwt#user_claim) specifies the name for the Identity alias created by Vault upon a successful login.
 
-[bound_claims_type](https://www.vaultproject.io/api-docs/auth/jwt#bound_claims_type) configures the interpretation of the `bound_claims` values. If set to `glob`, the values will be interpreted as globs, with `*` matching any number of characters.
+[bound_claims_type](https://www.vaultproject.io/api-docs/auth/jwt#bound_claims_type) configures the interpretation of the `bound_claims` values. If set to `glob`, the values are interpreted as globs, with `*` matching any number of characters.
 
 For the full list of options, see Vault's [Create Role documentation](https://www.vaultproject.io/api/auth/jwt#create-role).
 
@@ -178,7 +178,7 @@ $ vault write auth/jwt/config \
 
 For the full list of available configuration options, see Vault's [API documentation](https://www.vaultproject.io/api/auth/jwt#configure).
 
-The following job, when run for the `master` branch, will be able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
+The following job, when run for the `master` branch, is able to read secrets under `secret/myproject/staging/`, but not the secrets under `secret/myproject/production/`:
 
 ```yaml
 read_secrets:
@@ -202,7 +202,7 @@ read_secrets:
 
 ![read_secrets staging](img/vault-read-secrets-staging.png)
 
-The following job will be able to authenticate using the `myproject-production` role and read secrets under `/secret/myproject/production/`:
+The following job is able to authenticate using the `myproject-production` role and read secrets under `/secret/myproject/production/`:
 
 ```yaml
 read_secrets:

doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md

@@ -9,11 +9,10 @@ type: tutorial
 
 ## Introduction
 
-In this article, we'll demonstrate how to deploy a [Spring
-Boot](https://projects.spring.io/spring-boot/) application to [Cloud
-Foundry (CF)](https://www.cloudfoundry.org/) with GitLab CI/CD using the [Continuous
-Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-deployment)
-method.
+This article demonstrates how to use the [Continuous Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/#continuous-deployment)
+method to deploy a [Spring Boot](https://projects.spring.io/spring-boot/) application to
+[Cloud Foundry (CF)](https://www.cloudfoundry.org/)
+with GitLab CI/CD.
 
 All the code for this project can be found in this [GitLab
 repository](https://gitlab.com/gitlab-examples/spring-gitlab-cf-deploy-demo).
@@ -25,17 +24,16 @@ using GitLab CI/CD, read through the blog post [Continuous Delivery of a Spring
 
 This tutorial assumes you are familiar with Java, GitLab, Cloud Foundry, and GitLab CI/CD.
 
-To follow along, you will need:
+To follow along, you need:
 
 - An account on [Pivotal Web Services (PWS)](https://run.pivotal.io/) or any
   other Cloud Foundry (CF) instance.
 - An account on GitLab.
 
 NOTE:
-You will need to replace the `api.run.pivotal.io` URL in the all below
-commands with the [API
-URL](https://docs.cloudfoundry.org/running/cf-api-endpoint.html) of your CF
-instance if you're not deploying to PWS.
+If you're not deploying to PWS, you must replace the `api.run.pivotal.io` URL in all the below
+commands with the [API URL](https://docs.cloudfoundry.org/running/cf-api-endpoint.html)
+of your CF instance.
 
 ## Create your project
 
@@ -46,9 +44,9 @@ GitLab when creating a new project:
 
 ## Configure the deployment to Cloud Foundry
 
-To deploy to Cloud Foundry we need to add a `manifest.yml` file. This
-is the configuration for the CF CLI we will use to deploy the application. We
-will create this in the root directory of our project with the following
+To deploy to Cloud Foundry you must add a `manifest.yml` file. This
+is the configuration for the CF CLI you must use to deploy the application.
+Create this in the root directory of your project with the following
 content:
 
 ```yaml
@@ -62,12 +60,12 @@ applications:
 
 ## Configure GitLab CI/CD to deploy your application
 
-Now we need to add the GitLab CI/CD configuration file
-([`.gitlab-ci.yml`](../../yaml/README.md)) to our
-project's root. This is how GitLab figures out what commands need to be run whenever
-code is pushed to our repository. We will add the following `.gitlab-ci.yml`
-file to the root directory of the repository, GitLab will detect it
-automatically and run the steps defined once we push our code:
+Now you must add the GitLab CI/CD configuration file
+([`.gitlab-ci.yml`](../../yaml/README.md))
+to your project's root. This is how GitLab figures out what commands must run whenever
+code is pushed to your repository. Add the following `.gitlab-ci.yml`
+file to the root directory of the repository. GitLab detects it
+automatically and runs the defined steps once you push your code:
 
 ```yaml
 image: java:8
@@ -96,15 +94,13 @@ production:
     - master
 ```
 
-We've used the `java:8` [Docker
-image](../../docker/using_docker_images.md) to build
-our application as it provides the up-to-date Java 8 JDK on [Docker
-Hub](https://hub.docker.com/). We've also added the [`only`
-clause](../../yaml/README.md#onlyexcept-basic)
-to ensure our deployments only happen when we push to the master branch.
+This uses the `java:8` [Docker image](../../docker/using_docker_images.md)
+to build your application, as it provides the up-to-date Java 8 JDK on [Docker Hub](https://hub.docker.com/).
+You also added the [`only` clause](../../yaml/README.md#onlyexcept-basic)
+to ensure your deployments only happen when you push to the master branch.
 
 Because the steps defined in `.gitlab-ci.yml` require credentials to sign in to
-CF, you'll need to add your CF credentials as
+CF, you must add your CF credentials as
 [environment variables](../../variables/README.md#predefined-environment-variables)
 in GitLab CI/CD. To set the environment variables, navigate to your project's
 **Settings > CI/CD**, and then expand **Variables**. Name the variables
@@ -122,8 +118,8 @@ your application and add its credentials to GitLab instead of using a
 developer's credentials.
 
 To start a manual deployment in GitLab go to **CI/CD > Pipelines** then click
-on **Run Pipeline**. After the app is finished deploying, it will display the
-URL of your application in the logs for the `production` job like:
+**Run Pipeline**. After the app is finished deploying, it displays the
+URL of your application in the logs for the `production` job:
 
 ```shell
 requested state: started

doc/ci/examples/deployment/README.md

@@ -55,10 +55,10 @@ To use different provider take a look at long list of [Supported Providers](http
 
 ## Using Dpl with Docker
 
-In most cases, you will have configured [GitLab Runner](https://docs.gitlab.com/runner/) to use your server's shell commands.
+In most cases, you configured [GitLab Runner](https://docs.gitlab.com/runner/) to use your server's shell commands.
 This means that all commands are run in the context of local user (e.g. `gitlab_runner` or `gitlab_ci_multi_runner`).
 It also means that most probably in your Docker container you don't have the Ruby runtime installed.
-You will have to install it:
+You must install it:
 
 ```yaml
 staging:
@@ -115,7 +115,7 @@ We also use two secure variables:
 
 ## Storing API keys
 
-Secure Variables can added by going to your project's
+To add secure variables, navigate to your project's
 **Settings > CI / CD > Variables**. The variables that are defined
 in the project settings are sent along with the build script to the runner.
 The secure variables are stored out of the repository. Never store secrets in

doc/ci/examples/deployment/composer-npm-deploy.md

@@ -9,13 +9,13 @@ type: tutorial
 
 This guide covers the building of dependencies of a PHP project while compiling assets via an NPM script using [GitLab CI/CD](../../README.md).
 
-While it is possible to create your own image with custom PHP and Node.js versions, for brevity, we will use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed.
+While it is possible to create your own image with custom PHP and Node.js versions, for brevity we use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed.
 
 ```yaml
 image: tetraweb/php
 ```
 
-The next step is to install zip/unzip packages and make composer available. We will place these in the `before_script` section:
+The next step is to install zip/unzip packages and make composer available. We place these in the `before_script` section:
 
 ```yaml
 before_script:
@@ -26,7 +26,7 @@ before_script:
   - php -r "unlink('composer-setup.php');"
 ```
 
-This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies and `npm install` to load Node.js packages, then run the `npm` script. We need to append them into `before_script` section:
+This makes sure we have all requirements ready. Next, run `composer install` to fetch all PHP dependencies and `npm install` to load Node.js packages. Then run the `npm` script. We need to append them into `before_script` section:
 
 ```yaml
 before_script:
@@ -43,19 +43,19 @@ In this particular case, the `npm deploy` script is a Gulp script that does the
 1. Copy various assets (images, fonts) around
 1. Replace some strings
 
-All these operations will put all files into a `build` folder, which is ready to be deployed to a live server.
+All these operations put all files into a `build` folder, which is ready to be deployed to a live server.
 
 ## How to transfer files to a live server
 
-You have multiple options: rsync, SCP, SFTP, and so on. For now, we will use SCP.
+You have multiple options: rsync, SCP, SFTP, and so on. For now, use SCP.
 
-To make this work, you need to add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). That variable will be called `STAGING_PRIVATE_KEY` and it's the  **private** SSH key of your server.
+To make this work, you must add a GitLab CI/CD Variable (accessible on `gitlab.example/your-project-name/variables`). Name this variable `STAGING_PRIVATE_KEY` and set it to the **private** SSH key of your server.
 
 ### Security tip
 
 Create a user that has access **only** to the folder that needs to be updated.
 
-After you create that variable, you need to make sure that key will be added to the Docker container on run:
+After you create that variable, make sure that key is added to the Docker container on run:
 
 ```yaml
 before_script:
@@ -71,7 +71,7 @@ In order, this means that:
 1. We check if the `ssh-agent` is available and we install it if it's not.
 1. We create the `~/.ssh` folder.
 1. We make sure we're running bash.
-1. We disable host checking (we don't ask for user accept when we first connect to a server and since every job will equal a first connect, we kind of need this).
+1. We disable host checking (we don't ask for user accept when we first connect to a server, and since every job equals a first connect, we need this).
 
 And this is basically all you need in the `before_script` section.
 
@@ -96,14 +96,14 @@ stage_deploy:
 
 Here's the breakdown:
 
-1. `only:dev` means that this build will run only when something is pushed to the `dev` branch. You can remove this block completely and have everything be ran on every push (but probably this is something you don't want)
-1. `ssh-add ...` we will add that private key you added on the web UI to the Docker container
-1. We will connect via `ssh` and create a new `_tmp` folder
-1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
-1. We will connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
-1. We connect to SSH and remove the `_old` folder
+1. `only:dev` means that this build runs only when something is pushed to the `dev` branch. You can remove this block completely and have everything run on every push (but probably this is something you don't want).
+1. `ssh-add ...` we add that private key you added on the web UI to the Docker container.
+1. We connect via `ssh` and create a new `_tmp` folder.
+1. We connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder.
+1. We connect again via `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
+1. We connect to SSH and remove the `_old` folder.
 
-What's the deal with the artifacts? We just tell GitLab CI/CD to keep the `build` directory (later on, you can download that as needed).
+What's the deal with the artifacts? We tell GitLab CI/CD to keep the `build` directory (later on, you can download that as needed).
 
 ### Why we do it this way
 
@@ -114,7 +114,7 @@ If you're using this only for stage server, you could do this in two steps:
 - scp -P22 -r build/* server_user@server_host:htdocs/wp-content/themes/live
 ```
 
-The problem is that there will be a small period of time when you won't have the app on your server.
+The problem is that there's a small period of time when you don't have the app on your server.
 
 Therefore, for a production environment we use additional steps to ensure that at any given time, a functional app is in place.
 
@@ -122,13 +122,13 @@ Therefore, for a production environment we use additional steps to ensure that a
 
 Since this was a WordPress project, I gave real life code snippets. Some further ideas you can pursue:
 
-- Having a slightly different script for `master` branch will allow you to deploy to a production server from that branch and to a stage server from any other branches.
+- Having a slightly different script for `master` branch allows you to deploy to a production server from that branch and to a stage server from any other branches.
 - Instead of pushing it live, you can push it to WordPress official repository (with creating a SVN commit, etc.).
 - You could generate i18n text domains on the fly.
 
 ---
 
-Our final `.gitlab-ci.yml` will look like this:
+Our final `.gitlab-ci.yml` looks like this:
 
 ```yaml
 image: tetraweb/php

doc/ci/review_apps/index.md

@@ -69,7 +69,7 @@ The process of configuring Review Apps is as follows:
 
 When configuring Review Apps for a project, you need to add a new job to `.gitlab-ci.yml`,
 as mentioned above. To facilitate this and if you are using Kubernetes, you can click
-the **Enable Review Apps** button and GitLab will prompt you with a template code block that
+the **Enable Review Apps** button and GitLab prompts you with a template code block that
 you can copy and paste into `.gitlab-ci.yml` as a starting point. To do so:
 
 1. Go to the project your want to create a Review App job for.
@@ -115,7 +115,7 @@ and faster to preview proposed modifications.
 
 Configuring Route Maps involves telling GitLab how the paths of files
 in your repository map to paths of pages on your website using a Route Map.
-Once set, GitLab will display **View on ...** buttons, which will take you
+Once set, GitLab displays **View on ...** buttons, which take you
 to the pages changed directly from merge requests.
 
 To set up a route map, add a file inside the repository at `.gitlab/route-map.yml`,
@@ -165,15 +165,15 @@ The public path for a source path is determined by finding the first
 
 In the example above, the fact that mappings are evaluated in order
 of their definition is used to ensure that `source/index.html.haml`
-will match `/source\/(.+?\.html).*/` instead of `/source\/(.*)/`,
-and will result in a public path of `index.html`, instead of
+matches `/source\/(.+?\.html).*/` instead of `/source\/(.*)/`,
+and results in a public path of `index.html`, instead of
 `index.html.haml`.
 
-After you have the route mapping set up, it will take effect in the following locations:
+After you have the route mapping set up, it takes effect in the following locations:
 
 - In the merge request widget. The:
-  - **View app** button will take you to the environment URL set in `.gitlab-ci.yml`.
-  - Dropdown will list the first 5 matched items from the route map, but you can filter them if more
+  - **View app** button takes you to the environment URL set in `.gitlab-ci.yml`.
+  - Dropdown lists the first 5 matched items from the route map, but you can filter them if more
     than 5 are available.
 
     ![View app file list in merge request widget](img/view_on_mr_widget.png)
@@ -221,7 +221,7 @@ To see Visual reviews in action, see the [Visual Reviews Walk through](https://y
 The feedback form is served through a script you add to pages in your Review App.
 If you have [Developer permissions](../../user/permissions.md) to the project,
 you can access it by clicking the **Review** button in the **Pipeline** section
-of the merge request. The form modal will also show a dropdown for changed pages
+of the merge request. The form modal also shows a dropdown for changed pages
 if [route maps](#route-maps) are configured in the project.
 
 ![review button](img/review_button.png)
@@ -251,13 +251,13 @@ to replace those values at runtime when each review app is created:
   `CI_MERGE_REQUEST_IID` variable. `CI_MERGE_REQUEST_IID` is available only if
   [`only: [merge_requests]`](../merge_request_pipelines/index.md)
   is used and the merge request is created.
-- `data-mr-url` is the URL of the GitLab instance and will be the same for all
+- `data-mr-url` is the URL of the GitLab instance and is the same for all
   review apps.
 - `data-project-path` is the project's path, which can be found by `CI_PROJECT_PATH`.
-- `data-require-auth` is optional for public projects but required for [private and internal ones](#authentication-for-visual-reviews). If this is set to `true`, the user will be required to enter their [personal access token](../../user/profile/personal_access_tokens.md) instead of their name and email.
+- `data-require-auth` is optional for public projects but required for [private and internal ones](#authentication-for-visual-reviews). If this is set to `true`, the user is required to enter their [personal access token](../../user/profile/personal_access_tokens.md) instead of their name and email.
 - `id` is always `review-app-toolbar-script`, you don't need to change that.
 - `src` is the source of the review toolbar script, which resides in the
-  respective GitLab instance and will be the same for all review apps.
+  respective GitLab instance and is the same for all review apps.
 
 For example, in a Ruby application with code hosted on in a project GitLab.com, you would need to have this script:
 

doc/development/cicd/templates.md

@@ -34,7 +34,7 @@ Also, all templates must be named with the `*.gitlab-ci.yml` suffix.
 ### Backward compatibility
 
 A template might be dynamically included with the `include:template:` keyword. If
-you make a change to an *existing* template, you **must** make sure that it won't break
+you make a change to an *existing* template, you **must** make sure that it doesn't break
 CI/CD in existing projects.
 
 For example, changing a job name in a template could break pipelines in an existing project.
@@ -59,7 +59,7 @@ performance:
 ```
 
 If the job name `performance` in the template is renamed to `browser-performance`,
-user's `.gitlab-ci.yml` will immediately cause a lint error because there
+the user's `.gitlab-ci.yml` immediately causes a lint error because there
 are no such jobs named `performance` in the included template anymore. Therefore,
 users have to fix their `.gitlab-ci.yml` that could annoy their workflow.
 
@@ -111,7 +111,7 @@ If the `latest` template does not exist yet, you can copy [the stable template](
 
 Users may want to use an older [stable template](#stable-version) that is not bundled
 in the current GitLab package. For example, the stable templates in GitLab v13.0 and
-GitLab v14.0 could be so different that a user will want to continue using the v13.0 template even
+GitLab v14.0 could be so different that a user wants to continue using the v13.0 template even
 after upgrading to GitLab 14.0.
 
 You can add a note in the template or in documentation explaining how to use `include:remote`
@@ -160,7 +160,7 @@ When you add a template into one of those directories, make sure that it correct
 
 ### Write an RSpec test
 
-You should write an RSpec test to make sure that pipeline jobs will be generated correctly:
+You should write an RSpec test to make sure that pipeline jobs are generated correctly:
 
 1. Add a test file at `spec/lib/gitlab/ci/templates/<template-category>/<template-name>_spec.rb`
 1. Test that pipeline jobs are properly created via `Ci::CreatePipelineService`.
@@ -171,10 +171,10 @@ When you introduce a breaking change to [a `latest` template](#latest-version),
 you must:
 
 1. Test the upgrade path from [the stable template](#stable-version).
-1. Verify what kind of errors users will encounter.
+1. Verify what kind of errors users encounter.
 1. Document it as a troubleshooting guide.
 
-This information will be important for users when [a stable template](#stable-version)
+This information is important for users when [a stable template](#stable-version)
 is updated in a major version GitLab release.
 
 ## Security

doc/integration/vault.md

@@ -13,12 +13,12 @@ type: reference, howto
 It allows you to store and manage sensitive information such as secret environment variables, encryption keys, and authentication tokens.
 Vault offers Identity-based Access, which means Vault users can authenticate through several of their preferred cloud providers.
 
-In this document, we'll explain how Vault users can authenticate themselves through GitLab by utilizing our OpenID authentication feature.
+This document explains how Vault users can authenticate themselves through GitLab by utilizing our OpenID authentication feature.
 The following assumes you already have Vault installed and running.
 
 1. **Get the OpenID Connect client ID and secret from GitLab:**
 
-   First you'll need to create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
+   First you must create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
 
    1. On GitLab, click your avatar on the top-right corner, and select your user **Settings > Applications**.
    1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt#redirect-uris),
@@ -71,7 +71,7 @@ The following assumes you already have Vault installed and running.
 
    Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
 
-   This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.
+   This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we show how you can access this role through the Vault CLI.
 
    ```shell
    vault write auth/oidc/role/demo \
@@ -88,11 +88,11 @@ The following assumes you already have Vault installed and running.
 
    1. Go to your Vault UI (example: [http://127.0.0.1:8200/ui/vault/auth?with=oidc](http://127.0.0.1:8200/ui/vault/auth?with=oidc)).
    1. If the `OIDC` method is not currently selected, open the dropdown and select it.
-   1. Click the **Sign in With GitLab** button, which will open a modal window:
+   1. Click the **Sign in With GitLab** button, which opens a modal window:
 
       ![Sign into Vault with GitLab](img/sign_into_vault_with_gitlab_v12_6.png)
 
-   1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This will redirect you back to your Vault UI as a signed-in user.
+   1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This redirects you back to your Vault UI as a signed-in user.
 
       ![Authorize Vault to connect with GitLab](img/authorize_vault_with_gitlab_v12_6.png)
 
@@ -116,12 +116,12 @@ The following assumes you already have Vault installed and running.
       another port number that matches the port given to GitLab when listing
       [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
 
-   After running the command, it will present a link in the terminal.
-   Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
+   After running the command, it presents a link in the terminal.
+   Click the link in the terminal and a browser tab opens that confirms you're signed into Vault via OIDC:
 
    ![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
 
-   The terminal will output:
+   The terminal outputs:
 
    ```plaintext
    Success! You are now authenticated. The token information displayed below

doc/operations/feature_flags.md

@@ -226,9 +226,9 @@ To remove users from a user list:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8240) in GitLab 12.2.
 > - [Made read-only](https://gitlab.com/gitlab-org/gitlab/-/issues/220228) in GitLab 13.4.
 
-In GitLab 13.0 and earlier, the **Rollout strategy** setting affects which users will experience
-the feature as enabled. Choose the percentage of users that the feature will be enabled
-for. The rollout strategy will have no effect if the environment spec is disabled.
+In GitLab 13.0 and earlier, the **Rollout strategy** setting affects which users experience
+the feature as enabled. Choose the percentage of users that the feature is enabled
+for. The rollout strategy has no effect if the environment spec is disabled.
 
 It can be set to:
 
@@ -282,7 +282,7 @@ To get the access credentials that your application needs to communicate with Gi
      could be `production` or similar. This value is used for the environment spec evaluation.
 
 Note that the meaning of these fields might change over time. For example, we're not sure if
-**Instance ID** will be single token or multiple tokens, assigned to the **Environment**. Also,
+**Instance ID** is a single token or multiple tokens, assigned to the **Environment**. Also,
 **Application name** could describe the application version instead of the running environment.
 
 ### Choose a client library

doc/user/project/deploy_boards.md

@@ -54,8 +54,8 @@ specific environment, there are a lot of use cases. To name a few:
 - You want to promote what's running in staging, to production. You go to the
   environments list, verify that what's running in staging is what you think is
   running, then click on the [manual action](../../ci/yaml/README.md#whenmanual) to deploy to production.
-- You trigger a deploy, and you've got lots of containers to upgrade so you know
-  it'll take a while (you've also throttled your deploy to only take down X
+- You trigger a deploy, and you have many containers to upgrade so you know
+  this takes a while (you've also throttled your deploy to only take down X
   containers at a time). But you need to tell someone when it's deployed, so you
   go to the environments list, look at the production environment to see what
   the progress is in real-time as each pod is rolled.
@@ -76,8 +76,8 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
 1. Have a Kubernetes cluster up and running.
 
    NOTE:
-   If you are using OpenShift, ensure that you're using the `Deployment` resource
-   instead of `DeploymentConfiguration`. Otherwise, the Deploy Boards won't render
+   If you're using OpenShift, ensure that you're using the `Deployment` resource
+   instead of `DeploymentConfiguration`. Otherwise, the Deploy Boards don't render
    correctly. For more information, read the
    [OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
    and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab/-/issues/4584).
@@ -85,7 +85,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
 1. [Configure GitLab Runner](../../ci/runners/README.md) with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
    [`kubernetes`](https://docs.gitlab.com/runner/executors/kubernetes.html) executor.
 1. Configure the [Kubernetes integration](clusters/index.md) in your project for the
-   cluster. The Kubernetes namespace is of particular note as you will need it
+   cluster. The Kubernetes namespace is of particular note as you need it
    for your deployment scripts (exposed by the `KUBE_NAMESPACE` environment variable).
 1. Ensure Kubernetes annotations of `app.gitlab.com/env: $CI_ENVIRONMENT_SLUG`
    and `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG` are applied to the
@@ -95,7 +95,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
    than one. These resources should be contained in the namespace defined in
    the Kubernetes service setting. You can use an [Autodeploy](../../topics/autodevops/stages.md#auto-deploy) `.gitlab-ci.yml`
    template which has predefined stages and commands to use, and automatically
-   applies the annotations. Each project will need to have a unique namespace in
+   applies the annotations. Each project must have a unique namespace in
    Kubernetes as well. The image below demonstrates how this is shown inside
    Kubernetes.
 
@@ -106,7 +106,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
    re-deploy your application. If you are using Auto DevOps, this will
    be done automatically and no action is necessary.
 
-   If you are using GCP to manage clusters, you can see the deployment details in GCP itself by going to **Workloads > deployment name > Details**:
+   If you use GCP to manage clusters, you can see the deployment details in GCP itself by navigating to **Workloads > deployment name > Details**:
 
    ![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
 
@@ -142,7 +142,7 @@ spec:
         app.gitlab.com/env: ${CI_ENVIRONMENT_SLUG}
 ```
 
-The annotations will be applied to the deployments, replica sets, and pods. By changing the number of replicas, like `kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}`, you can follow the instances' pods from the board.
+The annotations are applied to the deployments, replica sets, and pods. By changing the number of replicas, like `kubectl scale --replicas=3 deploy APPLICATION_NAME -n ${KUBE_NAMESPACE}`, you can follow the instances' pods from the board.
 
 NOTE:
 The YAML file is static. If you apply it using `kubectl apply`, you must

doc/user/project/deploy_keys/index.md

@@ -92,7 +92,7 @@ There are three lists of Project Deploy Keys:
 
 ![Deploy Keys section](img/deploy_keys_v13_0.png)
 
-After you add a key, it will be enabled for this project by default, and it'll appear
+After you add a key, it's enabled for this project by default and it appears
 in the **Enabled deploy keys** tab.
 
 In the **Privately accessible deploy keys** tab, you can enable a private key which
@@ -111,7 +111,7 @@ and `read-write` access.
 NOTE:
 If you have enabled a privately or publicly accessible or deploy key for your
 project, and if you then update the access level for this key from `read-only` to
-`read-write`, the change will be only for the **current project**.
+`read-write`, the change is only for the **current project**.
 
 ### Public deploy keys
 
@@ -131,7 +131,7 @@ Instance administrators can add public deploy keys:
 
 ![Public Deploy Keys section](img/public_deploy_key_v13_0.png)
 
-After adding a key, it will be available to any shared systems. Project maintainers
+After adding a key, it's available to any shared systems. Project maintainers
 or higher can [authorize a public deploy key](#project-deploy-keys) to start using it with the project.
 
 NOTE:
@@ -155,8 +155,8 @@ until a project maintainer chooses to make use of it.
 
 ### Deploy Key cannot push to a protected branch
 
-If the owner of this deploy key does not have access to a [protected
-branch](../protected_branches.md), then this deploy key won't have access to
+If the owner of this deploy key doesn't have access to a [protected
+branch](../protected_branches.md), then this deploy key doesn't have access to
 the branch either. In addition to this, choosing the **No one** value in
 [the "Allowed to push" section](../protected_branches.md#configuring-protected-branches)
 means that no users **and** no services using deploy keys can push to that selected branch.

doc/user/project/deploy_tokens/index.md

@@ -36,7 +36,7 @@ project. Alternatively, you can also create [group-scoped deploy tokens](#group-
 1. Choose the [desired scopes](#limiting-scopes-of-a-deploy-token).
 1. Select **Create deploy token**.
 1. Save the deploy token somewhere safe. After you leave or refresh
-   the page, **you won't be able to access it again**.
+   the page, **you can't access it again**.
 
 ![Personal access tokens page](img/deploy_tokens_ui.png)
 
@@ -89,7 +89,7 @@ Replace `<username>` and `<deploy_token>` with the proper values.
 
 ### Read Container Registry images
 
-To read the container registry images, you'll need to:
+To read the container registry images, you must:
 
 1. Create a Deploy Token with `read_registry` as a scope.
 1. Take note of your `username` and `token`.
@@ -106,7 +106,7 @@ pull images from your Container Registry.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22743) in GitLab 12.10.
 
-To push the container registry images, you'll need to:
+To push the container registry images, you must:
 
 1. Create a Deploy Token with `write_registry` as a scope.
 1. Take note of your `username` and `token`.
@@ -123,7 +123,7 @@ push images to your Container Registry.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) in GitLab 13.0.
 
-To pull packages in the GitLab package registry, you'll need to:
+To pull packages in the GitLab package registry, you must:
 
 1. Create a Deploy Token with `read_package_registry` as a scope.
 1. Take note of your `username` and `token`.
@@ -134,7 +134,7 @@ To pull packages in the GitLab package registry, you'll need to:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) in GitLab 13.0.
 
-To upload packages in the GitLab package registry, you'll need to:
+To upload packages in the GitLab package registry, you must:
 
 1. Create a Deploy Token with `write_package_registry` as a scope.
 1. Take note of your `username` and `token`.
@@ -160,7 +160,7 @@ To use a group deploy token:
 1. Use it the same way you use a project deploy token when
    [cloning a repository](#git-clone-a-repository).
 
-The scopes applied to a group deploy token (such as `read_repository`) will
+The scopes applied to a group deploy token (such as `read_repository`)
 apply consistently when cloning the repository of related projects.
 
 ### GitLab Deploy Token
@@ -168,7 +168,7 @@ apply consistently when cloning the repository of related projects.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18414) in GitLab 10.8.
 
 There's a special case when it comes to Deploy Tokens. If a user creates one
-named `gitlab-deploy-token`, the username and token of the Deploy Token will be
+named `gitlab-deploy-token`, the username and token of the Deploy Token is
 automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER`
 and `CI_DEPLOY_PASSWORD`, respectively.
 

doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md

@@ -24,7 +24,7 @@ GitLab Pages site.
 Note that **how to** add DNS records depends on which server your domain
 is hosted on. Every control panel has its own place to do it. If you are
 not an administrator of your domain, and don't have access to your registrar,
-you'll need to ask for the technical support of your hosting service
+you must ask the technical support of your hosting service
 to do it for you.
 
 To help you out, we've gathered some instructions on how to do that
@@ -67,7 +67,7 @@ Example:
 
 - `www` => `CNAME` => `example.com`
 
-This way, visitors visiting `www.example.com` will be redirected to
+This way, visitors visiting `www.example.com` are redirected to
 `example.com`.
 
 ## MX record

doc/user/project/pages/custom_domains_ssl_tls_certification/index.md

@@ -47,7 +47,8 @@ Click **Create New Domain**.
 
 #### 2. Get the verification code
 
-Once you have added a new domain to Pages, the verification code will be prompted to you. Copy the values from GitLab and paste them in your domain's control panel as a TXT record on the next step.
+After you add a new domain to Pages, the verification code prompts you. Copy the values from GitLab
+and paste them in your domain's control panel as a TXT record on the next step.
 
 ![Get the verification code](img/get_domain_verification_code_v12_0.png)
 
@@ -91,7 +92,7 @@ add a DNS apex `CNAME` record instead of an `A` record. The main
 advantage of doing so is that when GitLab Pages IP on GitLab.com
 changes for whatever reason, you don't need to update your `A` record.
 There may be a few exceptions, but **this method is not recommended**
-as it most likely won't work if you set an [`MX` record](dns_concepts.md#mx-record) for your root domain.
+as it most likely doesn't work if you set an [`MX` record](dns_concepts.md#mx-record) for your root domain.
 
 ##### For subdomains
 
@@ -154,12 +155,11 @@ Once you have added all the DNS records:
 
 ![Verify your domain](img/retry_domain_verification_v12_0.png)
 
-As soon as your domain becomes active, your website will be available
-through your domain name.
+As soon as your domain becomes active, your website is available through your domain name.
 
 WARNING:
 Considering GitLab instances with domain verification enabled,
-if the domain cannot be verified for 7 days, it will be removed
+if the domain can't be verified for 7 days, it's removed
 from the GitLab project.
 
 > **Notes:**
@@ -169,9 +169,9 @@ from the GitLab project.
   to [disabled custom domain verification](../../../../administration/pages/index.md#custom-domain-verification).
 > - [DNS propagation may take some time (up to 24h)](https://www.inmotionhosting.com/support/domain-names/dns-nameserver-changes/complete-guide-to-dns-records/),
   although it's usually a matter of minutes to complete. Until it does, verification
-  will fail and attempts to visit your domain will respond with a 404.
+  fails, and attempts to visit your domain result in a 404.
 > - Once your domain has been verified, leave the verification record
-  in place: your domain will be periodically reverified, and may be
+  in place. Your domain is periodically reverified, and may be
   disabled if the record is removed.
 
 ##### Troubleshooting Pages domain verification
@@ -211,7 +211,7 @@ For a subdomain:
 You can add more than one alias (custom domains and subdomains) to the same project.
 An alias can be understood as having many doors leading to the same room.
 
-All the aliases you've set to your site will be listed on **Setting > Pages**.
+All the aliases you've set to your site are listed on **Setting > Pages**.
 From that page, you can view, add, and remove them.
 
 ### Redirecting `www.domain.com` to `domain.com` with Cloudflare
@@ -294,7 +294,7 @@ Sublime Text, Atom, Dreamweaver, Brackets, etc).
 
 To make your website's visitors even more secure, you can choose to
 force HTTPS for GitLab Pages. By doing so, all attempts to visit your
-website via HTTP will be automatically redirected to HTTPS via 301.
+website through HTTP are automatically redirected to HTTPS through 301.
 
 It works with both the GitLab default domain and with your custom
 domain (as long as you've set a valid certificate for it).

doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md

@@ -50,15 +50,15 @@ Once you've met the requirements, enable Let's Encrypt integration:
 
 1. Click **Save changes**.
 
-Once enabled, GitLab will obtain a LE certificate and add it to the
-associated Pages domain. It also will be renewed automatically by GitLab.
+Once enabled, GitLab obtains a LE certificate and add it to the
+associated Pages domain. GitLab also renews it automatically.
 
 > **Notes:**
 >
 > - Issuing the certificate and updating Pages configuration
 >   **can take up to an hour**.
-> - If you already have SSL certificate in domain settings it
->   will continue to work until it will be replaced by Let's Encrypt's certificate.
+> - If you already have an SSL certificate in domain settings it
+>   continues to work until replaced by the Let's Encrypt's certificate.
 
 ## Troubleshooting
 

doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md

@@ -10,10 +10,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 _Read this document for a brief overview of SSL/TLS certificates in
 the scope of GitLab Pages, for beginners in web development._
 
-Every GitLab Pages project on GitLab.com will be available under
+Every GitLab Pages project on GitLab.com is available under
 HTTPS for the default Pages domain (`*.gitlab.io`). Once you set
 up your Pages project with your custom (sub)domain, if you want
-it secured by HTTPS, you will have to issue a certificate for that
+it secured by HTTPS, you must issue a certificate for that
 (sub)domain and install it on your project.
 
 NOTE:
@@ -41,9 +41,6 @@ the connection between the **client** (you, me, your visitors)
 and the **server** (where you site lives), through a keychain of
 authentications and validations.
 
-How about taking Josh's advice and protecting our sites too? We will be
-well supported, and we'll contribute to a safer internet.
-
 ## Organizations supporting HTTPS
 
 There is a huge movement in favor of securing all the web. W3C fully
@@ -62,8 +59,8 @@ GitLab Pages accepts certificates provided in the [PEM](https://knowledge.digice
 for public websites for security reasons and to ensure that browsers trust your site's certificate.
 
 There are various kinds of certificates, each one
-with a certain security level. A static personal website will
-not require the same security level as an online banking web app,
+with a certain security level. A static personal website doesn't
+require the same security level as an online banking web app,
 for instance.
 
 There are some certificate authorities that

doc/user/project/pages/getting_started/pages_ci_cd_template.md

@@ -41,7 +41,7 @@ configuration for the Pages site to generate properly.
 
 If everything is configured correctly, the site can take approximately 30 minutes to deploy.
 
-You can watch the pipeline run by going to **CI / CD > Pipelines**.
+You can watch the pipeline run by navigating to **CI / CD > Pipelines**.
 When the pipeline is finished, go to **Settings > Pages** to find the link to
 your Pages website.
 

doc/user/project/pages/getting_started/pages_forked_sample_project.md

@@ -17,7 +17,7 @@ configured to generate a Pages site.
 
 To fork a sample project and create a Pages website:
 
-1. View the sample projects by going to the [GitLab Pages examples](https://gitlab.com/pages) group.
+1. View the sample projects by navigating to the [GitLab Pages examples](https://gitlab.com/pages) group.
 1. Click the name of the project you want to [fork](../../../../gitlab-basics/fork-project.md).
 1. In the top right, click the **Fork** button, and then choose a namespace to fork to.
 1. Go to your project's **CI/CD > Pipelines** and click **Run pipeline**.

doc/user/project/pages/getting_started/pages_from_scratch.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Create a GitLab Pages website from scratch
 
-This tutorial shows you how to create a Pages site from scratch. You will start with
+This tutorial shows you how to create a Pages site from scratch. You start with
 a blank project and create your own CI file, which gives instruction to
 a [runner](https://docs.gitlab.com/runner/). When your CI/CD
 [pipeline](../../../../ci/pipelines/index.md) runs, the Pages site is created.
@@ -218,7 +218,7 @@ There are three default stages for GitLab CI/CD: build, test,
 and deploy.
 
 If you want to test your script and check the built site before deploying
-to production, you can run the test exactly as it will run when you
+to production, you can run the test exactly as it runs when you
 push to `master`.
 
 To specify a stage for your job to run in,
@@ -376,7 +376,7 @@ test:
 
 In this case, you need to exclude the `/vendor`
 directory from the list of folders Jekyll builds. Otherwise, Jekyll
-will try to build the directory contents along with the site.
+tries to build the directory contents along with the site.
 
 In the root directory, create a file called `_config.yml`
 and add this content:

doc/user/project/pages/getting_started_part_one.md

@@ -16,7 +16,7 @@ wildcard domain with your sysadmin. This guide is valid for any GitLab instance,
 replace the Pages wildcard domain on GitLab.com (`*.gitlab.io`) with your own.
 
 If you set up a GitLab Pages project on GitLab,
-it will automatically be accessible under a
+it's automatically accessible under a
 subdomain of `namespace.example.io`.
 The [`namespace`](../../group/index.md#namespaces)
 is defined by your username on GitLab.com,
@@ -45,35 +45,35 @@ To understand Pages domains clearly, read the examples below.
 - You created a project called `blog` under your username `john`,
   therefore your project URL is `https://gitlab.com/john/blog/`.
   Once you enable GitLab Pages for this project, and build your site,
-  it will be available under `https://john.gitlab.io/blog/`.
+  you can access it at `https://john.gitlab.io/blog/`.
 - You created a group for all your websites called `websites`,
   and a project within this group is called `blog`. Your project
   URL is `https://gitlab.com/websites/blog/`. Once you enable
-  GitLab Pages for this project, the site will live under
+  GitLab Pages for this project, the site is available at
   `https://websites.gitlab.io/blog/`.
 - You created a group for your engineering department called `engineering`,
   a subgroup for all your documentation websites called `docs`,
   and a project within this subgroup is called `workflows`. Your project
   URL is `https://gitlab.com/engineering/docs/workflows/`. Once you enable
-  GitLab Pages for this project, the site will live under
+  GitLab Pages for this project, the site is available at
   `https://engineering.gitlab.io/docs/workflows`.
 
 ### User and Group website examples
 
 - Under your username, `john`, you created a project called
-  `john.gitlab.io`. Your project URL will be `https://gitlab.com/john/john.gitlab.io`.
+  `john.gitlab.io`. Your project URL is `https://gitlab.com/john/john.gitlab.io`.
   Once you enable GitLab Pages for your project, your website
-  will be published under `https://john.gitlab.io`.
+  is published under `https://john.gitlab.io`.
 - Under your group `websites`, you created a project called
-  `websites.gitlab.io`. your project's URL will be `https://gitlab.com/websites/websites.gitlab.io`.
+  `websites.gitlab.io`. Your project's URL is `https://gitlab.com/websites/websites.gitlab.io`.
   Once you enable GitLab Pages for your project,
-  your website will be published under `https://websites.gitlab.io`.
+  your website is published under `https://websites.gitlab.io`.
 
 **General example:**
 
-- On GitLab.com, a project site will always be available under
+- On GitLab.com, a project site is always available under
   `https://namespace.gitlab.io/project-name`
-- On GitLab.com, a user or group website will be available under
+- On GitLab.com, a user or group website is available under
   `https://namespace.gitlab.io/`
 - On your GitLab instance, replace `gitlab.io` above with your
   Pages server domain. Ask your sysadmin for this information.
@@ -87,7 +87,7 @@ Every Static Site Generator (SSG) default configuration expects
 to find your website under a (sub)domain (`example.com`), not
 in a subdirectory of that domain (`example.com/subdir`). Therefore,
 whenever you publish a project website (`namespace.gitlab.io/project-name`),
-you'll have to look for this configuration (base URL) on your SSG's
+you must look for this configuration (base URL) on your SSG's
 documentation and set it up to reflect this pattern.
 
 For example, for a Jekyll site, the `baseurl` is defined in the Jekyll
@@ -99,11 +99,11 @@ baseurl: "/blog"
 ```
 
 On the contrary, if you deploy your website after forking one of
-our [default examples](https://gitlab.com/pages), the `baseurl` will
-already be configured this way, as all examples there are project
-websites. If you decide to make yours a user or group website, you'll
-have to remove this configuration from your project. For the Jekyll
-example we've just mentioned, you'd have to change Jekyll's `_config.yml` to:
+our [default examples](https://gitlab.com/pages), the `baseurl` is
+already configured this way, as all examples there are project
+websites. If you decide to make yours a user or group website, you
+must remove this configuration from your project. For the Jekyll
+example we just mentioned, you must change Jekyll's `_config.yml` to:
 
 ```yaml
 baseurl: ""

doc/user/project/pages/index.md

@@ -81,10 +81,12 @@ becomes available automatically.
 To deploy your site, GitLab uses its built-in tool called [GitLab CI/CD](../../../ci/README.md)
 to build your site and publish it to the GitLab Pages server. The sequence of
 scripts that GitLab CI/CD runs to accomplish this task is created from a file named
-`.gitlab-ci.yml`, which you can [create and modify](getting_started/pages_from_scratch.md) at will. A specific `job` called `pages` in the configuration file will make GitLab aware that you are deploying a GitLab Pages website.
+`.gitlab-ci.yml`, which you can [create and modify](getting_started/pages_from_scratch.md).
+A specific `job` called `pages` in the configuration file makes GitLab aware that you're deploying a
+GitLab Pages website.
 
 You can either use the GitLab [default domain for GitLab Pages websites](getting_started_part_one.md#gitlab-pages-default-domain-names),
-`*.gitlab.io`, or your own domain (`example.com`). In that case, you'll
+`*.gitlab.io`, or your own domain (`example.com`). In that case, you
 need administrator access to your domain's registrar (or control panel) to set it up with Pages.
 
 The following diagrams show the workflows you might follow to get started with Pages.
@@ -94,15 +96,15 @@ The following diagrams show the workflows you might follow to get started with P
 ## Access to your Pages site
 
 If you're using GitLab Pages default domain (`.gitlab.io`),
-your website will be automatically secure and available under
+your website is automatically secure and available under
 HTTPS. If you're using your own custom domain, you can
 optionally secure it with SSL/TLS certificates.
 
-If you're using GitLab.com, your website will be publicly available to the internet.
+If you're using GitLab.com, your website is publicly available to the internet.
 To restrict access to your website, enable [GitLab Pages Access Control](pages_access_control.md).
 
 If you're using a self-managed instance (Core, Starter, Premium, or Ultimate),
-your websites will be published on your own server, according to the
+your websites are published on your own server, according to the
 [Pages settings](../../../administration/pages/index.md) chosen by your sysadmin,
 who can make them public or internal.
 

doc/user/project/pages/introduction.md

@@ -44,19 +44,19 @@ Visit the [GitLab Pages group](https://gitlab.com/groups/pages) for a complete l
 
 You can provide your own 403 and 404 error pages by creating the `403.html` and
 `404.html` files respectively in the root directory of the `public/` directory
-that will be included in the artifacts. Usually this is the root directory of
+that are included in the artifacts. Usually this is the root directory of
 your project, but that may differ depending on your static generator
 configuration.
 
 If the case of `404.html`, there are different scenarios. For example:
 
 - If you use project Pages (served under `/projectname/`) and try to access
-  `/projectname/non/existing_file`, GitLab Pages will try to serve first
+  `/projectname/non/existing_file`, GitLab Pages tries to serve first
   `/projectname/404.html`, and then `/404.html`.
 - If you use user/group Pages (served under `/`) and try to access
-  `/non/existing_file` GitLab Pages will try to serve `/404.html`.
+  `/non/existing_file` GitLab Pages tries to serve `/404.html`.
 - If you use a custom domain and try to access `/non/existing_file`, GitLab
-  Pages will try to serve only `/404.html`.
+  Pages tries to serve only `/404.html`.
 
 ## Redirects in GitLab Pages
 
@@ -71,8 +71,8 @@ To restrict access to your website, enable [GitLab Pages Access Control](pages_a
 
 If you ever feel the need to purge your Pages content, you can do so by going
 to your project's settings through the gear icon in the top right, and then
-navigating to **Pages**. Hit the **Remove pages** button and your Pages website
-will be deleted.
+navigating to **Pages**. Click the **Remove pages** button to delete your Pages
+website.
 
 ![Remove pages](img/remove_pages.png)
 
@@ -81,9 +81,9 @@ will be deleted.
 When using Pages under the general domain of a GitLab instance (`*.example.io`),
 you _cannot_ use HTTPS with sub-subdomains. That means that if your
 username or group name contains a dot, for example `foo.bar`, the domain
-`https://foo.bar.example.io` will _not_ work. This is a limitation of the
-[HTTP Over TLS protocol](https://tools.ietf.org/html/rfc2818#section-3.1). HTTP pages will continue to work provided you
-don't redirect HTTP to HTTPS.
+`https://foo.bar.example.io` does _not_ work. This is a limitation of the
+[HTTP Over TLS protocol](https://tools.ietf.org/html/rfc2818#section-3.1).
+HTTP pages continue to work provided you don't redirect HTTP to HTTPS.
 
 GitLab Pages [does **not** support group websites for subgroups](../../group/subgroups/index.md#limitations).
 You can only create the highest-level group website.
@@ -130,11 +130,11 @@ See this document for a [step-by-step guide](getting_started/pages_from_scratch.
 Remember that GitLab Pages are by default branch/tag agnostic and their
 deployment relies solely on what you specify in `.gitlab-ci.yml`. You can limit
 the `pages` job with the [`only` parameter](../../../ci/yaml/README.md#onlyexcept-basic),
-whenever a new commit is pushed to a branch that will be used specifically for
-your pages.
+whenever a new commit is pushed to a branch used specifically for your
+pages.
 
 That way, you can have your project's code in the `master` branch and use an
-orphan branch (let's name it `pages`) that will host your static generator site.
+orphan branch (let's name it `pages`) to host your static generator site.
 
 You can create a new empty branch like this:
 
@@ -142,9 +142,9 @@ You can create a new empty branch like this:
 git checkout --orphan pages
 ```
 
-The first commit made on this new branch will have no parents and it will be
-the root of a new history totally disconnected from all the other branches and
-commits. Push the source files of your static generator in the `pages` branch.
+The first commit made on this new branch has no parents and is the root of a
+new history totally disconnected from all the other branches and commits.
+Push the source files of your static generator in the `pages` branch.
 
 Below is a copy of `.gitlab-ci.yml` where the most significant line is the last
 one, specifying to execute everything in the `pages` branch:
@@ -172,9 +172,9 @@ also includes `.gitlab-ci.yml`.
 Most modern browsers support downloading files in a compressed format. This
 speeds up downloads by reducing the size of files.
 
-Before serving an uncompressed file, Pages will check whether the same file
-exists with a `.br` or `.gz` extension. If it does, and the browser supports receiving
-compressed files, it will serve that version instead of the uncompressed one.
+Before serving an uncompressed file, Pages checks if the same file exists with
+a `.br` or `.gz` extension. If it does, and the browser supports receiving
+compressed files, it serves that version instead of the uncompressed one.
 
 To take advantage of this feature, the artifact you upload to the Pages should
 have this structure:
@@ -236,10 +236,10 @@ public/
 ```
 
 Pages supports reaching each of these files through several different URLs. In
-particular, it will always look for an `index.html` file if the URL only
+particular, it always looks for an `index.html` file if the URL only
 specifies the directory. If the URL references a file that doesn't exist, but
-adding `.html` to the URL leads to a file that *does* exist, it will be served
-instead. Here are some examples of what will happen given the above Pages site:
+adding `.html` to the URL leads to a file that *does* exist, it's served
+instead. Here are some examples of what happens given the above Pages site:
 
 | URL path             | HTTP response | File served |
 | -------------------- | ------------- | ----------- |
@@ -275,7 +275,7 @@ to private, internal or public.
 
 ### Do I need to create a user/group website before creating a project website?
 
-No, you don't. You can create your project first and it will be accessed under
+No, you don't. You can create your project first and access it under
 `http(s)://namespace.example.io/projectname`.
 
 ## Known issues

doc/user/project/pages/lets_encrypt_for_gitlab_pages.md

@@ -61,7 +61,7 @@ might be slightly different. Follow the
    ```
 
    Alternatively, you can register without adding an e-mail account,
-   but you won't be notified about the certificate expiration's date:
+   but you aren't notified about the certificate expiration's date:
 
    ```shell
    sudo certbot certonly -a manual -d example.com --register-unsafely-without-email
@@ -71,10 +71,10 @@ might be slightly different. Follow the
    Read through CertBot's documentation on their
    [command line options](https://certbot.eff.org/docs/using.html#certbot-command-line-options).
 
-1. You'll be prompted with a message to agree with their terms.
+1. You're prompted with a message to agree with their terms.
    Press `A` to agree and `Y` to let they log your IP.
 
-   CertBot will then prompt you with the following message:
+   CertBot then prompts you with the following message:
 
    ```shell
    Create a file containing just this data:
@@ -88,7 +88,7 @@ might be slightly different. Follow the
    Press Enter to Continue
    ```
 
-1. **Do not press Enter yet.** Let's Encrypt will need to verify your
+1. **Do not press Enter yet.** Let's Encrypt needs to verify your
    domain ownership before issuing the certificate. To do so, create 3
    consecutive directories under your website's root:
    `/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP/`
@@ -107,7 +107,7 @@ might be slightly different. Follow the
 
 1. Add, commit, and push the file into your repository in GitLab. Once the pipeline
    passes, press **Enter** on your terminal to continue issuing your
-   certificate. CertBot will then prompt you with the following message:
+   certificate. CertBot then prompts you with the following message:
 
    ```shell
    Waiting for verification...
@@ -157,7 +157,7 @@ valid certificates)**.
 
 ## Renewal
 
-Let's Encrypt certificates expire every 90 days and you'll have to
+Let's Encrypt certificates expire every 90 days and you must
 renew them periodically. To renew all your certificates at once, run:
 
 ```shell

doc/user/project/pages/pages_access_control.md

@@ -28,20 +28,20 @@ For a demonstration, see [Pages access controls](https://www.youtube.com/watch?v
    with GitLab Pages, depending on your project's visibility:
 
    - If your project is private:
-     - **Only project members**: Only project members will be able to browse the website.
-     - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+     - **Only project members**: Only project members are able to browse the website.
+     - **Everyone**: Everyone, both logged into and logged out of GitLab, is able to browse the website, no matter their project membership.
    - If your project is internal:
-     - **Only project members**: Only project members will be able to browse the website.
-     - **Everyone with access**: Everyone logged into GitLab will be able to browse the website, no matter their project membership.
-     - **Everyone**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+     - **Only project members**: Only project members are able to browse the website.
+     - **Everyone with access**: Everyone logged into GitLab is able to browse the website, no matter their project membership.
+     - **Everyone**: Everyone, both logged into and logged out of GitLab, is able to browse the website, no matter their project membership.
    - If your project is public:
-     - **Only project members**: Only project members will be able to browse the website.
-     - **Everyone with access**: Everyone, both logged into and logged out of GitLab, will be able to browse the website, no matter their project membership.
+     - **Only project members**: Only project members are able to browse the website.
+     - **Everyone with access**: Everyone, both logged into and logged out of GitLab, is able to browse the website, no matter their project membership.
 
 1. Click **Save changes**.
 
 The next time someone tries to access your website and the access control is
-enabled, they will be presented with a page to sign into GitLab and verify they
+enabled, they're presented with a page to sign into GitLab and verify they
 can access the website.
 
 ## Terminating a Pages session

doc/user/project/releases/index.md

@@ -274,14 +274,11 @@ Release note descriptions are unrelated. Description supports [Markdown](../../m
 
 ### Release assets
 
-You can currently add the following types of assets to each release:
+You can add the following types of assets to each release:
 
 - [Source code](#source-code)
 - [Links](#links)
 
-GitLab will support more asset types in the future, including objects such
-as pre-built packages, compliance/security evidence, or container images.
-
 #### Permanent links to release assets
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27300) in GitLab 12.9.
@@ -336,8 +333,8 @@ The four types of links are "Runbook," "Package," "Image," and "Other."
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26019) in GitLab 12.6.
 
 Each time a release is created, GitLab takes a snapshot of data that's related to it.
-This data is saved in a JSON file and called *release evidence*. The feature currently
-includes test artifacts and linked milestones (and will include issues) to facilitate
+This data is saved in a JSON file and called *release evidence*. The feature
+includes test artifacts and linked milestones to facilitate
 internal processes, like external audits.
 
 To access the release evidence, on the Releases page, click the link to the JSON file that's listed