And yet more future tense in development docs

Cleaning up yet more future tense goodness.

doc/architecture/blueprints/cloud_native_build_logs/index.md

@@ -24,7 +24,7 @@ output to a file on a disk. This is simple, but this mechanism depends on
 shared local storage - the same file needs to be available on every GitLab web
 node machine, because GitLab Runner might connect to a different one every time
 it performs an API request. Sidekiq also needs access to the file because when
-a job is complete, a trace file contents will be sent to the object store.
+a job is complete, the trace file contents are sent to the object store.
 
 ## New architecture
 

doc/architecture/blueprints/cloud_native_gitlab_pages/index.md

@@ -72,9 +72,9 @@ of complexity, maintenance cost and enormous, negative impact on availability.
 
 ## New GitLab Pages Architecture
 
-- GitLab Pages is going to source domains' configuration from GitLab's internal
+- GitLab Pages sources domains' configuration from GitLab's internal
   API, instead of reading `config.json` files from a local shared storage.
-- GitLab Pages is going to serve static content from Object Storage.
+- GitLab Pages serves static content from Object Storage.
 
 ```mermaid
 graph TD

doc/architecture/blueprints/image_resizing/index.md

@@ -8,11 +8,11 @@ description: 'Image Resizing'
 
 # Image resizing for avatars and content images
 
-Currently, we are showing all uploaded images 1:1, which is of course not ideal. To improve performance greatly we will add image resizing to the backend. There are two main areas of image resizing to consider; avatars and content images. The MVC for this implementation will focus on Avatars. Avatars requests consist of approximately 70% of total image requests. There is an identified set of sizes we intend to support which makes the scope of this first MVC very narrow. Content image resizing has many more considerations for size and features. It is entirely possible that we have two separate development efforts with the same goal of increasing performance via image resizing.
+Currently, we are showing all uploaded images 1:1, which is of course not ideal. To improve performance greatly, add image resizing to the backend. There are two main areas of image resizing to consider; avatars and content images. The MVC for this implementation focuses on Avatars. Avatars requests consist of approximately 70% of total image requests. There is an identified set of sizes we intend to support which makes the scope of this first MVC very narrow. Content image resizing has many more considerations for size and features. It is entirely possible that we have two separate development efforts with the same goal of increasing performance via image resizing.
 
 ## MVC Avatar Resizing
 
-We will implement a dynamic image resizing solution. This means image should be resized and optimized on the fly so that if we define new targeted sizes later we can add them dynamically. This would mean a huge improvement in performance as some of the measurements suggest that we can save up to 95% of our current load size. Our initial investigations indicate that we have uploaded approximately 1.65 million avatars totaling approximately 80GB in size and averaging approximately 48kb each. Early measurements indicate we can reduce the most common avatar dimensions to between 1-3kb in size, netting us a greater than 90% size reduction. For the MVC we will not consider application level caching and rely purely on HTTP based caches as implemented in CDNs and browsers, but might revisit this decision later on. To easily mitigate performance issues with avatar resizing, especially in the case of self managed, an operations feature flag will be implemented to disable dynamic image resizing.
+When implementing a dynamic image resizing solution, images should be resized and optimized on the fly so that if we define new targeted sizes later we can add them dynamically. This would mean a huge improvement in performance as some of the measurements suggest that we can save up to 95% of our current load size. Our initial investigations indicate that we have uploaded approximately 1.65 million avatars totaling approximately 80GB in size and averaging approximately 48kb each. Early measurements indicate we can reduce the most common avatar dimensions to between 1-3kb in size, netting us a greater than 90% size reduction. For the MVC we don't consider application level caching and rely purely on HTTP based caches as implemented in CDNs and browsers, but might revisit this decision later on. To easily mitigate performance issues with avatar resizing, especially in the case of self managed, an operations feature flag is implemented to disable dynamic image resizing.
 
 ```mermaid
 sequenceDiagram

doc/raketasks/backup_restore.md

@@ -16,7 +16,7 @@ of GitLab on which it was created. The best way to migrate your repositories
 from one server to another is through backup restore.
 
 CAUTION: **Warning:**
-GitLab won't back up items that aren't stored in the filesystem. If you're
+GitLab doesn't back up items that aren't stored in the filesystem. If you're
 using [object storage](../administration/object_storage.md), be sure to enable
 backups with your object storage provider, if desired.
 
@@ -38,8 +38,8 @@ system. If you installed GitLab:
 
 ## Backup timestamp
 
-The backup archive will be saved in `backup_path`, which is specified in the
-`config/gitlab.yml` file. The filename will be `[TIMESTAMP]_gitlab_backup.tar`,
+The backup archive is saved in `backup_path`, which is specified in the
+`config/gitlab.yml` file. The filename is `[TIMESTAMP]_gitlab_backup.tar`,
 where `TIMESTAMP` identifies the time at which each backup was created, plus
 the GitLab version. The timestamp is needed if you need to restore GitLab and
 multiple backups are available.
