Merge branch 'docs-future-tense-release' into 'master'

Remove future tense from Release docs

See merge request gitlab-org/gitlab!50116

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/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