Fix additional future tense in development docs

More files in the development directory that used future tense
instead of present tense.

doc/development/new_fe_guide/development/performance.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 We have a performance dashboard available in one of our [Grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://www.sitespeed.io/) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
 These pages can be found inside a text file in the [`gitlab-build-images` repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [`gitlab.txt`](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
-Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
+Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing URLs of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/company/team/) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes are pushed live on the next scheduled run after the changes are merged into `master`.
 
 There are 3 recommended high impact metrics to review on each page:
 

doc/integration/cas.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # CAS OmniAuth Provider
 
-To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab will supply to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout.
+To enable the CAS OmniAuth provider you must register your application with your CAS instance. This requires the service URL GitLab supplies to CAS. It should be something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. By default handling for SLO is enabled, you only need to configure CAS for backchannel logout.
 
 1. On your GitLab server, open the configuration file.
 

doc/integration/jenkins.md

@@ -54,9 +54,9 @@ Grant a GitLab user access to the select GitLab projects.
 
 1. Create a new GitLab user, or choose an existing GitLab user.
 
-   This account will be used by Jenkins to access the GitLab projects. We recommend creating a GitLab
+   This account is used by Jenkins to access the GitLab projects. We recommend creating a GitLab
    user for only this purpose. If you use a person's account, and their account is deactivated or
-   deleted, the GitLab-Jenkins integration will stop working.
+   deleted, the GitLab-Jenkins integration stops working.
 
 1. Grant the user permission to the GitLab projects.
 
@@ -96,12 +96,12 @@ For more information, see GitLab Plugin documentation about
 
 ## Configure the Jenkins project
 
-Set up the Jenkins project you’re going to run your build on.
+Set up the Jenkins project you intend to run your build on.
 
 1. On your Jenkins instance, go to **New Item**.
 1. Enter the project's name.
 1. Choose between **Freestyle** or **Pipeline** and click **OK**.
-    We recommend a Freestyle project, because the Jenkins plugin will update the build status on
+    We recommend a Freestyle project, because the Jenkins plugin updates the build status on
     GitLab. In a Pipeline project, you must configure a script to update the status on GitLab.
 1. Choose your GitLab connection from the dropdown.
 1. Check the **Build when a change is pushed to GitLab** checkbox.
@@ -186,7 +186,7 @@ If those are present, the request is exceeding the
 [webhook timeout](../user/project/integrations/webhooks.md#receiving-duplicate-or-multiple-webhook-requests-triggered-by-one-event),
 which is set to 10 seconds by default.
 
-To fix this the `gitlab_rails['webhook_timeout']` value will need to be increased
+To fix this the `gitlab_rails['webhook_timeout']` value must be increased
 in the `gitlab.rb` config file, followed by the [`gitlab-ctl reconfigure` command](../administration/restart_gitlab.md).
 
 If you don't find the errors above, but do find *duplicate* entries like below (in `/var/log/gitlab/gitlab-rail`), this

doc/user/admin_area/broadcast_messages.md

@@ -47,7 +47,7 @@ The available placeholders are:
 - `{{username}}`
 - `{{instance_id}}`
 
-If the user is not signed in, user related values will be empty.
+If the user is not signed in, user related values are empty.
 
 ![Broadcast Message Notification](img/broadcast_messages_notification_v12_10.png)
 

doc/user/admin_area/index.md

@@ -94,7 +94,7 @@ The list of projects can be sorted by:
 
 A user can choose to hide or show archived projects in the list.
 
-In the **Filter by name** field, type the project name you want to find, and GitLab will filter
+In the **Filter by name** field, type the project name you want to find, and GitLab filters
 them as you type.
 
 Select from the **Namespace** dropdown to filter only projects in that namespace.

doc/user/admin_area/monitoring/health_check.md

@@ -70,7 +70,7 @@ The readiness probe checks whether the GitLab instance is ready
 to accept traffic via Rails Controllers. The check by default
 does validate only instance-checks.
 
-If the `all=1` parameter is specified, the check will also validate
+If the `all=1` parameter is specified, the check also validates
 the dependent services (Database, Redis, Gitaly etc.)
 and gives a status for each.
 
@@ -97,7 +97,7 @@ Example response:
 }
 ```
 
-On failure, the endpoint will return a `503` HTTP status code.
+On failure, the endpoint returns a `503` HTTP status code.
 
 This check does hit the database and Redis if authenticated via `token`.
 
@@ -126,7 +126,7 @@ curl 'https://gitlab.example.com/-/liveness'
 
 Example response:
 
-On success, the endpoint will return a `200` HTTP status code, and a response like below.
+On success, the endpoint returns a `200` HTTP status code, and a response like below.
 
 ```json
 {
@@ -134,7 +134,7 @@ On success, the endpoint will return a `200` HTTP status code, and a response li
 }
 ```
 
-On failure, the endpoint will return a `503` HTTP status code.
+On failure, the endpoint returns a `503` HTTP status code.
 
 This check is being exempt from Rack Attack.
 

doc/user/application_security/index.md

@@ -92,7 +92,7 @@ rules:
 
 ## Security Scanning with Auto DevOps
 
-When [Auto DevOps](../../topics/autodevops/) is enabled, all GitLab Security scanning tools will be configured using default settings.
+When [Auto DevOps](../../topics/autodevops/) is enabled, all GitLab Security scanning tools are configured using default settings.
 
 - [Auto SAST](../../topics/autodevops/stages.md#auto-sast)
 - [Auto Secret Detection](../../topics/autodevops/stages.md#auto-secret-detection)
@@ -225,11 +225,11 @@ vulnerability as you learn more over time.
 > Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.
 
 You can dismiss multiple vulnerabilities at once, providing an optional reason.
-Selecting the checkboxes on the side of each vulnerability in the list will select that individual vulnerability.
+Selecting the checkboxes on the side of each vulnerability in the list selects that individual vulnerability.
 Alternatively, you can select all the vulnerabilities in the list by selecting the checkbox in the table header.
-Deselecting the checkbox in the header will deselect all the vulnerabilities in the list.
+Deselecting the checkbox in the header deselects all the vulnerabilities in the list.
 Once you have selected some vulnerabilities, a menu appears at the top of the table that allows you to select a dismissal reason.
-Pressing the "Dismiss Selected" button will dismiss all the selected vulnerabilities at once, with the reason you chose.
+Pressing the "Dismiss Selected" button dismisses all the selected vulnerabilities at once, with the reason you chose.
 
 ![Multiple vulnerability dismissal](img/multi_select_v12_9.png)
 

doc/user/gitlab_com/index.md

@@ -6,13 +6,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab.com settings
 
-In this page you will find information about the settings that are used on
+This page contains information about the settings that are used on
 [GitLab.com](https://about.gitlab.com/pricing/).
 
 ## SSH host keys fingerprints
 
 Below are the fingerprints for GitLab.com's SSH host keys. The first time you connect
-to a GitLab.com repository, you'll see one of these keys in the output.
+to a GitLab.com repository, one of these keys is displayed in the output.
 
 | Algorithm | MD5 (deprecated) | SHA256  |
 | --------- | --- | ------- |
@@ -50,7 +50,7 @@ Projects can be backed up in their entirety by exporting them either [through th
 
 With exports, be sure to take note of [what is and is not](../project/settings/import_export.md#exported-contents), included in a project export.
 
-Since GitLab is built on Git, you can back up **just** the repository of a project by [cloning](../../gitlab-basics/start-using-git.md#clone-a-repository) it to another machine. Similarly, if you need to back up just the wiki of a repository it can also be cloned and all files uploaded to that wiki will come with it [if they were uploaded after 2020-08-22](../project/wiki/index.md#creating-a-new-wiki-page).
+Since GitLab is built on Git, you can back up **just** the repository of a project by [cloning](../../gitlab-basics/start-using-git.md#clone-a-repository) it to another machine. Similarly, if you need to back up just the wiki of a repository it can also be cloned and all files uploaded to that wiki are included [if they were uploaded after 2020-08-22](../project/wiki/index.md#creating-a-new-wiki-page).
 
 ## Alternative SSH port
 
@@ -161,10 +161,10 @@ installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
 region of the VMs is US East1.
 Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
 
-The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They will not run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
+The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
 
 Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
-**will be timed out after 3 hours**, regardless of the timeout configured in a
+**time out after 3 hours**, regardless of the timeout configured in a
 project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
 
 Below are the shared runners settings.
@@ -396,19 +396,19 @@ test:
 - The average provisioning time for a new Windows VM is 5 minutes.
   This means that you may notice slower build start times
   on the Windows shared runner fleet during the beta. In a future
-  release we will update the autoscaler to enable
-  the pre-provisioning of virtual machines. This will significantly reduce
+  release we intend to update the autoscaler to enable
+  the pre-provisioning of virtual machines. This is intended to significantly reduce
   the time it takes to provision a VM on the Windows fleet. You can
   follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
 - The Windows shared runner fleet may be unavailable occasionally
   for maintenance or updates.
 - The Windows shared runner virtual machine instances do not use the
-  GitLab Docker executor. This means that you will not be able to specify
+  GitLab Docker executor. This means that you can't specify
   [`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
   your pipeline configuration.
 - For the beta release, we have included a set of software packages in
   the base VM image. If your CI job requires additional software that's
-  not included in this list, then you will need to add installation
+  not included in this list, then you must add installation
   commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
   software. Note that each job runs on a new VM instance, so the
   installation of additional software packages needs to be repeated for
@@ -512,7 +512,7 @@ documentation.
 
 IP blocks usually happen when GitLab.com receives unusual traffic from a single
 IP address that the system views as potentially malicious based on rate limit
-settings. After the unusual traffic ceases, the IP address will be automatically
+settings. After the unusual traffic ceases, the IP address is automatically
 released depending on the type of block, as described below.
 
 If you receive a `403 Forbidden` error for all requests to GitLab.com, please

doc/user/group/subgroups/index.md

@@ -109,7 +109,7 @@ To create a subgroup:
 
    ![Subgroups page](img/create_new_group.png)
 
-1. Click the **Create group** button and you will be taken to the new group's
+1. Click the **Create group** button to be redirected to the new group's
    dashboard page.
 
 Follow the same process to create any subsequent groups.
@@ -170,10 +170,10 @@ To override a user's membership of an ancestor group (the first group they were
 added to), add the user to the new subgroup again with a higher set of permissions.
 
 For example, if User0 was first added to group `group-1/group-1-1` with Developer
-permissions, then they will inherit those permissions in every other subgroup
+permissions, then they inherit those permissions in every other subgroup
 of `group-1/group-1-1`. To give them Maintainer access to `group-1/group-1-1/group1-1-1`,
 you would add them again in that group as Maintainer. Removing them from that group,
-the permissions will fallback to those of the ancestor group.
+the permissions fall back to those of the ancestor group.
 
 ## Mentioning subgroups
 

doc/user/project/canary_deployments.md

@@ -32,13 +32,13 @@ deployments right inside the [Deploy Board](deploy_boards.md), without the need
 Canary deployments can be used when you want to ship features to only a portion of
 your pods fleet and watch their behavior as a percentage of your user base
 visits the temporarily deployed feature. If all works well, you can deploy the
-feature to production knowing that it won't cause any problems.
+feature to production knowing that it shouldn't cause any problems.
 
 Canary deployments are also especially useful for backend refactors, performance
 improvements, or other changes where the user interface doesn't change, but you
 want to make sure the performance stays the same, or improves. Developers need
 to be careful when using canaries with user-facing changes, because by default,
-requests from the same user will be randomly distributed between canary and
+requests from the same user are randomly distributed between canary and
 non-canary pods, which could result in confusion or even errors. If needed, you
 may want to consider [setting `service.spec.sessionAffinity` to `ClientIP` in
 your Kubernetes service definitions](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), but that is beyond the scope of
@@ -60,7 +60,7 @@ This allows GitLab to discover whether a deployment is stable or canary (tempora
 
 Once all of the above are set up and the pipeline has run at least once,
 navigate to the environments page under **Pipelines > Environments**.
-As the pipeline executes Deploy Boards will clearly mark canary pods, enabling
+As the pipeline executes, Deploy Boards clearly mark canary pods, enabling
 quick and easy insight into the status of each environment and deployment.
 
 Canary deployments are marked with a yellow dot in the Deploy Board so that you

doc/user/project/import/tfvc.md

@@ -38,7 +38,7 @@ Advantages of migrating to Git/GitLab:
 - **No licensing costs:** Git is open source, while TFVC is proprietary.
 - **Shorter learning curve:** Git has a big community and a vast number of
   tutorials to get you started (see our [Git topic](../../../topics/git/index.md)).
-- **Integration with modern tools:** After migrating to Git and GitLab, you will have
+- **Integration with modern tools:** After migrating to Git and GitLab, you have
   an open source, end-to-end software development platform with built-in version
   control, issue tracking, code review, CI/CD, and more.
 

doc/user/project/insights/index.md

@@ -27,19 +27,19 @@ link in the left sidebar:
 ## Configure your Insights
 
 Insights are configured using a YAML file called `.gitlab/insights.yml` within
-a project. That file will then be used in the project's Insights page.
+a project. That file is used in the project's Insights page.
 
 See [Writing your `.gitlab/insights.yml`](#writing-your-gitlabinsightsyml) below
 for details about the content of this file.
 
 NOTE: **Note:**
-Once the configuration file is created, you can also
+After the configuration file is created, you can also
 [use it for your project's group](../../group/insights/index.md#configure-your-insights).
 
 NOTE: **Note:**
-If the project doesn't have any configuration file, it'll try to use
+If the project doesn't have any configuration file, it attempts to use
 the group configuration if possible. If the group doesn't have any
-configuration, the default configuration will be used.
+configuration, the default configuration is used.
 
 ## Permissions
 
@@ -56,11 +56,11 @@ You may also consult the [group permissions table](../../permissions.md#group-me
 ## Writing your `.gitlab/insights.yml`
 
 The `.gitlab/insights.yml` file defines the structure and order of the Insights
-charts that will be displayed in each Insights page of your project or group.
+charts displayed in each Insights page of your project or group.
 
 Each page has a unique key and a collection of charts to fetch and display.
 
-For example, here's a single definition for Insights that will display one page with one chart:
+For example, here's a single definition for Insights that displays one page with one chart:
 
 ```yaml
 bugsCharts:
@@ -103,8 +103,8 @@ The following table lists available parameters for charts:
 
 | Keyword                                            | Description |
 |:---------------------------------------------------|:------------|
-| [`title`](#title)                                  | The title of the chart. This will displayed on the Insights page. |
-| [`description`](#description)                      | A description for the individual chart. This will be displayed above the relevant chart. |
+| [`title`](#title)                                  | The title of the chart. This displays on the Insights page. |
+| [`description`](#description)                      | A description for the individual chart. This displays above the relevant chart. |
 | [`type`](#type)                                    | The type of chart: `bar`, `line` or `stacked-bar`. |
 | [`query`](#query)                                  | A hash that defines the conditions for issues / merge requests to be part of the chart. |
 
@@ -115,7 +115,7 @@ Insights charts.
 
 ### `title`
 
-`title` is the title of the chart as it will be displayed on the Insights page.
+`title` is the title of the chart as it displays on the Insights page.
 For example:
 
 ```yaml
@@ -187,14 +187,14 @@ Defines the type of "issuable" you want to create a chart for.
 
 Supported values are:
 
-- `issue`: The chart will display issues' data.
-- `merge_request`: The chart will display merge requests' data.
+- `issue`: The chart displays issues' data.
+- `merge_request`: The chart displays merge requests' data.
 
 #### `query.issuable_state`
 
 Filter by the state of the queried "issuable".
 
-By default, the `opened` state filter will be applied.
+By default, the `opened` state filter is applied.
 
 Supported values are:
 
@@ -208,7 +208,7 @@ Supported values are:
 
 Filter by labels applied to the queried "issuable".
 
-By default, no labels filter will be applied. All the defined labels must be
+By default, no labels filter is applied. All the defined labels must be
 applied to the "issuable" in order for it to be selected.
 
 Example:
@@ -229,7 +229,7 @@ monthlyBugsCreated:
 
 Group "issuable" by the configured labels.
 
-By default, no grouping will be done. When using this keyword, you need to
+By default, no grouping is done. When using this keyword, you need to
 set `type` to either `line` or `stacked-bar`.
 
 Example:
@@ -268,7 +268,7 @@ The unit is related to the `query.group_by` you defined. For instance if you
 defined `query.group_by: 'day'`  then `query.period_limit: 365` would mean
 "Gather and display data for the last 365 days".
 
-By default, default values will be applied depending on the `query.group_by`
+By default, default values are applied depending on the `query.group_by`
 you defined.
 
 | `query.group_by` | Default value |
@@ -294,9 +294,8 @@ The `period_field` is automatically set to:
 - `created_at` otherwise
 
 NOTE: **Note:**
-Until [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/26911), is resolved, you may see `created_at`
-in place of `merged_at`.
-`created_at` will be used instead.
+Until [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/26911), is resolved,
+you may see `created_at` in place of `merged_at`. `created_at` is used instead.
 
 ### `projects`
 
@@ -304,22 +303,22 @@ in place of `merged_at`.
 
 You can limit where the "issuables" can be queried from:
 
-- If `.gitlab/insights.yml` is used for a [group's insights](../../group/insights/index.md#configure-your-insights), with `projects`, you can limit the projects to be queried. By default, all projects under the group will be used.
-- If `.gitlab/insights.yml` is used for a project's insights, specifying any other projects will yield no results. By default, the project itself will be used.
+- If `.gitlab/insights.yml` is used for a [group's insights](../../group/insights/index.md#configure-your-insights), with `projects`, you can limit the projects to be queried. By default, all projects under the group are used.
+- If `.gitlab/insights.yml` is used for a project's insights, specifying any other projects yields no results. By default, the project itself is used.
 
 #### `projects.only`
 
 The `projects.only` option specifies the projects which the "issuables"
 should be queried from.
 
-Projects listed here will be ignored when:
+Projects listed here are ignored when:
 
 - They don't exist.
 - The current user doesn't have sufficient permissions to read them.
 - They are outside of the group.
 
 In the following `insights.yml` example, we specify the projects
-the queries will be used on. This example is useful when setting
+the queries are used on. This example is useful when setting
 a group's insights:
 
 ```yaml

doc/user/project/members/index.md

@@ -53,7 +53,7 @@ that you'd like to give the user. Note that you can select more than one user.
 
 ![Give user permissions](img/add_user_give_permissions.png)
 
-Once done, hit **Add users to project** and they will be immediately added to
+Once done, select **Add users to project** and they are immediately added to
 your project with the permissions you gave them above.
 
 ![List members](img/add_user_list_members.png)
@@ -71,7 +71,7 @@ In the dropdown menu, you can see only the projects you are Maintainer on.
 ![Import members from another project](img/add_user_import_members_from_another_project.png)
 
 Select the one you want and hit **Import project members**. A flash message
-notifying you that the import was successful will appear, and the new members
+displays, notifying you that the import was successful, and the new members
 are now in the project's members list. Notice that the permissions that they
 had on the project you imported from are retained.
 
@@ -96,7 +96,7 @@ invitation, change their access level, or even delete them.
 
 ![Invite user members list](img/add_user_email_accept.png)
 
-Once the user accepts the invitation, they will be prompted to create a new
+After the user accepts the invitation, they are prompted to create a new
 GitLab account using the same e-mail address the invitation was sent to.
 
 Note: **Note:**

doc/user/project/members/share_project_with_groups.md

@@ -34,7 +34,7 @@ To share 'Project Acme' with the 'Engineering' group:
 
    ![share project with groups tab](img/share_project_with_groups_tab.png)
 
-1. After sharing 'Project Acme' with 'Engineering', the project will be listed
+1. After sharing 'Project Acme' with 'Engineering', the project is listed
    on the group dashboard
 
    !['Project Acme' is listed as a shared project for 'Engineering'](img/other_group_sees_shared_project.png)
@@ -48,11 +48,11 @@ Admins are able to share projects with any group in the system.
 
 ## Maximum access level
 
-In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') will only have 'Developer' access to 'Project Acme'.
+In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') only have 'Developer' access to 'Project Acme'.
 
 ## Sharing public project with private group
 
-When sharing a public project with a private group, owners and maintainers of the project will see the name of the group in the `members` page. Owners will also have the possibility to see members of the private group they don't have access to when mentioning them in the issue or merge request.
+When sharing a public project with a private group, owners and maintainers of the project see the name of the group in the `members` page. Owners also have the possibility to see members of the private group they don't have access to when mentioning them in the issue or merge request.
 
 ## Share project with group lock
 

doc/user/project/merge_requests/versions.md

@@ -22,8 +22,8 @@ can select an older one from version dropdown.
 ![Merge request versions dropdown](img/versions_dropdown.png)
 
 Merge request versions are based on push not on commit. So, if you pushed 5
-commits in a single push, it will be a single option in the dropdown. If you
-pushed 5 times, that will count for 5 options.
+commits in a single push, it displays as a single option in the dropdown. If you
+pushed 5 times, that counts for 5 options.
 
 You can also compare the merge request version with an older one to see what has
 changed since then.
@@ -42,12 +42,12 @@ changes appears as a system note.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/2383) in GitLab 10.5.
 
-When viewing the commit details page, GitLab will link to the merge request (or
+When viewing the commit details page, GitLab links to the merge request (or
 merge requests, if it's in more than one) containing that commit.
 
 This only applies to commits that are in the most recent version of a merge
-request - if a commit was in a merge request, then rebased out of that merge
-request, they will not be linked.
+request - if commits were in a merge request, then rebased out of that merge
+request, they aren't linked.
 
 ## `HEAD` comparison mode for Merge Requests
 

doc/user/upgrade_email_bypass.md

@@ -27,7 +27,7 @@ sent within five minutes, with a link for users to re-confirm the subject email
 
 ## Do the confirmation emails expire?
 
-The links in these re-confirmation emails expire after one day by default. Users who click an expired link will be asked to request a new re-confirmation email. Any user can request a new re-confirmation email from `http://gitlab.example.com/users/confirmation/new`.
+The links in these re-confirmation emails expire after one day by default. Users who click an expired link are asked to request a new re-confirmation email. Any user can request a new re-confirmation email from `http://gitlab.example.com/users/confirmation/new`.
 
 ## Generate a list of affected users
 
@@ -112,16 +112,16 @@ The command described in this section may activate users who have not properly c
 
 ## What about LDAP users?
 
-LDAP Users will remain confirmed if all of the following conditions are met:
+LDAP Users remain confirmed if all of the following conditions are met:
 
 - The ["User email confirmation at sign-up" option](../security/user_email_confirmation.md) is set to false.
 - The first sign-in is based on user LDAP credentials.
 - The user has added and verified [a secondary email address](profile/index.md#profile-settings) some time later.
 
 NOTE: **Note:**
-Confirmation timestamps (primary vs. secondary) will be different.
+Confirmation timestamps (primary vs. secondary) are different.
 
-Users will be unconfirmed by the background migration if any of the following conditions are met:
+Users remain unconfirmed by the background migration if any of the following conditions are met:
 
 - They [create an account through GitLab](profile/account/create_accounts.md).
 - They [swap their primary email address](profile/index.md#profile-settings) and verify it.