@@ -112,8 +112,8 @@ kubectl exec -it <gitlab task-runner pod> backup-utility
 ```
 
 Similar to the Kubernetes case, if you have scaled out your GitLab cluster to
-use multiple application servers, you should pick a designated node (that won't
-be auto-scaled away) for running the backup Rake task. Because the backup Rake
+use multiple application servers, you should pick a designated node (that isn't
+auto-scaled away) for running the backup Rake task. Because the backup Rake
 task is tightly coupled to the main Rails application, this is typically a node
 on which you're also running Unicorn/Puma or Sidekiq.
 
@@ -200,11 +200,11 @@ data locations to the backup using the Linux command `tar` and `gzip`. This work
 fine in most cases, but can cause problems when data is rapidly changing.
 
 When data changes while `tar` is reading it, the error `file changed as we read
-it` may occur, and will cause the backup process to fail. To combat this, 8.17
+it` may occur, and causes the backup process to fail. To combat this, 8.17
 introduces a new backup strategy called `copy`. The strategy copies data files
 to a temporary location before calling `tar` and `gzip`, avoiding the error.
 
-A side-effect is that the backup process will take up to an additional 1X disk
+A side-effect is that the backup process takes up to an additional 1X disk
 space. The process does its best to clean up the temporary files at each stage
 so the problem doesn't compound, but it could be a considerable change for large
 installations. This is why the `copy` strategy is not the default in 8.17.
