Merge branch '284446-unassigned-pages-futuretense-2' into 'master'

More future-tense fixes for unowned pages

See merge request gitlab-org/gitlab!48175

doc/administration/auditor_users.md

@@ -58,7 +58,7 @@ helpful:
 To create a new Auditor user:
 
 1. Create a new user or edit an existing one by navigating to
-   **Admin Area > Users**. You will find the option of the access level in
+   **Admin Area > Users**. The option of the access level is located in
    the 'Access' section.
 
    ![Admin Area Form](img/auditor_access_form.png)

doc/administration/index.md

@@ -135,7 +135,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 
 - [Issue closing pattern](issue_closing_pattern.md): Customize how to close an issue from commit messages.
 - [Gitaly](gitaly/index.md): Configuring Gitaly, GitLab's Git repository storage service.
-- [Default labels](../user/admin_area/labels.md): Create labels that will be automatically added to every new project.
+- [Default labels](../user/admin_area/labels.md): Create labels that are automatically added to every new project.
 - [Restrict the use of public or internal projects](../public_access/public_access.md#restricting-the-use-of-public-or-internal-projects): Restrict the use of visibility levels for users when they create a project or a snippet.
 - [Custom project templates](../user/admin_area/custom_project_templates.md): Configure a set of projects to be used as custom templates when creating a new project. **(PREMIUM ONLY)**
 

doc/administration/libravatar.md

@@ -41,7 +41,7 @@ the configuration options as follows:
 ### Your own Libravatar server
 
 If you are [running your own Libravatar service](https://wiki.libravatar.org/running_your_own/),
-the URL will be different in the configuration, but you must provide the same
+the URL is different in the configuration, but you must provide the same
 placeholders so GitLab can parse the URL correctly.
 
 For example, you host a service on `http://libravatar.example.com` and the

doc/administration/load_balancer.md

@@ -7,17 +7,17 @@ type: reference
 
 # Load Balancer for multi-node GitLab
 
-In an multi-node GitLab configuration, you will need a load balancer to route
+In an multi-node GitLab configuration, you need a load balancer to route
 traffic to the application servers. The specifics on which load balancer to use
 or the exact configuration is beyond the scope of GitLab documentation. We hope
 that if you're managing HA systems like GitLab you have a load balancer of
 choice already. Some examples including HAProxy (open-source), F5 Big-IP LTM,
-and Citrix Net Scaler. This documentation will outline what ports and protocols
+and Citrix Net Scaler. This documentation outlines what ports and protocols
 you need to use with GitLab.
 
 ## SSL
 
-How will you handle SSL in your multi-node environment? There are several different
+How do you want to handle SSL in your multi-node environment? There are several different
 options:
 
 - Each application node terminates SSL
@@ -29,8 +29,8 @@ options:
 ### Application nodes terminate SSL
 
 Configure your load balancer(s) to pass connections on port 443 as 'TCP' rather
-than 'HTTP(S)' protocol. This will pass the connection to the application nodes
-NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
+than 'HTTP(S)' protocol. This passes the connection to the application nodes
+NGINX service untouched. NGINX has the SSL certificate and listen on port 443.
 
 See [NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
 for details on managing SSL certificates and configuring NGINX.
@@ -38,10 +38,10 @@ for details on managing SSL certificates and configuring NGINX.
 ### Load Balancer(s) terminate SSL without backend SSL
 
 Configure your load balancer(s) to use the 'HTTP(S)' protocol rather than 'TCP'.
-The load balancer(s) will then be responsible for managing SSL certificates and
+The load balancer(s) is be responsible for managing SSL certificates and
 terminating SSL.
 
-Since communication between the load balancer(s) and GitLab will not be secure,
+Since communication between the load balancer(s) and GitLab isn't secure,
 there is some additional configuration needed. See
 [NGINX Proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl)
 for details.
@@ -49,12 +49,12 @@ for details.
 ### Load Balancer(s) terminate SSL with backend SSL
 
 Configure your load balancer(s) to use the 'HTTP(S)' protocol rather than 'TCP'.
-The load balancer(s) will be responsible for managing SSL certificates that
-end users will see.
+The load balancer(s) is responsible for managing SSL certificates that
+end users see.
 
-Traffic will also be secure between the load balancer(s) and NGINX in this
+Traffic is secure between the load balancer(s) and NGINX in this
 scenario. There is no need to add configuration for proxied SSL since the
-connection will be secure all the way. However, configuration will need to be
+connection is secure all the way. However, configuration must be
 added to GitLab to configure SSL certificates. See
 [NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
 for details on managing SSL certificates and configuring NGINX.
@@ -75,13 +75,13 @@ for details on managing SSL certificates and configuring NGINX.
   to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the
   [web terminal](integration/terminal.md) integration guide for
   more details.
-- (*2*): When using HTTPS protocol for port 443, you will need to add an SSL
+- (*2*): When using HTTPS protocol for port 443, you must add an SSL
   certificate to the load balancers. If you wish to terminate SSL at the
   GitLab application server instead, use TCP protocol.
 
 ### GitLab Pages Ports
 
-If you're using GitLab Pages with custom domain support you will need some
+If you're using GitLab Pages with custom domain support you need some
 additional port configurations.
 GitLab Pages requires a separate virtual IP address. Configure DNS to point the
 `pages_external_url` from `/etc/gitlab/gitlab.rb` at the new virtual IP address. See the
@@ -103,7 +103,7 @@ GitLab Pages requires a separate virtual IP address. Configure DNS to point the
 
 Some organizations have policies against opening SSH port 22. In this case,
 it may be helpful to configure an alternate SSH hostname that allows users
-to use SSH on port 443. An alternate SSH hostname will require a new virtual IP address
+to use SSH on port 443. An alternate SSH hostname requires a new virtual IP address
 compared to the other GitLab HTTP configuration above.
 
 Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
@@ -114,7 +114,7 @@ Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
 
 ## Readiness check
 
-It is strongly recommend that multi-node deployments configure load balancers to use the [readiness check](../user/admin_area/monitoring/health_check.md#readiness) to ensure a node is ready to accept traffic, before routing traffic to it. This is especially important when utilizing Puma, as there is a brief period during a restart where Puma will not accept requests.
+It is strongly recommend that multi-node deployments configure load balancers to use the [readiness check](../user/admin_area/monitoring/health_check.md#readiness) to ensure a node is ready to accept traffic, before routing traffic to it. This is especially important when utilizing Puma, as there is a brief period during a restart where Puma doesn't accept requests.
 
 <!-- ## Troubleshooting
 

doc/administration/pseudonymizer.md

@@ -28,7 +28,7 @@ To configure the pseudonymizer, you need to:
 
 - Provide a manifest file that describes which fields should be included or
   pseudonymized ([example `manifest.yml` file](https://gitlab.com/gitlab-org/gitlab/tree/master/config/pseudonymizer.yml)).
-  A default manifest is provided with the GitLab installation. Using a relative file path will be resolved from the Rails root.
+  A default manifest is provided with the GitLab installation, using a relative file path that resolves from the Rails root.
   Alternatively, you can use an absolute file path.
 - Use an object storage and specify the connection parameters in the `pseudonymizer.upload.connection` configuration option.
 
@@ -100,7 +100,7 @@ sudo gitlab-rake gitlab:db:pseudonymizer
 sudo -u git -H bundle exec rake gitlab:db:pseudonymizer RAILS_ENV=production
 ```
 
-This will produce some CSV files that might be very large, so make sure the
+This produces some CSV files that might be very large, so make sure the
 `PSEUDONYMIZER_OUTPUT_DIR` has sufficient space. As a rule of thumb, at least
 10% of the database size is recommended.
 

doc/administration/raketasks/check.md

@@ -56,7 +56,7 @@ sudo -u git -H bundle exec rake gitlab:git:fsck RAILS_ENV=production
 Various types of files can be uploaded to a GitLab installation by users.
 These integrity checks can detect missing files. Additionally, for locally
 stored files, checksums are generated and stored in the database upon upload,
-and these checks will verify them against current files.
+and these checks verify them against current files.
 
 Currently, integrity checks are supported for the following types of file:
 
@@ -137,8 +137,8 @@ Done!
 
 ## LDAP check
 
-The LDAP check Rake task will test the bind DN and password credentials
-(if configured) and will list a sample of LDAP users. This task is also
+The LDAP check Rake task tests the bind DN and password credentials
+(if configured) and lists a sample of LDAP users. This task is also
 executed as part of the `gitlab:check` task, but can run independently.
 See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.
 

doc/administration/raketasks/github_import.md

@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 To retrieve and import GitHub repositories, you need a [GitHub personal access token](https://github.com/settings/tokens).
 A username should be passed as the second argument to the Rake task,
-which will become the owner of the project. You can resume an import
+which becomes the owner of the project. You can resume an import
 with the same command.
 
 Bear in mind that the syntax is very specific. Remove any spaces within the argument block and
@@ -20,7 +20,7 @@ before/after the brackets. Also, some shells (for example, `zsh`) can interpret
 ## Caveats
 
 If the GitHub [rate limit](https://developer.github.com/v3/#rate-limiting) is reached while importing,
-the importing process will wait (`sleep()`) until it can continue importing.
+the importing process waits (`sleep()`) until it can continue importing.
 
 ## Importing multiple projects
 
@@ -35,8 +35,8 @@ bundle exec rake "import:github[access_token,root,foo/bar]" RAILS_ENV=production
 ```
 
 In this case, `access_token` is your GitHub personal access token, `root`
-is your GitLab username, and  `foo/bar` is the new GitLab namespace/project that
-will get created from your GitHub project. Subgroups are also possible: `foo/foo/bar`.
+is your GitLab username, and `foo/bar` is the new GitLab namespace/project
+created from your GitHub project. Subgroups are also possible: `foo/foo/bar`.
 
 ## Importing a single project
 

doc/administration/raketasks/maintenance.md

@@ -107,8 +107,8 @@ The `gitlab:check` Rake task runs the following Rake tasks:
 - `gitlab:sidekiq:check`
 - `gitlab:app:check`
 
-It will check that each component was set up according to the installation guide and suggest fixes
-for issues found. This command must be run from your application server and will not work correctly on
+It checks that each component was set up according to the installation guide and suggest fixes
+for issues found. This command must be run from your application server and doesn't work correctly on
 component servers like [Gitaly](../gitaly/index.md#run-gitaly-on-its-own-server).
 
 You may also have a look at our troubleshooting guides for:
@@ -300,7 +300,7 @@ To check the status of specific migrations, you can use the following Rake task:
 sudo gitlab-rake db:migrate:status
 ```
 
-This will output a table with a `Status` of `up` or `down` for
+This outputs a table with a `Status` of `up` or `down` for
 each Migration ID.
 
 ```shell
@@ -313,7 +313,7 @@ database: gitlabhq_production
 
 ## Run incomplete database migrations
 
-Database migrations can be stuck in an incomplete state. That is, they'll have a `down`
+Database migrations can be stuck in an incomplete state, with a `down`
 status in the output of the `sudo gitlab-rake db:migrate:status` command.
 
 To complete these migrations, use the following Rake task:

doc/administration/raketasks/project_import_export.md

@@ -36,7 +36,7 @@ sudo gitlab-rake gitlab:import_export:version
 bundle exec rake gitlab:import_export:version RAILS_ENV=production
 ```
 
-The current list of DB tables that will be exported can be listed by using the following command:
+The current list of DB tables to export can be listed by using the following command:
 
 ```shell
 # Omnibus installations

doc/administration/raketasks/uploads/migrate.md

@@ -16,7 +16,7 @@ There is a Rake task for migrating uploads between different storage types.
 After [configuring the object storage](../../uploads.md#using-object-storage) for GitLab's
 uploads, use this task to migrate existing uploads from the local storage to the remote storage.
 
-All of the processing will be done in a background worker and requires **no downtime**.
+All of the processing is done in a background worker and requires **no downtime**.
 
 Read more about using [object storage with GitLab](../../object_storage.md).
 
@@ -133,7 +133,7 @@ migrate your data out of object storage and back into your local storage.
 
 CAUTION: **Warning:**
 **Extended downtime is required** so no new files are created in object storage during
-the migration. A configuration setting will be added soon to allow migrating
+the migration. A configuration setting is planned to allow migrating
 from object storage to local files with only a brief moment of downtime for configuration changes.
 To follow progress, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30979).
 

doc/administration/raketasks/uploads/sanitize.md

@@ -41,8 +41,8 @@ The Rake task accepts following parameters.
 
 | Parameter    | Type    | Description                                                                                                                 |
 |:-------------|:--------|:----------------------------------------------------------------------------------------------------------------------------|
-| `start_id`   | integer | Only uploads with equal or greater ID will be processed                                                                     |
-| `stop_id`    | integer | Only uploads with equal or smaller ID will be processed                                                                     |
+| `start_id`   | integer | Only uploads with equal or greater ID are processed                                                                     |
+| `stop_id`    | integer | Only uploads with equal or smaller ID are processed                                                                     |
 | `dry_run`    | boolean | Do not remove EXIF data, only check if EXIF data are present or not. Defaults to `true`                                     |
 | `sleep_time` | float   | Pause for number of seconds after processing each image. Defaults to 0.3 seconds                                            |
 | `uploader`   | string  | Run sanitization only for uploads of the given uploader: `FileUploader`, `PersonalFileUploader`, or `NamespaceFileUploader` |
@@ -66,7 +66,7 @@ To remove EXIF data on uploads with an ID between 100 and 5000 and pause for 0.1
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:remove_exif[100,5000,false,0.1] 2>&1 | tee exif.log
 ```
 
-The output is written into an `exif.log` file because it will probably be long.
+The output is written into an `exif.log` file because it is often long.
 
 If sanitization fails for an upload, an error message should be in the output of the Rake task.
 Typical reasons include that the file is missing in the storage or it's not a valid image.

doc/downgrade_ee_to_ce/README.md

@@ -24,8 +24,7 @@ alternative authentication methods to your users.
 ### Remove Service Integration entries from the database
 
 The `JenkinsService` and `GithubService` classes are only available in the Enterprise Edition codebase,
-so if you downgrade to the Community Edition, you'll come across the following
-error:
+so if you downgrade to the Community Edition, the following error displays:
 
 ```plaintext
 Completed 500 Internal Server Error in 497ms (ActiveRecord: 32.2ms)

doc/migrate_ci_to_ce/README.md

@@ -11,7 +11,7 @@ Beginning with version 8.0 of GitLab Community Edition (CE) and Enterprise
 Edition (EE), GitLab CI is no longer its own application, but is instead built
 into the CE and EE applications.
 
-This guide will detail the process of migrating your CI installation and data
+This guide details the process of migrating your CI installation and data
 into your GitLab CE or EE installation. **You can only migrate CI data from
 GitLab CI 8.0 to GitLab 8.0; migrating between other versions (e.g.7.14 to 8.1)
 is not possible.**
@@ -28,9 +28,9 @@ The migration consists of three parts: updating GitLab and GitLab CI, moving
 data, and redirecting traffic.
 
 Please note that CI builds triggered on your GitLab server in the time between
-updating to 8.0 and finishing the migration will be lost. Your GitLab server
+updating to 8.0 and finishing the migration are lost. Your GitLab server
 can be online for most of the procedure; the only GitLab downtime (if any) is
-during the upgrade to 8.0. Your CI service will be offline from the moment you
+during the upgrade to 8.0. Your CI service remains offline from the moment you
 upgrade to 8.0 until you finish the migration procedure.
 
 ## Before upgrading
@@ -47,8 +47,8 @@ If you want to migrate your existing data, continue reading.
 
 ### 0. Updating Omnibus from versions prior to 7.13
 
-If you are updating from older versions you should first update to 7.14 and then to 8.0.
-Otherwise it's pretty likely that you will encounter problems described in the [Troubleshooting](#troubleshooting).
+If you are updating from older versions you should first update to 7.14 and then to 8.0
+to avoid the problems described in the [Troubleshooting](#troubleshooting) section.
 
 ### 1. Verify that backups work
 
@@ -123,7 +123,7 @@ store build traces on the same storage as your Git repositories.
 
 ## I. Upgrading
 
-From this point on, GitLab CI will be unavailable for your end users.
+From this point on, GitLab CI is unavailable for your end users.
 
 ### 1. Upgrade GitLab to 8.0
 
@@ -169,10 +169,10 @@ sudo -u gitlab_ci -H bundle exec whenever --clear-crontab RAILS_ENV=production
 ### 1. Database encryption key
 
 Move the database encryption key from your CI server to your GitLab
-  server. The command below will show you what you need to copy-paste to your
-GitLab server. On Omnibus GitLab servers you will have to add a line to
-`/etc/gitlab/gitlab.rb`. On GitLab servers installed from source you will have
-to replace the contents of `/home/git/gitlab/config/secrets.yml`.
+  server. The command below shows you what you need to copy-paste to your
+GitLab server. On Omnibus GitLab servers you must add a line to
+`/etc/gitlab/gitlab.rb`. On GitLab servers installed from source you must
+replace the contents of `/home/git/gitlab/config/secrets.yml`.
 
 ```shell
 # On your CI server:
@@ -188,8 +188,8 @@ sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production
 
 Create your final CI data export. If you are converting from MySQL to
 PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the Rake command. When
-the command finishes it will print the path to your data export archive; you
-will need this file later.
+the command finishes it prints the path to your data export archive; you
+need this file later.
 
 ```shell
 # On your CI server:
@@ -208,7 +208,7 @@ If you were running GitLab and GitLab CI on the same server you can skip this
 step.
 
 Copy your CI data archive to your GitLab server. There are many ways to do
-this, below we use SSH agent forwarding and `scp`, which will be easy and fast
+this, below we use SSH agent forwarding and `scp`, which is easy and fast
 for most setups. You can also copy the data archive first from the CI server to
 your laptop and then from your laptop to the GitLab server.
 
@@ -235,7 +235,7 @@ sudo mv /path/to/12345_gitlab_ci_backup.tar /home/git/gitlab/tmp/backups/
 
 ### 5. Import the CI data into GitLab
 
-This step will delete any existing CI data on your GitLab server. There should
+This step deletes any existing CI data on your GitLab server. There should
 be no CI data yet because you turned CI on the GitLab server off earlier.
 
 ```shell
@@ -274,8 +274,8 @@ so that existing links to your CI server keep working.
 ### 1. Update NGINX configuration
 
 To ensure that your existing CI runners are able to communicate with the
-migrated installation, and that existing build triggers still work, you'll need
-to update your NGINX configuration to redirect requests for the old locations to
+migrated installation, and that existing build triggers still work, you must
+update your NGINX configuration to redirect requests for the old locations to
 the new ones.
 
 Edit `/etc/nginx/sites-available/gitlab_ci` and paste:

doc/topics/application_development_platform/index.md

@@ -35,12 +35,12 @@ of newer, more efficient, more profitable, and less error-prone techniques for s
 
 Because at GitLab we are [cloud-native first](https://about.gitlab.com/handbook/product/#cloud-native-first) our
 Application Development Platform initially focuses on providing robust support for Kubernetes, with other platforms
-to follow. Teams can bring their own clusters and we will additionally make it easy to create new infrastructure
+to follow. Teams can bring their own clusters and we additionally make it easy to create new infrastructure
 with various cloud providers.
 
 ### Build, test, deploy
 
-In order to provide modern DevOps workflows, our Application Development Platform will rely on
+In order to provide modern DevOps workflows, our Application Development Platform relies on
 [Auto DevOps](../autodevops/index.md) to provide those workflows. Auto DevOps works with
 any Kubernetes cluster; you're not limited to running on GitLab's infrastructure. Additionally, Auto DevOps offers
 an incremental consumption path. Because it is [composable](../autodevops/customize.md#using-components-of-auto-devops),

doc/topics/git/lfs/migrate_to_git_lfs.md

@@ -10,9 +10,8 @@ description: "How to migrate an existing Git repository to Git LFS with BFG."
 Using Git LFS can help you to reduce the size of your Git
 repository and improve its performance.
 
-However, simply adding the
-large files that are already in your repository to Git LFS,
-will not actually reduce the size of your repository because
+However, simply adding the large files that are already in your repository to Git LFS
+doesn't actually reduce the size of your repository because
 the files are still referenced by previous commits.
 
 Through the method described on this document, first migrate
@@ -41,7 +40,7 @@ Before beginning, make sure:
   Branches based on the repository before applying this method cannot be merged.
   Branches based on the repo before applying this method cannot be merged.
 
-To follow this tutorial, you'll need:
+To follow this tutorial, you need:
 
 - Maintainer permissions to the existing Git repository
   you'd like to migrate to LFS with access through the command line.
@@ -74,7 +73,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
 
 1. Clone `--mirror` the repository:
 
-   Cloning with the mirror flag will create a bare repository.
+   Cloning with the mirror flag creates a bare repository.
    This ensures you get all the branches within the repo.
 
    It creates a directory called `<repo-name>.git`
@@ -150,7 +149,7 @@ Consider an example upstream project, `git@gitlab.com:gitlab-tests/test-git-lfs-
    ```
 
    Now all existing the files you converted, as well as the new
-   ones you add, will be properly tracked with LFS.
+   ones you add, are properly tracked with LFS.
 
 1. [Re-protect the default branch](../../../user/project/protected_branches.md):
 

doc/topics/index.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Welcome to Topics! We have organized our content resources into topics
 to get you started on areas of your interest. Each topic page
-consists of an index listing all related content. It will guide
+consists of an index listing all related content. It guides
 you through better understanding GitLab's concepts
 through our regular docs, and, when available, through articles (guides,
 tutorials, technical overviews, blog posts) and videos.

doc/topics/offline/quick_start_guide.md

@@ -18,12 +18,12 @@ server's name.
 
 Follow the installation instructions [as outlined in the omnibus install
 guide](https://about.gitlab.com/install/#ubuntu), but make sure to specify an `http`
-URL for the `EXTERNAL_URL` installation step. Once installed, we will manually
+URL for the `EXTERNAL_URL` installation step. Once installed, we can manually
 configure the SSL ourselves.
 
 It is strongly recommended to setup a domain for IP resolution rather than bind
 to the server's IP address. This better ensures a stable target for our certs' CN
-and will make long-term resolution simpler.
+and makes long-term resolution simpler.
 
 ```shell
 sudo EXTERNAL_URL="http://my-host.internal" install gitlab-ee

doc/user/admin_area/appearance.md

@@ -16,7 +16,7 @@ section.
 
 By default, the navigation bar has the GitLab logo, but this can be customized with
 any image desired. It is optimized for images 28px high (any width), but any image can be
-used (less than 1MB) and it will automatically be resized.
+used (less than 1MB) and it is automatically resized.
 
 ![Navigation bar header logo screenshot](img/appearance_header_logo_v12_3.png)
 
@@ -24,7 +24,7 @@ Once you select and upload an image, click **Update appearance settings** at the
 of the page to activate it in the GitLab instance.
 
 NOTE: **Note:**
-GitLab pipeline emails will also display the custom logo.
+GitLab pipeline emails also display the custom logo.
 
 ## Favicon
 
@@ -45,7 +45,7 @@ of the page to activate it in the GitLab instance.
 > - [Added](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
 
 You can add a small header message, a small footer message, or both, to the interface
-of your GitLab instance. These messages will appear on all projects and pages of the
+of your GitLab instance. These messages appear on all projects and pages of the
 instance, including the sign in / sign up page. The default color is white text on
 an orange background, but this can be customized by clicking on **Customize colors**.
 
@@ -69,7 +69,7 @@ and logo. You can make full use of [Markdown](../markdown.md) in the description
 ![sign in message screenshot](img/appearance_sign_in_v12_3.png)
 
 The optimal size for the logo is 640x360px, but any image can be used (below 1MB)
-and it will be resized automatically. The logo image will appear between the title and
+and it is resized automatically. The logo image appears between the title and
 the description, on the left of the sign-up page.
 
 ![sign in message preview screenshot](img/appearance_sign_in_preview_v12_3.png)
@@ -88,12 +88,12 @@ You can make full use of [Markdown](../markdown.md) in the description:
 
 ![new project message screenshot](img/appearance_new_project_v12_3.png)
 
-The message will be displayed below the **New Project** message, on the left side
+The message is displayed below the **New Project** message, on the left side
 of the **New project page**.
 
 After you add a message, click **Update appearance settings** at the bottom of the page
 to activate it in the GitLab instance. You can also click on the **New project page**
-button, which will bring you to the new project page so you can review the change.
+button, which brings you to the new project page so you can review the change.
 
 ![new project message preview screenshot](img/appearance_new_project_preview_v12_3.png)
 

doc/user/admin_area/settings/external_authorization.md

@@ -17,26 +17,26 @@ authorization with your own defined service.
 
 ## Overview
 
-Once the external service is configured and enabled, when a project is accessed,
-a request is made to the external service with the user information and project
-classification label assigned to the project. When the service replies with a
-known response, the result is cached for 6 hours.
+After the external service is configured and enabled, when a project is
+accessed, a request is made to the external service with the user information
+and project classification label assigned to the project. When the service
+replies with a known response, the result is cached for six hours.
 
-If the external authorization is enabled, GitLab will further block pages and
+If the external authorization is enabled, GitLab further blocks pages and
 functionality that render cross-project data. That includes:
 
 - Most pages under Dashboard (Activity, Milestones, Snippets, Assigned merge
   requests, Assigned issues, To-Do List).
 - Under a specific group (Activity, Contribution analytics, Issues, Issue boards,
   Labels, Milestones, Merge requests).
-- Global and Group search will be disabled.
+- Global and Group search are disabled.
 
 This is to prevent performing to many requests at once to the external
 authorization service.
 
 Whenever access is granted or denied this is logged in a log file called
-`external-policy-access-control.log`.
-Read more about logs GitLab keeps in the [omnibus documentation](https://docs.gitlab.com/omnibus/settings/logs.html).
+`external-policy-access-control.log`. Read more about the logs GitLab keeps in
+the [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/logs.html).
 
 ## Configuration
 
@@ -48,7 +48,7 @@ The external authorization service can be enabled by an admin on the GitLab's
 The available required properties are:
 
 - **Service URL**: The URL to make authorization requests to. When leaving the
-  URL blank, cross project features will remain available while still being able
+  URL blank, cross project features remain available while still being able
   to specify classification labels for projects.
 - **External authorization request timeout**: The timeout after which an
   authorization request is aborted. When a request times out, access is denied
@@ -58,19 +58,21 @@ The available required properties are:
 - **Client authentication key**: Private key for the certificate when
   authentication is required for the external authorization service, this is
   encrypted when stored.
-- **Client authentication key password**: Passphrase to use for the private key when authenticating with the external service this is encrypted when stored.
+- **Client authentication key password**: Passphrase to use for the private key
+  when authenticating with the external service this is encrypted when stored.
 - **Default classification label**: The classification label to use when
   requesting authorization if no specific label is defined on the project
 
 When using TLS Authentication with a self signed certificate, the CA certificate
-needs to be trusted by the OpenSSL installation. When using GitLab installed using
-Omnibus, learn to install a custom CA in the
-[omnibus documentation](https://docs.gitlab.com/omnibus/settings/ssl.html). Alternatively learn where to install
-custom certificates using `openssl version -d`.
+needs to be trusted by the OpenSSL installation. When using GitLab installed
+using Omnibus, learn to install a custom CA in the
+[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/ssl.html).
+Alternatively, learn where to install custom certificates by using
+`openssl version -d`.
 
 ## How it works
 
-When GitLab requests access, it will send a JSON POST request to the external
+When GitLab requests access, it sends a JSON POST request to the external
 service with this body:
 
 ```json
@@ -85,14 +87,17 @@ service with this body:
 }
 ```
 
-The `user_ldap_dn` is optional and is only sent when the user is logged in
+The `user_ldap_dn` is optional and is only sent when the user is signed in
 through LDAP.
 
-`identities` will contain the details of all the identities associated with the user. This will be an empty array if there are no identities associated with the user.
+`identities` contains the details of all the identities associated with the
+user. This is an empty array if there are no identities associated with the
+user.
 
 When the external authorization service responds with a status code 200, the
 user is granted access. When the external service responds with a status code
-401 or 403, the user is denied access. In any case, the request is cached for 6 hours.
+401 or 403, the user is denied access. In any case, the request is cached for
+six hours.
 
 When denying access, a `reason` can be optionally specified in the JSON body:
 
@@ -102,20 +107,20 @@ When denying access, a `reason` can be optionally specified in the JSON body:
 }
 ```
 
-Any other status code than 200, 401 or 403 will also deny access to the user, but the
-response will not be cached.
+Any other status code than 200, 401 or 403 also deny access to the user, but the
+response isn't cached.
 
 If the service times out (after 500ms), a message "External Policy Server did
-not respond" will be displayed.
+not respond" is displayed.
 
 ## Classification labels
 
 You can use your own classification label in the project's
 **Settings > General > General project settings** page in the "Classification
 label" box. When no classification label is specified on a project, the default
-label defined in the [global settings](#configuration) will be used.
+label defined in the [global settings](#configuration) is used.
 
-The label will be shown on all project pages in the upper right corner.
+The label is shown on all project pages in the upper right corner.
 
 ![classification label on project page](img/classification_label_on_project_page.png)
 

doc/user/admin_area/settings/index.md

@@ -63,7 +63,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | Option | Description |
 | ------ | ----------- |
 | [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. |
-| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration will be run after the project's own configuration. |
+| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. |
 | [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using GitLab's Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
 
 ## Reporting
@@ -98,7 +98,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 
 | Option | Description |
 | ------ | ----------- |
-| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **Admin Area > Geo > Settings**, and will no longer be available at **Admin Area > Settings > Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
+| Geo    | Geo allows you to replicate your GitLab instance to other geographical locations. Redirects to **Admin Area > Geo > Settings** are no longer available at **Admin Area > Settings > Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896). |
 
 ## Preferences
 

doc/user/admin_area/settings/terms.md

@@ -29,7 +29,7 @@ To enforce acceptance of a Terms of Service and Privacy Policy:
 ![Enable enforcing Terms of Service](img/enforce_terms.png)
 
 For each update to the terms, a new version is stored. When a user accepts or declines the terms,
-GitLab will record which version they accepted or declined.
+GitLab records which version they accepted or declined.
 
 ## New users
 
@@ -37,28 +37,28 @@ When this feature is enabled, a checkbox is added to the sign-up form.
 
 ![Sign up form](img/sign_up_terms.png)
 
-This checkbox will be required during sign up.
+This checkbox is required during sign up.
 
 Users can review the terms entered in the admin panel before
-accepting. The page will be opened in a new window so they can
+accepting. The page is opened in a new window so they can
 continue their registration afterwards.
 
 ## Accepting terms
 
 When this feature is enabled, the users that have not accepted the
-terms of service will be presented with a screen where they can either
+terms of service are presented with a screen where they can either
 accept or decline the terms.
 
 ![Respond to terms](img/respond_to_terms.png)
 
-If the user accepts the terms, they will be directed to where they
-were going. After a sign-in or sign-up this will most likely be the
+If the user accepts the terms, they are directed to where they
+were going. After a sign-in or sign-up this is most likely the
 dashboard.
 
 If the user was already logged in when the feature was turned on,
-they will be asked to accept the terms on their next interaction.
+they are asked to accept the terms on their next interaction.
 
-If a user declines the terms, they will be signed out.
+If a user declines the terms, they are signed out.
 
 <!-- ## Troubleshooting