@@ -221,7 +221,7 @@ Users of GitLab 12.1 and earlier should use the command `gitlab-rake gitlab:back
 #### Backup filename
 
 CAUTION: **Warning:**
-If you use a custom backup filename, you will not be able to
+If you use a custom backup filename, you can't
 [limit the lifetime of the backups](#limit-backup-lifetime-for-local-files-prune-old-backups).
 
 By default, a backup file is created according to the specification in the
@@ -235,8 +235,8 @@ sudo gitlab-backup create BACKUP=dump
 
 Users of GitLab 12.1 and earlier should use the command `gitlab-rake gitlab:backup:create` instead.
 
-The resulting file will then be `dump_gitlab_backup.tar`. This is useful for
-systems that make use of rsync and incremental backups, and will result in
+The resulting file is named `dump_gitlab_backup.tar`. This is useful for
+systems that make use of rsync and incremental backups, and results in
 considerably faster transfer speeds.
 
 #### Rsyncable
@@ -271,8 +271,8 @@ variable `SKIP`. The available options are:
 
 Use a comma to specify several options at the same time:
 
-All wikis will be backed up as part of the `repositories` group. Non-existent
-wikis will be skipped during a backup.
+All wikis are backed up as part of the `repositories` group. Non-existent
+wikis are skipped during a backup.
 
 For Omnibus GitLab packages:
 
@@ -297,7 +297,7 @@ harmful, so you can skip this step by adding `tar` to the `SKIP` environment
 variable.
 
 Adding `tar` to the `SKIP` variable leaves the files and directories containing the
-backup in the directory used for the intermediate files. These files will be
+backup in the directory used for the intermediate files. These files are
 overwritten when a new backup is created, so you should make sure they are copied
 elsewhere, because you can only have one backup on the system.
 
@@ -454,7 +454,7 @@ For installations from source:
 1. [Restart GitLab](../administration/restart_gitlab.md#installations-from-source)
    for the changes to take effect
 
-If you're uploading your backups to S3, you'll probably want to create a new
+If you're uploading your backups to S3, you should create a new
 IAM user with restricted access rights. To give the upload user access only for
 uploading backups create the following IAM profile, replacing `my.s3.bucket`
 with the name of your bucket:
@@ -620,7 +620,7 @@ as (for Omnibus packages, this is the `git` user).
 
 The `backup_upload_remote_directory` _must_ be set in addition to the
 `local_root` key. This is the sub directory inside the mounted directory that
-backups will be copied to, and will be created if it does not exist. If the
+backups are copied to, and is created if it does not exist. If the
 directory that you want to copy the tarballs to is the root of your mounted
 directory, use `.` instead.
 
@@ -667,7 +667,7 @@ For installations from source:
 #### Backup archive permissions
 
 The backup archives created by GitLab (`1393513186_2014_02_27_gitlab_backup.tar`)
-will have owner/group `git`/`git` and 0600 permissions by default. This is
+have the owner/group `git`/`git` and 0600 permissions by default. This is
 meant to avoid other system users reading GitLab's data. If you need the backup
 archives to have different permissions, you can use the `archive_permissions`
 setting.
@@ -741,7 +741,7 @@ output if there aren't any errors. This is recommended to reduce cron spam.
 ### Limit backup lifetime for local files (prune old backups)
 
 CAUTION: **Warning:**
-The process described in this section will not work if you used a [custom filename](#backup-filename)
+The process described in this section don't work if you used a [custom filename](#backup-filename)
 for your backups.
 
 To prevent regular backups from using all your disk space, you may want to set a limited lifetime
@@ -791,8 +791,8 @@ once before attempting to perform it in a production environment.
 You can restore a backup only to _the exact same version and type (CE/EE)_ of
 GitLab that you created it on (for example CE 9.1.0).
 
-If your backup is a different version than the current installation, you'll
-need to [downgrade your GitLab installation](https://docs.gitlab.com/omnibus/update/README.html#downgrade)
+If your backup is a different version than the current installation, you must
+[downgrade your GitLab installation](https://docs.gitlab.com/omnibus/update/README.html#downgrade)
 before restoring the backup.
 
 ### Restore prerequisites
@@ -800,17 +800,17 @@ before restoring the backup.
 You need to have a working GitLab installation before you can perform a
 restore. This is because the system user performing the restore actions (`git`)
 is usually not allowed to create or delete the SQL database needed to import
-data into (`gitlabhq_production`). All existing data will be either erased
+data into (`gitlabhq_production`). All existing data is either erased
 (SQL) or moved to a separate directory (such as repositories and uploads).
 
-To restore a backup, you'll also need to restore `/etc/gitlab/gitlab-secrets.json`
+To restore a backup, you must restore `/etc/gitlab/gitlab-secrets.json`
 (for Omnibus packages) or `/home/git/gitlab/.secret` (for installations from
 source). This file contains the database encryption key,
 [CI/CD variables](../ci/variables/README.md#gitlab-cicd-environment-variables), and
 variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md).
 If you fail to restore this encryption key file along with the application data
-backup, users with two-factor authentication enabled and GitLab Runner will
-lose access to your GitLab server.
+backup, users with two-factor authentication enabled and GitLab Runner
+loses access to your GitLab server.
 
 You may also want to restore any TLS keys, certificates, or
 [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
@@ -825,7 +825,7 @@ more of the following options:
 - `BACKUP=timestamp_of_backup`: Required if more than one backup exists.
   Read what the [backup timestamp is about](#backup-timestamp).
 - `force=yes`: Doesn't ask if the authorized_keys file should get regenerated,
-  and assumes 'yes' for warning that database tables will be removed,
+  and assumes 'yes' for warning about database tables being removed,
   enabling the "Write to authorized_keys file" setting, and updating LDAP
   providers.
 
@@ -1033,7 +1033,7 @@ Example: LVM snapshots + rsync
 > A GitLab server using Omnibus GitLab, with an LVM logical volume mounted at `/var/opt/gitlab`.
 > Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
 > Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
-> Now we can have a longer running rsync job which will create a consistent replica on the remote server.
+> Now we can have a longer running rsync job which creates a consistent replica on the remote server.
 > The replica includes all repositories, uploads and PostgreSQL data.
 
 If you're running GitLab on a virtualized server, you can possibly also create
@@ -1045,7 +1045,7 @@ practical use.
 
 Do NOT backup or restore GitLab through a PgBouncer connection. These
 tasks must [bypass PgBouncer and connect directly to the PostgreSQL primary database node](#bypassing-pgbouncer),
-or they will cause a GitLab outage.
+or they cause a GitLab outage.
 
 When the GitLab backup or restore task is used with PgBouncer, the
 following error message is shown:
@@ -1170,7 +1170,7 @@ unexpected behaviors, such as:
 In this case, you must reset all the tokens for CI/CD variables and
 runner authentication, which is described in more detail in the following
 sections. After resetting the tokens, you should be able to visit your project
-and the jobs will have started running again.
+and the jobs begin running again.
 
 Use the information in the following sections at your own risk.
 

doc/raketasks/import.md

@@ -13,13 +13,13 @@ please use [our project-based import/export](../user/project/settings/import_exp
 
 Note that:
 
-- The owner of the project will be the first administrator.
-- The groups will be created as needed, including subgroups.
-- The owner of the group will be the first administrator.
-- Existing projects will be skipped.
+- The owner of the project is the first administrator.
+- The groups are created as needed, including subgroups.
+- The owner of the group is the first administrator.
+- Existing projects are skipped.
 - Projects in hashed storage may be skipped. For more information, see
   [Importing bare repositories from hashed storage](#importing-bare-repositories-from-hashed-storage).
-- The existing Git repositories will be moved from disk (removed from the original path).
+- The existing Git repositories ware moved from disk (removed from the original path).
 
 To import bare repositories into a GitLab instance:
 
@@ -35,8 +35,8 @@ To import bare repositories into a GitLab instance:
 
 1. Copy your bare repositories inside this newly created folder. Note:
 
-   - Any `.git` repositories found on any of the subfolders will be imported as projects.
-   - Groups will be created as needed, these could be nested folders.
+   - Any `.git` repositories found on any of the subfolders are imported as projects.
+   - Groups are created as needed, these could be nested folders.
 
    For example, if we copy the repositories to `/var/opt/gitlab/git-data/repository-import-2020-08-22`,
    and repository `A` needs to be under the groups `G1` and `G2`, it must be created under those folders:

doc/raketasks/user_management.md

@@ -98,11 +98,11 @@ the leaked key without forcing all users to change their 2FA details.
 To rotate the two-factor authentication encryption key:
 
 1. Look up the old key. This is in the `config/secrets.yml` file, but **make sure you're working
-   with the production section**. The line you're interested in will look like this:
+   with the production section**. The line you're interested in looks like this:
 
    ```yaml
    production:
-     otp_key_base: ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
+     otp_key_base: fffffffffffffffffffffffffffffffffffffffffffffff
    ```
 
 1. Generate a new secret:
@@ -130,7 +130,7 @@ To rotate the two-factor authentication encryption key:
    ```
 
    The `<old key>` value can be read from `config/secrets.yml` (`<new key>` was
-   generated earlier). The **encrypted** values for the user 2FA secrets will be
+   generated earlier). The **encrypted** values for the user 2FA secrets are
    written to the specified `filename`. You can use this to rollback in case of
    error.
 

doc/subscriptions/gitlab_com/index.md

@@ -11,7 +11,7 @@ GitLab.com is GitLab Inc.'s software-as-a-service offering. You don't need to
 install anything to use GitLab.com, you only need to
 [sign up](https://gitlab.com/users/sign_up) and start using GitLab straight away.
 
-In this page we'll go through the details of your GitLab.com subscription.
+This page reviews the details of your GitLab.com subscription.
 
 ## Choose a GitLab.com group or personal subscription
 
@@ -20,10 +20,10 @@ On GitLab.com you can apply a subscription to either a group or a personal names
 When applied to:
 
 - A **group**, the group, all subgroups, and all projects under the selected
-  group on GitLab.com will have the features of the associated tier. GitLab recommends
+  group on GitLab.com contains the features of the associated tier. GitLab recommends
   choosing a group plan when managing an organization's projects and users.
-- A **personal userspace**, all projects will have features with the
-  subscription applied, but as it's not a group, group features won't be available.
+- A **personal userspace**, all projects contain features with the
+  subscription applied, but as it's not a group, group features aren't available.
 
 ## Choose a GitLab.com tier
 
@@ -64,7 +64,7 @@ To subscribe to GitLab.com:
      [Customers Portal](https://customers.gitlab.com/).
   1. Link your GitLab.com account with your Customers Portal account.
      Once a plan has been selected, if your account is not
-     already linked, you will be prompted to link your account with a
+     already linked, GitLab prompts you to link your account with a
      **Sign in to GitLab.com** button.
   1. Select the namespace from the drop-down list to associate the subscription.
   1. Proceed to checkout.
@@ -81,7 +81,7 @@ To subscribe to GitLab.com:
      [Customers Portal](https://customers.gitlab.com/).
   1. Link your GitLab.com account with your Customers Portal account.
      Once a plan has been selected, if your account is not
-     already linked, you will be prompted to link your account with a
+     already linked, GitLab prompts you to link your account with a
      **Sign in to GitLab.com** button.
   1. Select the namespace from the drop-down list to associate the subscription.
   1. Proceed to checkout.
@@ -109,9 +109,9 @@ to the **Billing** section of the relevant namespace:
   | **Seats in subscription**   | If this is a paid plan, represents the number of seats you've paid to support in your group.                                            |
   | **Seats currently in use** | Number of active seats currently in use.                                                                                                |
   | **Max seats used**          | Highest number of seats you've used. If this exceeds the seats in subscription, you may owe an additional fee for the additional users. |
-  | **Seats owed**              | If your maximum seats used exceeds the seats in your subscription, you'll owe an additional fee for the users you've added.             |
+  | **Seats owed**              | If your maximum seats used exceeds the seats in your subscription, you owe an additional fee for the users you've added.             |
   | **Subscription start date** | Date your subscription started. If this is for a Free plan, is the date you transitioned off your group's paid plan.                    |
-  | **Subscription end date**   | Date your current subscription will end. Does not apply to Free plans.                                                                  |
+  | **Subscription end date**   | Date your current subscription ends. Does not apply to Free plans.                                                                  |
 
 ## Renew your GitLab.com subscription
 
@@ -136,8 +136,8 @@ the contact person who manages your subscription.
 
 It's important to regularly review your user accounts, because:
 
-- A GitLab subscription is based on the number of users. You will pay more than
-  you should if you renew for too many users, while the renewal will fail if you
+- A GitLab subscription is based on the number of users. You could pay more than
+  you should if you renew for too many users, while the renewal fails if you
   attempt to renew a subscription for too few users.
 - Stale user accounts can be a security risk. A regular review helps reduce this risk.
 
@@ -172,8 +172,8 @@ previous period), log in to the [Customers Portal](https://customers.gitlab.com/
 - If you see **Cancel subscription**, your subscription is set to automatically
   renew at the end of the subscription period. Click it to cancel automatic renewal.
 
-With automatic renewal enabled, the subscription will automatically renew on the
-expiration date and there will be no gap in available service. An invoice will be
+With automatic renewal enabled, the subscription automatically renews on the
+expiration date without a gap in available service. An invoice is
 generated for the renewal and available for viewing or download in the
 [View invoices](https://customers.gitlab.com/receipts) page. If you have difficulty
 during the renewal process, contact our
@@ -193,10 +193,10 @@ To add users to a subscription:
 1. Enter the number of additional users.
 1. Select **Proceed to checkout**.
 1. Review the **Subscription Upgrade Detail**. The system lists the total price for all users on the
-   system and a credit for what you've already paid. You will only be charged for the net change.
+   system and a credit for what you've already paid. You are only be charged for the net change.
 1. Select **Confirm Upgrade**.
 
-The following will be emailed to you:
+The following is emailed to you:
 
 - A payment receipt. You can also access this information in the Customers Portal under
   [**View invoices**](https://customers.gitlab.com/receipts).
@@ -222,7 +222,7 @@ it may become inaccessible, depending on the tier at expiry. Some features may n
 behave as expected if you're not prepared for the expiry. For example,
 [environment specific variables not being passed](https://gitlab.com/gitlab-org/gitlab/-/issues/24759).
 
-If you renew or upgrade, your data will again be accessible.
+If you renew or upgrade, your data is accessible again.
 
 ## CI pipeline minutes
 
@@ -258,7 +258,7 @@ Your own runners can still be used even if you reach your limits.
 ### Purchase additional CI minutes
 
 If you're using GitLab.com, you can purchase additional CI minutes so your
-pipelines won't be blocked after you have used all your CI minutes from your
+pipelines aren't blocked after you have used all your CI minutes from your
 main quota. You can find pricing for additional CI/CD minutes in the
 [GitLab Customers Portal](https://customers.gitlab.com/plans). Additional minutes:
 
@@ -268,9 +268,9 @@ main quota. You can find pricing for additional CI/CD minutes in the
 To purchase additional minutes for your group on GitLab.com:
 
 1. From your group, go to **Settings > Usage Quotas**.
-1. Select **Buy additional minutes** and you will be directed to the Customers Portal.
+1. Select **Buy additional minutes** and GitLab directs you to the Customers Portal.
 1. Locate the subscription card that's linked to your group on GitLab.com, click **Buy more CI minutes**, and complete the details about the transaction.
-1. Once we have processed your payment, the extra CI minutes will be synced to your group namespace.
+1. Once we have processed your payment, the extra CI minutes are synced to your group namespace.
 1. To confirm the available CI minutes, go to your group, then **Settings > Usage Quotas**.
 
    The **Additional minutes** displayed now includes the purchased additional CI minutes, plus any minutes rolled over from last month.
@@ -278,8 +278,8 @@ To purchase additional minutes for your group on GitLab.com:
 To purchase additional minutes for your personal namespace:
 
 1. Click your avatar, then go to **Settings > Usage Quotas**.
-1. Select **Buy additional minutes** and you will be directed to the Customers Portal.
-1. Locate the subscription card that's linked to your personal namespace on GitLab.com, click **Buy more CI minutes**, and complete the details about the transaction. Once we have processed your payment, the extra CI minutes will be synced to your personal namespace.
+1. Select **Buy additional minutes** and GitLab redirects you to the Customers Portal.
+1. Locate the subscription card that's linked to your personal namespace on GitLab.com, click **Buy more CI minutes**, and complete the details about the transaction. Once we have processed your payment, the extra CI minutes are synced to your personal namespace.
 1. To confirm the available CI minutes for your personal projects, click your avatar, then go to **Settings > Usage Quotas**.
 
    The **Additional minutes** displayed now includes the purchased additional CI minutes, plus any minutes rolled over from last month.
@@ -287,7 +287,7 @@ To purchase additional minutes for your personal namespace:
 Be aware that:
 
 - If you have purchased extra CI minutes before the purchase of a paid plan,
-  we will calculate a pro-rated charge for your paid plan. That means you may
+  we calculate a pro-rated charge for your paid plan. That means you may
   be charged for less than one year since your subscription was previously
   created with the extra CI minutes.
 - Once the extra CI minutes have been assigned to a Group, they can't be transferred

doc/subscriptions/index.md

@@ -152,7 +152,7 @@ With a linked GitLab.com account:
 1. Select the desired group from the **This subscription is for** dropdown.
 1. Click **Proceed to checkout**.
 
-Subscription charges are calculated based on the total number of users in a group, including its subgroups and nested projects. If the total number of users exceeds the number of seats in your subscription, you will be charged for the additional users.
+Subscription charges are calculated based on the total number of users in a group, including its subgroups and nested projects. If the total number of users exceeds the number of seats in your subscription, your account is charged for the additional users.
 
 ### Change customer portal account password
 

doc/subscriptions/self_managed/index.md

@@ -116,8 +116,8 @@ the contact person who manages your subscription.
 
 It's important to regularly review your user accounts, because:
 
-- A GitLab subscription is based on the number of users. You will pay more than
-  you should if you renew for too many users, while the renewal will fail if you
+- A GitLab subscription is based on the number of users. You pay more than
+  you should if you renew for too many users, while the renewal fail if you
   attempt to renew a subscription for too few users.
 - Stale user accounts can be a security risk. A regular review helps reduce this risk.
 
@@ -140,10 +140,10 @@ To add users to a subscription:
 1. Select **Add more seats** on the relevant subscription card.
 1. Enter the number of additional users.
 1. Select **Proceed to checkout**.
-1. Review the **Subscription Upgrade Detail**. The system lists the total price for all users on the system and a credit for what you've already paid. You will only be charged for the net change.
+1. Review the **Subscription Upgrade Detail**. The system lists the total price for all users on the system and a credit for what you've already paid. You are only be charged for the net change.
 1. Select **Confirm Upgrade**.
 
-The following will be emailed to you:
+The following items are emailed to you:
 
 - A payment receipt. You can also access this information in the Customers Portal under [**View invoices**](https://customers.gitlab.com/receipts).
 - A new license. [Upload this license](../../user/admin_area/license.md#uploading-your-license) to your instance to use it.
@@ -165,7 +165,7 @@ We recommend following these steps during renewal:
 1. Enter the number of [users over license](#users-over-license) in the second box for the user overage incurred in your previous subscription term.
 
    TIP: **Tip:**
-   You can find the _users over license_ in your instance's **Admin** dashboard by clicking on the **Admin Area** in the top bar, or going to `/admin`.
+   You can find the _users over license_ in your instance's **Admin** dashboard by clicking on the **Admin Area** in the top bar, or navigating to `/admin`.
 
    The following table describes details of your admin dashboard and renewal terms:
 
@@ -174,13 +174,13 @@ We recommend following these steps during renewal:
    | Users in License | The number of users you've paid for in the current license loaded on the system. This does not include the amount you've paid for `Users over license` during renewal. |
    | Active users | The daily count of active users on your system. |
    | Maximum users | The highest number of active users on your system during the term of the loaded license. If this number exceeds your users in license count at any point, you incur users over license. |
-   | Users over license | The number of users that exceed the `Users in License` for the current license term. Charges for this number of users will be incurred at the next renewal. |
+   | Users over license | The number of users that exceed the `Users in License` for the current license term. Charges for this number of users are incurred at the next renewal. |
 
 1. Review your renewal details and complete the payment process.
-1. A license for the renewal term will be available for download on the [Manage Purchases](https://customers.gitlab.com/subscriptions) page on the relevant subscription card. Select **Copy license to clipboard** or **Download license** to get a copy.
+1. A license for the renewal term is available for download on the [Manage Purchases](https://customers.gitlab.com/subscriptions) page on the relevant subscription card. Select **Copy license to clipboard** or **Download license** to get a copy.
 1. [Upload](../../user/admin_area/license.md#uploading-your-license) your new license to your instance.
 
-An invoice will be generated for the renewal and available for viewing or download on the [View invoices](https://customers.gitlab.com/receipts) page. If you have difficulty during the renewal process, contact our [support team](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293) for assistance.
+An invoice is generated for the renewal and available for viewing or download on the [View invoices](https://customers.gitlab.com/receipts) page. If you have difficulty during the renewal process, contact our [support team](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293) for assistance.
 
 ### Seat Link
 
@@ -197,7 +197,7 @@ Seat Link provides **only** the following information to GitLab:
 - Historical maximum user count
 - Active users count
 
-For offline or closed network customers, the existing [true-up model](#users-over-license) will be used. Prorated charges are not possible without user count data.
+For offline or closed network customers, the existing [true-up model](#users-over-license) is used. Prorated charges are not possible without user count data.
 
 <details>
 <summary>Click here to view example content of a Seat Link POST request.</summary>
@@ -306,14 +306,14 @@ When your subscription or trial expires, GitLab does not delete your data, but i
 may become inaccessible, depending on the tier at expiry. Some features may not
 behave as expected if you're not prepared for the expiry. For example,
 [environment specific variables not being passed](https://gitlab.com/gitlab-org/gitlab/-/issues/24759).
-If you renew or upgrade, your data will again be accessible.
+If you renew or upgrade, your data is again accessible.
 
 For self-managed customers, there is a 14-day grace period when your features
-will continue to work as-is, after which the entire instance will become read
+continue to work as-is, after which the entire instance becomes read
 only.
 
-However, if you remove the license, you will immediately revert to Core
-features, and the instance will be read / write again.
+However, if you remove the license, you immediately revert to Core
+features, and the instance become read / write again.
 
 ## Customers portal
 

doc/university/training/topics/env_setup.md

@@ -12,7 +12,7 @@ comments: false
 - **Windows** - Install 'Git for Windows' from [Git for Windows](https://gitforwindows.org).
 - **Mac**
   - Type '`git`' in the Terminal application.
-  - If it's not installed, it will prompt you to install it.
+  - If it's not installed, it prompts you to install it.
 
 - **GNU/Linux** - Enter `which git` in the Terminal application and press <kbd>Enter</kbd> to
   determine if Git is installed on your system.

doc/university/training/topics/merge_conflicts.md

@@ -42,7 +42,7 @@ git commit -am "add line6 and line7"
 git push origin master
 ```
 
-Create a merge request on the GitLab web UI. You'll see a conflict warning.
+Create a merge request on the GitLab web UI, and a conflict warning displays.
 
 ```shell
 git checkout conflicts_branch

doc/university/training/topics/stash.md

@@ -55,7 +55,7 @@ and we need to change to a different branch.
   ```
 
 - If we meet conflicts we need to either reset or commit our changes.
-- Conflicts through `pop` will not drop a stash afterwards.
+- Conflicts through `pop` doesn't drop a stash afterwards.
 
 ## Git Stash sample workflow
 

doc/university/training/topics/unstage.md

@@ -7,7 +7,7 @@ comments: false
 
 # Unstage
 
-- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This will unstage the file but maintain the modifications.
+- To remove files from stage use reset HEAD where HEAD is the last commit of the current branch. This unstages the file but maintain the modifications.
 
   ```shell
   git reset HEAD <file>

doc/university/training/user_training.md

@@ -46,7 +46,7 @@ Use the tools at your disposal when you get stuck.
 
 - Mac: Type '`git`' in the Terminal application.
 
-> If it's not installed, it will prompt you to install it.
+> If it's not installed, it prompts you to install it.
 
 - Debian: '`sudo apt-get install git-all`' or Red Hat '`sudo yum install git-all`'
 
@@ -235,7 +235,7 @@ See GitLab merge requests for examples: <https://gitlab.com/gitlab-org/gitlab-fo
 
 - Useful for marking deployments and releases.
 - Annotated tags are an unchangeable part of Git history.
-- Soft/lightweight tags can be set and removed at will.
+- Soft/lightweight tags can be set and removed at any time.
 - Many projects combine an annotated release tag with a stable branch.
 - Consider setting deployment/release tags automatically.
 

doc/user/abuse_reports.md

@@ -39,7 +39,7 @@ To report abuse from a user's comment:
 1. Click the **Send report** button.
 
 NOTE: **Note:**
-A URL to the reported user's comment will be pre-filled in the abuse report's
+A URL to the reported user's comment is pre-filled in the abuse report's
 **Message** field.
 
 ## Reporting abuse through a user's issue or merge request
@@ -59,7 +59,7 @@ With the **Report abuse** button displayed, to submit an abuse report:
 1. Click the **Send report** button.
 
 NOTE: **Note:**
-A URL to the reported user's issue or merge request will be pre-filled
+A URL to the reported user's issue or merge request is pre-filled
 in the abuse report's **Message** field.
 
 ## Managing abuse reports

doc/user/feature_highlight.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/16379) in GitLab 10.5
 
 Feature highlights are represented by a pulsing blue dot. Hovering over the dot
-will display more information.
+displays more information.
 They are used to emphasize a certain feature and make something more visible to the user.
 
 You can dismiss any feature highlight permanently by clicking the "Got it" link

doc/user/index.md

@@ -10,7 +10,7 @@ description: 'Read through the GitLab User documentation to learn how to use, co
 
 Welcome to GitLab! We're glad to have you here!
 
-As a GitLab user you'll have access to all the features
+As a GitLab user you have access to all the features
 your [subscription](https://about.gitlab.com/pricing/)
 includes, except [GitLab administrator](../administration/index.md)
 settings, unless you have admin privileges to install, configure,
@@ -175,7 +175,7 @@ such as Trello, Jira, etc.
 ## Webhooks
 
 Configure [webhooks](project/integrations/webhooks.md) to listen for
-specific events like pushes, issues or merge requests. GitLab will send a
+specific events like pushes, issues or merge requests. GitLab sends a
 POST request with data to the webhook URL.
 
 ## API

doc/user/instance/clusters/index.md

@@ -18,7 +18,7 @@ The instance level Kubernetes clusters can be found in the top menu by navigatin
 
 ## Cluster precedence
 
-GitLab will try to match clusters in the following order:
+GitLab tries to match clusters in the following order:
 
 - Project-level clusters.
 - Group-level clusters.

doc/user/operations_dashboard/index.md

@@ -26,7 +26,7 @@ To add a project to the dashboard:
 1. Search and add one or more projects using the **Search your projects** field.
 1. Click the **Add projects** button.
 
-Once added, the dashboard will display the project's number of active alerts,
+Once added, the dashboard displays the project's number of active alerts,
 last commit, pipeline status, and when it was last deployed.
 
 The Operations and [Environments](../../ci/environments/environments_dashboard.md) dashboards share the same list of projects. Adding or removing a project from one adds or removes the project from the other.
@@ -35,7 +35,7 @@ The Operations and [Environments](../../ci/environments/environments_dashboard.m
 
 ## Arranging projects on a dashboard
 
-You can drag project cards to change their order. The card order is currently only saved to your browser, so will not change the dashboard for other people.
+You can drag project cards to change their order. The card order is currently only saved to your browser, so it doesn't change the dashboard for other people.
 
 ## Making it the default dashboard when you sign in
 

doc/user/profile/active_sessions.md

@@ -34,7 +34,7 @@ exceeds 100, the oldest ones are deleted.
 
 NOTE: **Note:**
 When any session is revoked all **Remember me** tokens for all
-devices will be revoked. See ['Why do I keep getting signed out?'](index.md#why-do-i-keep-getting-signed-out)
+devices are revoked. See ['Why do I keep getting signed out?'](index.md#why-do-i-keep-getting-signed-out)
 for more information about the **Remember me** feature.
 
 <!-- ## Troubleshooting

doc/user/profile/preferences.md

@@ -107,8 +107,8 @@ While `1280px` is the standard max width when using fixed layout, some pages sti
 
 For users who have access to a large number of projects but only keep up with a
 select few, the amount of activity on the default Dashboard page can be
-overwhelming. Changing this setting allows you to redefine what your default
-dashboard will be.
+overwhelming. Changing this setting allows you to redefine your default
+dashboard.
 
 You have 8 options here that you can use for your default dashboard view:
 
@@ -164,7 +164,7 @@ You can choose one of the following options as the first day of the week:
 - Sunday
 - Monday
 
-If you select **System Default**, the system-wide default setting will be used.
+If you select **System Default**, the system-wide default setting is used.
 
 ## Integrations
 

doc/user/project/issues/csv_export.md

@@ -35,11 +35,11 @@ Among numerous use cases for exporting issues for CSV, we can name a few:
 
 ## Choosing which issues to include
 
-After selecting a project, from the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned will be exported, including those not shown on the first page.
+After selecting a project, from the issues page you can narrow down which issues to export using the search bar, along with the All/Open/Closed tabs. All issues returned are exported, including those not shown on the first page.
 
 ![CSV export button](img/csv_export_button_v12_9.png)
 
-You will be asked to confirm the number of issues and email address for the export, after which the email will begin being prepared.
+GitLab asks you to confirm the number of issues and email address for the export, after which the email is prepared.
 
 ![CSV export modal dialog](img/csv_export_modal.png)
 
@@ -53,7 +53,7 @@ Exported issues are always sorted by `Issue ID`.
 >
 > **Weight** and **Locked** columns were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5300) in GitLab Starter 10.8.
 
-Data will be encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows. The first row will be the headers, which are listed in the following table along with a description of the values:
+Data wis encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows. The first row contains the headers, which are listed in the following table along with a description of the values:
 
 | Column  | Description |
 |---------|-------------|
@@ -82,4 +82,4 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
 ## Limitations
 
 - Export Issues to CSV is not available at the Group's Issues List.
-- As the issues will be sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.
+- As the issues are sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 15MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.

doc/user/project/issues/csv_import.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Issues can be imported to a project by uploading a CSV file with the columns
 `title` and `description`.
 
-The user uploading the CSV file will be set as the author of the imported issues.
+The user uploading the CSV file is set as the author of the imported issues.
 
 NOTE: **Note:**
 A permission level of [Developer](../../permissions.md), or higher, is required

doc/user/shortcuts.md

@@ -54,7 +54,7 @@ other keyboard shortcuts are disabled as explained above.
 ## Project
 
 These shortcuts are available from any page within a project. You must type them
-relatively quickly to work, and they will take you to another page in the project.
+relatively quickly to work, and they take you to another page in the project.
 
 | Keyboard Shortcut           | Description |
 | --------------------------- | ----------- |
@@ -87,7 +87,7 @@ These shortcuts are available when viewing issues and merge requests.
 | <kbd>a</kbd>                 | Change assignee. |
 | <kbd>m</kbd>                 | Change milestone. |
 | <kbd>l</kbd>                 | Change label. |
-| <kbd>r</kbd>                 | Start writing a comment. If any text is selected, it will be quoted in the comment. Can't be used to reply within a thread. |
+| <kbd>r</kbd>                 | Start writing a comment. If any text is selected, it is quoted in the comment. Can't be used to reply within a thread. |
 | <kbd>n</kbd>                 | Move to next unresolved discussion (merge requests only). |
 | <kbd>p</kbd>                 | Move to previous unresolved discussion (merge requests only). |
 | <kbd>]</kbd> or <kbd>j</kbd> | Move to next file (merge requests only). |
@@ -153,6 +153,6 @@ These shortcuts are available when viewing [Epics](group/epics/index.md):
 
 | Keyboard Shortcut | Description |
 | ----------------- | ----------- |
-| <kbd>r</kbd>      | Start writing a comment. If any text is selected, it will be quoted in the comment. Can't be used to reply within a thread. |
+| <kbd>r</kbd>      | Start writing a comment. If any text is selected, it is quoted in the comment. Can't be used to reply within a thread. |
 | <kbd>e</kbd>      | Edit description. |
 | <kbd>l</kbd>      | Change label. |