Add latest changes from gitlab-org/gitlab@master

28 files changed, 232 insertions, 226 deletions

diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index 8e7d8049467..1b0082687e6 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -49,7 +49,7 @@ developed and tested. We aim to be compatible with most external
 
 To set up an external database, you can either:
 
-- Set up streaming replication yourself (for example, in AWS RDS).
+- Set up [streaming replication](https://www.postgresql.org/docs/11/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example AWS RDS, bare metal not managed by Omnibus, etc.).
 - Perform the Omnibus configuration manually as follows.
 
 #### Leverage your cloud provider's tools to replicate the primary database
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index c22d9d0d72b..a51641f661f 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -2313,7 +2313,7 @@ in the future.
   </a>
 </div>
 
-## Configure Advanced Search **(PREMIUM SELF)**
+## Configure Advanced Search
 
 You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
 for faster, more advanced code search across your entire GitLab instance.
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 7025dacdae1..8cf9efe1d2c 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -2317,7 +2317,7 @@ in the future.
   </a>
 </div>
 
-## Configure Advanced Search **(PREMIUM SELF)**
+## Configure Advanced Search
 
 You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
 for faster, more advanced code search across your entire GitLab instance.
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 80460705eeb..7f7777455c2 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -7,20 +7,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Reference architecture: up to 3,000 users **(PREMIUM SELF)**
 
-This page describes GitLab reference architecture for up to 3,000 users.
-It is designed to help your organization achieve a
-highly-available GitLab deployment. If you do not have the expertise or need to
-maintain a highly-available environment, you can have a simpler and less
-costly-to-operate environment by using the
-[2,000-user reference architecture](2k_users.md).
-If you have fewer than 3,000 users and still want a highly-available GitLab deployment,
-you should still use this reference architecture but scale down the node sizes.
+This GitLab reference architecture can help you deploy GitLab to up to 3,000
+users, and then maintain uptime and access for those users. You can also use
+this architecture to provide improved GitLab uptime and availability for fewer
+than 3,000 users. For fewer users, reduce the stated node sizes as needed.
+
+If maintining a high level of uptime for your GitLab environment isn't a
+requirement, or if you don't have the expertise to maintain this sort of
+environment, we recommend using the [2,000-user reference architecture](2k_users.md)
+for your GitLab installation.
 
 For a full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
 > - **Supported users (approximate):** 3,000
-> - **High Availability:** Yes ([Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution for HA)
+> - **High Availability:** Yes, although [Praefect](#configure-praefect-postgresql) needs a third-party PostgreSQL solution
 > - **Test requests per second (RPS) rates:** API: 60 RPS, Web: 6 RPS, Git (Pull): 6 RPS, Git (Push): 1 RPS
 
 | Service                                    | Nodes       | Configuration         | GCP            | AWS         | Azure   |
@@ -135,10 +136,15 @@ uploads, or artifacts), using an [object storage service](#configure-the-object-
 is recommended instead of using NFS. Using an object storage service also
 doesn't require you to provision and maintain a node.
 
-It's also worth noting that at this time [Praefect requires its own database server](../gitaly/praefect.md#postgresql) and
-that to achieve full High Availability a third party PostgreSQL database solution will be required.
-We hope to offer a built in solutions for these restrictions in the future but in the meantime a non HA PostgreSQL server
-can be set up via Omnibus GitLab, which the above specs reflect. Refer to the following issues for more information: [`omnibus-gitlab#5919`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5919) & [`gitaly#3398`](https://gitlab.com/gitlab-org/gitaly/-/issues/3398)
+[Praefect requires its own database server](../gitaly/praefect.md#postgresql),
+and a third-party PostgreSQL database solution is required to achieve full
+high availability. Although we hope to offer a built-in solution for these
+restrictions in the future, you can set up a non-HA PostgreSQL server by using
+Omnibus GitLab (which the previous specifications reflect). Refer to the
+following issues for more information:
+
+- [`omnibus-gitlab#5919`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5919)
+- [`gitaly#3398`](https://gitlab.com/gitlab-org/gitaly/-/issues/3398)
 
 ## Setup components
 
@@ -1997,7 +2003,7 @@ in the future.
   </a>
 </div>
 
-## Configure Advanced Search **(PREMIUM SELF)**
+## Configure Advanced Search
 
 You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
 for faster, more advanced code search across your entire GitLab instance.
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index bb01ed5c5b5..606701a4d83 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -2331,7 +2331,7 @@ in the future.
   </a>
 </div>
 
-## Configure Advanced Search **(PREMIUM SELF)**
+## Configure Advanced Search
 
 You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
 for faster, more advanced code search across your entire GitLab instance.
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 71d74bbc923..0a236eac243 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -1992,7 +1992,7 @@ in the future.
   </a>
 </div>
 
-## Configure Advanced Search **(PREMIUM SELF)**
+## Configure Advanced Search
 
 You can leverage Elasticsearch and [enable Advanced Search](../../integration/elasticsearch.md)
 for faster, more advanced code search across your entire GitLab instance.
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 54d981d65a2..277064c8666 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -110,7 +110,7 @@ rspec 2.6:
 
 ## Global keywords
 
-Some keywords are not defined within a job. These keywords control pipeline behavior
+Some keywords are not defined in a job. These keywords control pipeline behavior
 or import additional pipeline configuration:
 
 | Keyword                 | Description |
@@ -709,8 +709,8 @@ You can use syntax in [`script`](README.md#script) sections to:
 Use `stage` to define which stage a job runs in. Jobs in the same
 `stage` can execute in parallel (subject to [certain conditions](#use-your-own-runners)).
 
-Jobs without a `stage` entry use the `test` stage by default. If [`stages`](#stages)
-is not defined in the pipeline, you can use the 5 default stages, which execute in
+Jobs without a `stage` entry use the `test` stage by default. If you do not define
+[`stages`](#stages) in the pipeline, you can use the 5 default stages, which execute in
 this order:
 
 - [`.pre`](#pre-and-post)
@@ -1532,8 +1532,11 @@ job:
     - branches
 ```
 
-In the following example, `job` runs only for refs that are tagged, or if a build is
-explicitly requested by an API trigger or a [pipeline schedule](../pipelines/schedules.md):
+In the following example, `job` runs only for:
+
+- Git tags
+- [Triggers](../triggers/README.md#trigger-token)
+- [Scheduled pipelines](../pipelines/schedules.md)
 
 ```yaml
 job:
@@ -2092,12 +2095,13 @@ build_job:
       artifacts: true
 ```
 
-Downloading artifacts from jobs that are run in [`parallel:`](#parallel) is not supported.
+You can't download artifacts from jobs that run in [`parallel:`](#parallel).
+
+To download artifacts between [parent-child pipelines](../parent_child_pipelines.md),
+use [`needs:pipeline`](#artifact-downloads-to-child-pipelines).
 
-To download artifacts between [parent-child pipelines](../parent_child_pipelines.md) use [`needs:pipeline`](#artifact-downloads-to-child-pipelines).
-Downloading artifacts from the same ref as the currently running pipeline is not
-recommended because artifacts could be overridden by concurrent pipelines running
-on the same ref.
+You should not download artifacts from the same ref as a running pipeline. Concurrent
+pipelines running on the same ref could override the artifacts.
 
 ##### Artifact downloads to child pipelines
 
@@ -2504,11 +2508,6 @@ You can't use variables defined in a `script` section.
 
 #### `environment:on_stop`
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22191) in GitLab 8.13.
-> - Starting with GitLab 8.14, when you have an environment that has a stop action
->   defined, GitLab automatically triggers a stop action when the associated
->   branch is deleted.
-
 Closing (stopping) environments can be achieved with the `on_stop` keyword
 defined under `environment`. It declares a different job that runs to close the
 environment.
@@ -2517,8 +2516,6 @@ Read the `environment:action` section for an example.
 
 #### `environment:action`
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/22191) in GitLab 8.13.
-
 Use the `action` keyword to specify jobs that prepare, start, or stop environments.
 
 | **Value** | **Description**                                                                                                                                               |
@@ -3459,8 +3456,7 @@ for more details.
 
 ### `retry`
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3442) in GitLab 9.5.
-> - [Behavior expanded](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) in GitLab 11.5 to control which failures to retry on.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3515) in GitLab 11.5, you can control which failures to retry on.
 
 Use `retry` to configure how many times a job is retried in
 case of a failure.
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index 3608636dd55..c42e9224105 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -139,14 +139,14 @@ end
 
 Self-managed:
 
-- `default` - Everyone
+- `default`: Everyone.
 
 GitLab.com:
 
-- `default` - Any system-wide feature
-- `free` - Namespaces and projects with a Free subscription
-- `bronze`- Namespaces and projects with a Bronze subscription
-- `silver` - Namespaces and projects with a Silver subscription
-- `gold` - Namespaces and projects with a Gold subscription
+- `default`: Any system-wide feature.
+- `free`: Namespaces and projects with a Free subscription.
+- `bronze`: Namespaces and projects with a Bronze subscription. This tier is no longer available for purchase.
+- `silver`: Namespaces and projects with a Premium subscription.
+- `gold`: Namespaces and projects with an Ultimate subscription.
 
 The `test` environment doesn't have any plans.
diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md
index 4710ae4606c..7c4f869d1a7 100644
--- a/doc/development/internal_api.md
+++ b/doc/development/internal_api.md
@@ -488,7 +488,7 @@ POST /namespaces/:id/gitlab_subscription
 | `plan_code` | string  | no       | Subscription tier code |
 | `seats`     | integer | no       | Number of seats in subscription |
 | `max_seats_used` | integer | no  | Highest number of active users in the last month |
-| `auto_renew` | boolean | no      | Whether subscription will auto renew on end date |
+| `auto_renew` | boolean | no      | Whether subscription auto-renews on end date |
 | `trial`     | boolean | no       | Whether subscription is a trial |
 | `trial_starts_on` | date | no    | Start date of trial |
 | `trial_ends_on` | date | no      | End date of trial |
@@ -539,7 +539,7 @@ PUT /namespaces/:id/gitlab_subscription
 | `plan_code` | string  | no       | Subscription tier code |
 | `seats`     | integer | no       | Number of seats in subscription |
 | `max_seats_used` | integer | no  | Highest number of active users in the last month |
-| `auto_renew` | boolean | no      | Whether subscription will auto renew on end date |
+| `auto_renew` | boolean | no      | Whether subscription auto-renews on end date |
 | `trial`     | boolean | no       | Whether subscription is a trial |
 | `trial_starts_on` | date | no    | Start date of trial. Required if trial is true. |
 | `trial_ends_on` | date | no      | End date of trial |
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index 759b19db36f..dd193ac9022 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -374,7 +374,7 @@ standard Rails migration helper methods. Calling more than one migration
 helper is not a problem if they're executed on the same table.
 
 Using the `with_lock_retries` helper method is advised when a database
-migration involves one of the [high-traffic tables](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3).
+migration involves one of the [high-traffic tables](#high-traffic-tables).
 
 Example changes:
 
@@ -606,7 +606,7 @@ we have to employ `add_concurrent_foreign_key` and `add_concurrent_index`
 instead of `add_reference`.
 
 If you have a new or empty table that doesn't reference a
-[high-traffic table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3),
+[high-traffic table](#high-traffic-tables),
 we recommend that you use `add_reference` in a single-transaction migration. You can
 combine it with other operations that don't require `disable_ddl_transaction!`.
 
@@ -709,11 +709,8 @@ Dropping a database table is uncommon, and the `drop_table` method
 provided by Rails is generally considered safe. Before dropping the table,
 please consider the following:
 
-If your table has foreign keys on a high-traffic table (like `projects`), then
-the `DROP TABLE` statement might fail with **statement timeout** error. Determining
-what tables are high traffic can be difficult. Self-managed instances might
-use different features of GitLab with different usage patterns, thus making
-assumptions based on GitLab.com is not enough.
+If your table has foreign keys on a [high-traffic table](#high-traffic-tables) (like `projects`), then
+the `DROP TABLE` statement is likely to stall concurrent traffic until it fails with **statement timeout** error.
 
 Table **has no records** (feature was never in use) and **no foreign
 keys**:
@@ -1028,3 +1025,20 @@ D, [2020-07-06T00:37:12.653459 #130101] DEBUG -- :   AddAndSeedMyColumn::User Up
 D, [2020-07-06T00:37:12.653648 #130101] DEBUG -- :   ↳ config/initializers/config_initializers_active_record_locking.rb:13:in `_update_row'
 == 20200705232821 AddAndSeedMyColumn: migrated (0.1706s) =====================
 ```
+
+## High traffic tables
+
+Here's a list of current [high-traffic tables](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml). 
+
+Determining what tables are high-traffic can be difficult. Self-managed instances might use
+different features of GitLab with different usage patterns, thus making assumptions based 
+on GitLab.com not enough.
+
+To identify a high-traffic table for GitLab.com the following measures are considered.
+Note that the metrics linked here are GitLab-internal only:
+
+- [Read operations](https://thanos.gitlab.net/graph?g0.range_input=2h&g0.max_source_resolution=0s&g0.expr=topk(500%2C%20sum%20by%20(relname)%20(rate(pg_stat_user_tables_seq_tup_read%7Benvironment%3D%22gprd%22%7D%5B12h%5D)%20%2B%20rate(pg_stat_user_tables_idx_scan%7Benvironment%3D%22gprd%22%7D%5B12h%5D)%20%2B%20rate(pg_stat_user_tables_idx_tup_fetch%7Benvironment%3D%22gprd%22%7D%5B12h%5D)))&g0.tab=1)
+- [Number of records](https://thanos.gitlab.net/graph?g0.range_input=2h&g0.max_source_resolution=0s&g0.expr=topk(500%2C%20sum%20by%20(relname)%20(rate(pg_stat_user_tables_n_live_tup%7Benvironment%3D%22gprd%22%7D%5B12h%5D)))&g0.tab=1)
+- [Size](https://thanos.gitlab.net/graph?g0.range_input=2h&g0.max_source_resolution=0s&g0.expr=topk(500%2C%20sum%20by%20(relname)%20(rate(pg_total_relation_size_bytes%7Benvironment%3D%22gprd%22%7D%5B12h%5D)))&g0.tab=1) is greater than 10 GB
+
+Any table which has some high read operation compared to current [high-traffic tables](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L4) might be a good candidate.
diff --git a/doc/development/usage_ping/metrics_dictionary.md b/doc/development/usage_ping/metrics_dictionary.md
index 1407a356363..3f43aaa916f 100644
--- a/doc/development/usage_ping/metrics_dictionary.md
+++ b/doc/development/usage_ping/metrics_dictionary.md
@@ -41,6 +41,7 @@ Each metric is defined in a separate YAML file consisting of a number of fields:
 | `milestone`         | no       | The milestone when the metric is introduced. |
 | `milestone_removed` | no       | The milestone when the metric is removed. |
 | `introduced_by_url` | no       | The URL to the Merge Request that introduced the metric. |
+| `skip_validation`   | no       | This should **not** be set. [Used for imported metrics until we review, update and make them valid](https://gitlab.com/groups/gitlab-org/-/epics/5425). |
 
 ### Example YAML metric definition
 
diff --git a/doc/user/admin_area/settings/instance_template_repository.md b/doc/user/admin_area/settings/instance_template_repository.md
index 54c2943b051..600d99934aa 100644
--- a/doc/user/admin_area/settings/instance_template_repository.md
+++ b/doc/user/admin_area/settings/instance_template_repository.md
@@ -23,7 +23,7 @@ select the project to serve as the custom template repository.
 ![File templates in the Admin Area](img/file_template_admin_area.png)
 
 After that, you can add custom templates to the selected repository and use them for the entire instance.
-They will be available on the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns)
+They are available in the [Web Editor's dropdown](../../project/repository/web_editor.md#template-dropdowns)
 and through the [API settings](../../../api/settings.md).
 
 Templates must be added to a specific subdirectory in the repository,
@@ -60,12 +60,12 @@ extension and not be empty. So, the hierarchy should look like this:
     |-- another_metrics-dashboard.yml
 ```
 
-Your custom templates will be displayed on the dropdown menu when a new file is added through the GitLab UI:
+Your custom templates are displayed on the dropdown menu when a new file is added through the GitLab UI:
 
 ![Custom template dropdown menu](img/file_template_user_dropdown.png)
 
-If this feature is disabled or no templates are present, there will be
-no "Custom" section in the selection dropdown.
+If this feature is disabled or no templates are present,
+no **Custom** section displays in the selection dropdown.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/admin_area/settings/push_event_activities_limit.md b/doc/user/admin_area/settings/push_event_activities_limit.md
index 1d6424face0..7032c1031a9 100644
--- a/doc/user/admin_area/settings/push_event_activities_limit.md
+++ b/doc/user/admin_area/settings/push_event_activities_limit.md
@@ -14,7 +14,7 @@ allowed at once. If the number of events is greater than this, GitLab creates
 bulk push event instead.
 
 For example, if 4 branches are pushed and the limit is currently set to 3,
-you'll see the following in the activity feed:
+the activity feed displays:
 
 ![Bulk push event](img/bulk_push_event_v12_4.png)
 
diff --git a/doc/user/asciidoc.md b/doc/user/asciidoc.md
index 07593c98da9..6d6460ca50f 100644
--- a/doc/user/asciidoc.md
+++ b/doc/user/asciidoc.md
@@ -30,7 +30,7 @@ Line comments, which are lines that start with `//`, are skipped:
 
 A blank line separates paragraphs.
 
-A paragraph with the `[%hardbreaks]` option will preserve line breaks:
+A paragraph with the `[%hardbreaks]` option preserves line breaks:
 
 ```plaintext
 [%hardbreaks]
@@ -381,7 +381,7 @@ Supported formats (named colors are not supported):
 - RGB: `` `RGB[A](R, G, B[, A])` ``
 - HSL: `` `HSL[A](H, S, L[, A])` ``
 
-Color written inside backticks will be followed by a color "chip":
+Color written inside backticks is followed by a color "chip":
 
 ```plaintext
 - `#F00`
@@ -399,7 +399,7 @@ Color written inside backticks will be followed by a color "chip":
 
 To activate equation and formula support,
 set the `stem` attribute in the document's header to `latexmath`.
-Equations and formulas will be rendered using [KaTeX](https://katex.org/):
+Equations and formulas are rendered using [KaTeX](https://katex.org/):
 
 ```plaintext
 :stem: latexmath
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index 6a5816d1275..f048440e383 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -153,7 +153,7 @@ npm config set '//gitlab.example.com/api/v4/packages/npm/:_authToken' "<your_tok
 - `<your_token>` is your personal access token or deploy token.
 - Replace `gitlab.example.com` with your domain name.
 
-You should now be able to publish and install npm packages in your project.
+You should now be able to install npm packages in your project.
 
 If you encounter an error with [Yarn](https://classic.yarnpkg.com/en/), view
 [troubleshooting steps](#troubleshooting).
diff --git a/doc/user/packages/pypi_repository/index.md b/doc/user/packages/pypi_repository/index.md
index 6b6690f1b38..a6cc5cf1f07 100644
--- a/doc/user/packages/pypi_repository/index.md
+++ b/doc/user/packages/pypi_repository/index.md
@@ -174,11 +174,10 @@ index-servers =
 
 [gitlab]
 repository = https://gitlab.example.com/api/v4/projects/<project_id>/packages/pypi
-username = __token__
-password = <your personal access token>
+username = <your_personal_access_token_name>
+password = <your_personal_access_token>
 ```
 
-- `username` must be `__token__` exactly.
 - Your project ID is on your project's home page.
 
 ### Authenticate with a deploy token
@@ -317,10 +316,11 @@ more than once, a `404 Bad Request` error occurs.
 To install the latest version of a package, use the following command:
 
 ```shell
-pip install --index-url https://__token__:<personal_access_token>@gitlab.example.com/api/v4/projects/<project_id>/packages/pypi/simple --no-deps <package_name>
+pip install --index-url https://<personal_access_token_name>:<personal_access_token>@gitlab.example.com/api/v4/projects/<project_id>/packages/pypi/simple --no-deps <package_name>
 ```
 
 - `<package_name>` is the package name.
+- `<personal_access_token_name>` is a personal access token name with the `read_api` scope.
 - `<personal_access_token>` is a personal access token with the `read_api` scope.
 - `<project_id>` is the project ID.
 
@@ -334,13 +334,13 @@ If you were following the guide and want to install the
 `MyPyPiPackage` package, you can run:
 
 ```shell
-pip install mypypipackage --no-deps --index-url https://__token__:<personal_access_token>@gitlab.example.com/api/v4/projects/<your_project_id>/packages/pypi/simple
+pip install mypypipackage --no-deps --index-url https://<personal_access_token_name>:<personal_access_token>@gitlab.example.com/api/v4/projects/<your_project_id>/packages/pypi/simple
 ```
 
 This message indicates that the package was installed successfully:
 
 ```plaintext
-Looking in indexes: https://__token__:****@gitlab.example.com/api/v4/projects/<your_project_id>/packages/pypi/simple
+Looking in indexes: https://<personal_access_token_name>:****@gitlab.example.com/api/v4/projects/<your_project_id>/packages/pypi/simple
 Collecting mypypipackage
   Downloading https://gitlab.example.com/api/v4/projects/<your_project_id>/packages/pypi/files/d53334205552a355fee8ca35a164512ef7334f33d309e60240d57073ee4386e6/mypypipackage-0.0.1-py3-none-any.whl (1.6 kB)
 Installing collected packages: mypypipackage
diff --git a/doc/user/project/badges.md b/doc/user/project/badges.md
index 7e6bba30001..783232ca7f9 100644
--- a/doc/user/project/badges.md
+++ b/doc/user/project/badges.md
@@ -19,7 +19,7 @@ project maintainers.
 
 ## Project badges
 
-Badges can be added to a project by Maintainers or Owners, and will then be visible on the project's overview page.
+Badges can be added to a project by Maintainers or Owners, and are visible on the project's overview page.
 If you find that you have to add the same badges to several projects, you may want to add them at the [group level](#group-badges).
 
 To add a new badge to a project:
@@ -52,7 +52,7 @@ To add this badge to a project:
 
 ## Group badges
 
-Badges can be added to a group and will then be visible on every project's
+Badges can be added to a group and are visible on every project's
 overview page that's under that group. In this case, they cannot be edited or
 deleted on the project level. If you need to have individual badges for each
 project, consider adding them on the [project level](#project-badges) or use
@@ -75,7 +75,7 @@ Badges directly associated with a project can be configured on the
 ## Placeholders
 
 The URL a badge points to, as well as the image URL, can contain placeholders
-which will be evaluated when displaying the badge. The following placeholders
+which are evaluated when displaying the badge. The following placeholders
 are available:
 
 - `%{project_path}`: Path of a project including the parent groups
diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md
index 59e915dd9e6..c557c7718c9 100644
--- a/doc/user/project/push_options.md
+++ b/doc/user/project/push_options.md
@@ -66,7 +66,7 @@ time as pushing changes:
 | `merge_request.remove_source_branch`         | Set the merge request to remove the source branch when it's merged.                                             | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64320)          |
 | `merge_request.title="<title>"`              | Set the title of the merge request. Ex: `git push -o merge_request.title="The title I want"`.                   | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64320)          |
 | `merge_request.description="<description>"`  | Set the description of the merge request. Ex: `git push -o merge_request.description="The description I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64320)          |
-| `merge_request.label="<label>"`              | Add labels to the merge request. If the label does not exist, it will be created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31831) |
+| `merge_request.label="<label>"`              | Add labels to the merge request. If the label does not exist, it is created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31831) |
 | `merge_request.unlabel="<label>"`            | Remove labels from the merge request. For example, for two labels: `git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31831) |
 
 If you use a push option that requires text with spaces in it, you need to enclose it
@@ -108,7 +108,7 @@ option](#push-options-for-merge-requests):
 git config --global alias.mwps "push -o merge_request.create -o merge_request.target=master -o merge_request.merge_when_pipeline_succeeds"
 ```
 
-Then to quickly push a local branch that will target master and merge when the
+Then to quickly push a local branch that targets the default branch and merges when the
 pipeline succeeds:
 
 ```shell
diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md
index 4d0cf28593d..eaabcb52d57 100644
--- a/doc/user/project/repository/branches/index.md
+++ b/doc/user/project/repository/branches/index.md
@@ -64,7 +64,7 @@ against accidental deletion and forced pushes.
 
 By default, when you create a new project in GitLab, the initial branch is called `master`.
 For self-managed instances, a GitLab administrator can customize the initial branch name to something
-else. This way, every new project created from then on will start from the custom branch name rather than `master`. To do so:
+else. This way, every new project created from then on starts from the custom branch name rather than `master`. To do so:
 
 1. Go to the **Admin Area > Settings > Repository** and expand **Default initial
    branch name**.
@@ -108,7 +108,7 @@ To compare branches in a repository:
 ![Delete merged branches](img/delete_merged_branches.png)
 
 This feature allows merged branches to be deleted in bulk. Only branches that
-have been merged and [are not protected](../../protected_branches.md) will be deleted as part of
+have been merged and [are not protected](../../protected_branches.md) are deleted as part of
 this operation.
 
 It's particularly useful to clean up old branches that were not deleted
@@ -127,8 +127,8 @@ This feature allows you to search and select branches quickly. Search results ap
 
 Sometimes when you have hundreds of branches you may want a more flexible matching pattern. In such cases you can use the following:
 
-- `^feature` will only match branch names that begin with 'feature'.
-- `feature$` will only match branch names that end with 'feature'.
+- `^feature` matches only branch names that begin with 'feature'.
+- `feature$` matches only branch names that end with 'feature'.
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index 1a5e169ec6b..c8922890deb 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -31,25 +31,25 @@ Forking a project is, in most cases, a two-step process.
 
    ![Choose namespace](img/forking_workflow_choose_namespace_v13_2.png)
 
-The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
+The fork is created. The permissions you have in the namespace are your permissions in the fork.
 
 WARNING:
-When a public project with the repository feature set to "Members
-only" is forked, the repository will be public in the fork. The owner
-of the fork will need to manually change the visibility. This is being
+When a public project with the repository feature set to **Members Only**
+is forked, the repository is public in the fork. The owner
+of the fork must manually change the visibility. This is being
 fixed in [#36662](https://gitlab.com/gitlab-org/gitlab/-/issues/36662).
 
 ## Repository mirroring
 
 You can use [repository mirroring](repository_mirroring.md) to keep your fork synced with the original repository. You can also use `git remote add upstream` to achieve the same result.
 
-The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
+The main difference is that with repository mirroring, your remote fork is automatically kept up-to-date.
 
-Without mirroring, to work locally you'll have to use `git pull` to update your local repository
+Without mirroring, to work locally you must use `git pull` to update your local repository
 with the upstream project, then push the changes back to your fork to update it.
 
 WARNING:
-With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommended.
+With mirroring, before approving a merge request, you are asked to sync. Because of this, automating it is recommended.
 
 Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).
 
@@ -60,7 +60,7 @@ When you are ready to send your code back to the upstream project,
 choose your forked project's branch. For **Target branch**, choose the original project's branch.
 
 NOTE:
-When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch will default to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
+When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch defaults to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
 
 ![Selecting branches](img/forking_workflow_branch_select.png)
 
diff --git a/doc/user/project/repository/git_blame.md b/doc/user/project/repository/git_blame.md
index 81995291911..0f49932d0c6 100644
--- a/doc/user/project/repository/git_blame.md
+++ b/doc/user/project/repository/git_blame.md
@@ -18,13 +18,12 @@ You can find the **Blame** button with each file in a project.
 
 ![File blame button](img/file_blame_button_v12_6.png "Blame button")
 
-When you select the **Blame** button, you'll see a screen with the
-noted information:
+When you select the **Blame** button, this information is shown:
 
 ![Git blame output](img/file_blame_output_v12_6.png "Blame button output")
 
-If you hover over a commit in the UI, you'll see a precise date and time
-for that commit.
+If you hover over a commit in the UI, the commit's precise date and time
+are shown.
 
 ## Blame previous commit
 
@@ -45,7 +44,7 @@ about a `README.md` file in the local directory, run the following command:
 git blame README.md
 ```
 
-You'll see output similar to the following, which includes the commit time
+The output looks similar to the following, which includes the commit time
 in UTC format:
 
 ```shell
diff --git a/doc/user/project/repository/git_history.md b/doc/user/project/repository/git_history.md
index 2e27cab4177..1b30a0b0f5f 100644
--- a/doc/user/project/repository/git_history.md
+++ b/doc/user/project/repository/git_history.md
@@ -17,13 +17,12 @@ You can find the **History** button with each file in a project.
 
 ![File history button](img/file_history_button_v12_6.png "History button")
 
-When you select the **History** button, you'll see a screen with the
-noted information:
+When you select the **History** button, this information displays:
 
 ![Git log output](img/file_history_output_v12_6.png "History button output")
 
-If you hover over a commit in the UI, you'll see a precise date and time
-that commit was last modified.
+If you hover over a commit in the UI, the precise date and time of the commit modification
+are shown.
 
 ## Associated `git` command
 
@@ -36,7 +35,7 @@ following command:
 git log README.md
 ```
 
-You'll see output similar to the following, which includes the commit
+Git displays output similar to the following, which includes the commit
 time in UTC format:
 
 ```shell
diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md
index 1a46c140507..bf877bfee68 100644
--- a/doc/user/project/repository/gpg_signed_commits/index.md
+++ b/doc/user/project/repository/gpg_signed_commits/index.md
@@ -40,7 +40,7 @@ For a commit to be verified by GitLab:
 
 ## Generating a GPG key
 
-If you don't already have a GPG key, the following steps will help you get
+If you don't already have a GPG key, the following steps can help you get
 started:
 
 1. [Install GPG](https://www.gnupg.org/download/index.html) for your operating system.
@@ -225,8 +225,8 @@ git config --global commit.gpgsign true
 ## Verifying commits
 
 1. Within a project or [merge request](../../merge_requests/index.md), navigate to
-   the **Commits** tab. Signed commits will show a badge containing either
-   "Verified" or "Unverified", depending on the verification status of the GPG
+   the **Commits** tab. Signed commits show a badge containing either
+   **Verified** or **Unverified**, depending on the verification status of the GPG
    signature.
 
    ![Signed and unsigned commits](img/project_signed_and_unsigned_commits.png)
@@ -240,8 +240,8 @@ git config --global commit.gpgsign true
 ## Revoking a GPG key
 
 Revoking a key **unverifies** already signed commits. Commits that were
-verified by using this key will change to an unverified state. Future commits
-will also stay unverified once you revoke this key. This action should be used
+verified by using this key changes to an unverified state. Future commits
+stay unverified after you revoke this key. This action should be used
 in case your key has been compromised.
 
 To revoke a GPG key:
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index d330e4d2d94..4dfc922fbad 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -19,8 +19,8 @@ To create a new repository, all you need to do is
 
 Once you create a new project, you can add new files via UI
 (read the section below) or via command line.
-To add files from the command line, follow the instructions that will
-be presented on the screen when you create a new project, or read
+To add files from the command line, follow the instructions
+presented on the screen when you create a new project, or read
 through them in the [command line basics](../../../gitlab-basics/start-using-git.md)
 documentation.
 
@@ -31,8 +31,7 @@ that you [connect with GitLab via SSH](../../../ssh/README.md).
 ## Files
 
 Use a repository to store your files in GitLab. In [GitLab 12.10 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/33806),
-you'll see on the repository's file tree an icon next to the filename
-according to its extension:
+an icon identifying the extension is shown next to the filename:
 
 ![Repository file icons](img/file_ext_icons_repo_v12_10.png)
 
@@ -76,7 +75,7 @@ markup languages](https://en.wikipedia.org/wiki/Lightweight_markup_language))
 that you can use for the content of your files in a repository. They are mostly
 used for documentation purposes.
 
-Just pick the right extension for your files and GitLab will render them
+Just pick the right extension for your files and GitLab renders them
 according to the markup language.
 
 | Markup language | Extensions |
@@ -93,7 +92,7 @@ according to the markup language.
 
 ### Repository README and index files
 
-When a `README` or `index` file is present in a repository, its contents will be
+When a `README` or `index` file is present in a repository, its contents are
 automatically pre-rendered by GitLab without opening it.
 
 They can either be plain text or have an extension of a
@@ -101,12 +100,12 @@ They can either be plain text or have an extension of a
 
 Some things to note about precedence:
 
-1. When both a `README` and an `index` file are present, the `README` will always
-   take precedence.
+1. When both a `README` and an `index` file are present, the `README` always
+   takes precedence.
 1. When more than one file is present with different extensions, they are
-   ordered alphabetically, with the exception of a file without an extension
-   which will always be last in precedence. For example, `README.adoc` will take
-   precedence over `README.md`, and `README.rst` will take precedence over
+   ordered alphabetically, with the exception of a file without an extension,
+   which is always last in precedence. For example, `README.adoc` takes
+   precedence over `README.md`, and `README.rst` takes precedence over
    `README`.
 
 ### Jupyter Notebook files
@@ -159,18 +158,18 @@ Via command line, you can commit multiple times before pushing.
 - **Commit message:**
   A commit message is important to identity what is being changed and,
   more importantly, why. In GitLab, you can add keywords to the commit
-  message that will perform one of the actions below:
+  message that performs one of the actions below:
   - **Trigger a GitLab CI/CD pipeline:**
   If you have your project configured with [GitLab CI/CD](../../../ci/README.md),
-  you will trigger a pipeline per push, not per commit.
+  you trigger a pipeline per push, not per commit.
   - **Skip pipelines:**
-  You can add to you commit message the keyword
-  [`[ci skip]`](../../../ci/yaml/README.md#skip-pipeline)
-  and GitLab CI/CD will skip that pipeline.
+  You can add to your commit message the keyword
+  [`[ci skip]`](../../../ci/yaml/README.md#skip-pipeline),
+  and GitLab CI/CD skips that pipeline.
   - **Cross-link issues and merge requests:**
   [Cross-linking](../issues/crosslinking_issues.md#from-commit-messages)
   is great to keep track of what's is somehow related in your workflow.
-  If you mention an issue or a merge request in a commit message, they will be shown
+  If you mention an issue or a merge request in a commit message, they are shown
   on their respective thread.
 - **Cherry-pick a commit:**
   In GitLab, you can
@@ -211,9 +210,9 @@ Find it under your project's **Repository > Graph**.
 
 ## Repository Languages
 
-For the default branch of each repository, GitLab will determine what programming languages
-were used and display this on the projects pages. If this information is missing, it will
-be added after updating the default branch on the project. This process can take up to 5
+For the default branch of each repository, GitLab determines what programming languages
+were used and displays this on the project's pages. If this information is missing, it's
+added after updating the default branch for the project. This process can take up to five
 minutes.
 
 ![Repository Languages bar](img/repository_languages_v12_2.gif)
@@ -253,8 +252,8 @@ into Xcode on macOS. To do that:
 1. Click **Clone**.
 1. Select **Xcode**.
 
-The project will be cloned onto your computer in a folder of your choice and you'll
-be prompted to open in XCode.
+The project is cloned onto your computer in a folder of your choice and you are
+prompted to open XCode.
 
 ### Clone and open in Visual Studio Code
 
@@ -264,10 +263,10 @@ All projects can be cloned into Visual Studio Code. To do that:
 
 1. From the GitLab UI, go to the project's overview page.
 1. Click **Clone**.
-1. Select **VS Code**
+1. Select **VS Code**.
+1. Select a folder to clone the project into.
 
-You'll be prompted to select a folder to clone the project into. When VS Code has
-successfully cloned your project, it will open the folder.
+When VS Code has successfully cloned your project, it opens the folder.
 
 ## Download Source Code
 
@@ -275,7 +274,7 @@ successfully cloned your project, it will open the folder.
 > - Support for [including Git LFS blobs](../../../topics/git/lfs#lfs-objects-in-project-archives) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15079) in GitLab 13.5.
 
 The source code stored in a repository can be downloaded from the UI.
-By clicking the download icon, a dropdown will open with links to download the following:
+By clicking the download icon, a dropdown opens with links to download the following:
 
 ![Download source code](img/download_source_code.png)
 
diff --git a/doc/user/project/repository/jupyter_notebooks/index.md b/doc/user/project/repository/jupyter_notebooks/index.md
index 123df9097f9..e4a3e6d6ef1 100644
--- a/doc/user/project/repository/jupyter_notebooks/index.md
+++ b/doc/user/project/repository/jupyter_notebooks/index.md
@@ -12,12 +12,12 @@ type: reference
 interactive computing in many fields and contain a complete record of the
 user's sessions and include code, narrative text, equations, and rich output.
 
-When added to a repository, Jupyter Notebooks with a `.ipynb` extension will be
+When added to a repository, Jupyter Notebooks with a `.ipynb` extension are
 rendered to HTML when viewed.
 
 ![Jupyter Notebook Rich Output](img/jupyter_notebook.png)
 
-Interactive features, including JavaScript plots, will not work when viewed in
+Interactive features, including JavaScript plots, don't work when viewed in
 GitLab.
 
 ## Jupyter Hub as a GitLab Managed App
diff --git a/doc/user/project/repository/repository_mirroring.md b/doc/user/project/repository/repository_mirroring.md
index 98d33b7461e..980c5417da6 100644
--- a/doc/user/project/repository/repository_mirroring.md
+++ b/doc/user/project/repository/repository_mirroring.md
@@ -7,19 +7,19 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/repository_mirroring.htm
 
 # Repository mirroring **(FREE)**
 
-Repository mirroring allows for mirroring of repositories to and from external sources. It can be
-used to mirror branches, tags, and commits between repositories. It is useful when you want to use
+Repository mirroring allows for the mirroring of repositories to and from external sources. You
+can use it to mirror branches, tags, and commits between repositories. It's useful when you want to use
 a repository outside of GitLab.
 
-A repository mirror at GitLab will be updated automatically. You can also manually trigger an update
-at most once every 5 minutes on GitLab.com with [the limit set by the administrator on self-managed instances](../../../administration/instance_limits.md#pull-mirroring-interval).
+A repository mirror at GitLab updates automatically. You can also manually trigger an update
+at most once every five minutes on GitLab.com with [the limit set by the administrator on self-managed instances](../../../administration/instance_limits.md#pull-mirroring-interval).
 
 There are two kinds of repository mirroring supported by GitLab:
 
 - [Push](#pushing-to-a-remote-repository): for mirroring a GitLab repository to another location. **(FREE)**
 - [Pull](#pulling-from-a-remote-repository): for mirroring a repository from another location to GitLab. **(PREMIUM)**
 
-When the mirror repository is updated, all new branches, tags, and commits will be visible in the
+When the mirror repository is updated, all new branches, tags, and commits are visible in the
 project's activity feed.
 
 Users with at least [Developer access](../../permissions.md) to the project can also force an
@@ -37,7 +37,7 @@ The following are some possible use cases for repository mirroring:
 
 - You migrated to GitLab but still need to keep your project in another source. In that case, you
   can simply set it up to mirror to GitLab (pull) and all the essential history of commits, tags,
-  and branches will be available in your GitLab instance. **(PREMIUM)**
+  and branches are available in your GitLab instance. **(PREMIUM)**
 - You have old projects in another source that you don't use actively anymore, but don't want to
   remove for archiving purposes. In that case, you can create a push mirror so that your active
   GitLab repository can push its changes to the old location.
@@ -49,25 +49,23 @@ The following are some possible use cases for repository mirroring:
 
 ## Pushing to a remote repository **(FREE)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249) in GitLab Enterprise Edition 8.7.
-> - [Moved to GitLab Free](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18715) in 10.8.
-> - [LFS support over HTTPS added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40137) in 13.5
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40137) in GitLab 13.5: LFS support over HTTPS.
 
 For an existing project, you can set up push mirroring as follows:
 
-1. Navigate to your project's **Settings > Repository** and expand the **Mirroring repositories** section.
+1. In your project, go to **Settings > Repository**, and then expand the **Mirroring repositories** section.
 1. Enter a repository URL.
-1. Select **Push** from the **Mirror direction** dropdown.
+1. In the **Mirror direction** dropdown, select **Push**.
 1. Select an authentication method from the **Authentication method** dropdown.
    You can authenticate with either a password or an [SSH key](#ssh-authentication).
-1. Check the **Only mirror protected branches** box, if necessary.
-1. Check the **Keep divergent refs** box, if desired.
-1. Click the **Mirror repository** button to save the configuration.
+1. Select the **Only mirror protected branches** check box, if necessary.
+1. Select the **Keep divergent refs** check box, if desired.
+1. Select **Mirror repository** to save the configuration.
 
 ![Repository mirroring push settings screen](img/repository_mirroring_push_settings.png)
 
 When push mirroring is enabled, only push commits directly to the mirrored repository to prevent the
-mirror diverging. All changes will end up in the mirrored repository whenever:
+mirror diverging. The mirrored repository receives all changes when:
 
 - Commits are pushed to GitLab.
 - A [forced update](#forcing-an-update) is initiated.
@@ -77,7 +75,7 @@ Changes pushed to files in the repository are automatically pushed to the remote
 - Within five minutes of being received.
 - Within one minute if **Only mirror protected branches** is enabled.
 
-In the case of a diverged branch, you will see an error indicated at the **Mirroring repositories**
+In the case of a diverged branch, an error displays in the **Mirroring repositories**
 section.
 
 ### Configuring push mirrors through the API
@@ -87,20 +85,20 @@ You can also create and modify project push mirrors through the
 
 ### Keep divergent refs
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208828) in GitLab 13.0.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/208828) in GitLab 13.0.
 
 By default, if any ref on the remote mirror has diverged from the local
-repository, the *entire push* will fail, and nothing will be updated.
+repository, the *entire push* fails, and no updates occur.
 
 For example, if a repository has `master`, `develop`, and `stable` branches that
 have been mirrored to a remote, and then a new commit is added to `develop` on
-the mirror, the next push attempt will fail, leaving `master` and `stable`
+the mirror, the next push attempt fails, leaving `master` and `stable`
 out-of-date despite not having diverged. No change on any branch can be mirrored
 until the divergence is resolved.
 
 With the **Keep divergent refs** option enabled, the `develop` branch is
-skipped, allowing `master` and `stable` to be updated. The mirror status will
-reflect that `develop` has diverged and was skipped, and be marked as a failed
+skipped, allowing `master` and `stable` to be updated. The mirror status
+reflects that `develop` has diverged and was skipped, and be marked as a failed
 update.
 
 NOTE:
@@ -113,15 +111,15 @@ To set up a mirror from GitLab to GitHub, you need to follow these steps:
 1. Create a [GitHub personal access token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) with the `public_repo` box checked.
 1. Fill in the **Git repository URL** field using this format: `https://<your_github_username>@github.com/<your_github_group>/<your_github_project>.git`.
 1. Fill in **Password** field with your GitHub personal access token.
-1. Click the **Mirror repository** button.
+1. Select **Mirror repository**.
 
-The mirrored repository will be listed. For example, `https://*****:*****@github.com/<your_github_group>/<your_github_project>.git`.
+The mirrored repository is listed. For example, `https://*****:*****@github.com/<your_github_group>/<your_github_project>.git`.
 
-The repository will push soon. To force a push, click the **Update now** (**{retry}**) button.
+The repository pushes shortly thereafter. To force a push, select the **Update now** (**{retry}**) button.
 
 ### Setting up a push mirror from GitLab to AWS CodeCommit
 
-AWS CodeCommit push mirroring is currently the best way to connect GitLab repositories to AWS CodePipeline, as GitLab is not yet supported as one of their Source Code Management (SCM) providers.
+AWS CodeCommit push mirroring is currently the best way to connect GitLab repositories to AWS CodePipeline, as GitLab isn't yet supported as one of their Source Code Management (SCM) providers.
 
 Each new AWS CodePipeline needs significant AWS infrastructure setup. It also requires an individual pipeline per branch.
 
@@ -159,9 +157,9 @@ To set up a mirror from GitLab to AWS CodeCommit:
    }
    ```
 
-1. After the user was created, click the AWS IAM user name.
-1. Click the **Security credentials** tab.
-1. Under **HTTPS Git credentials for AWS CodeCommit** click **Generate credentials**.
+1. After the user was created, select the AWS IAM user name.
+1. Select the **Security credentials** tab.
+1. Under **HTTPS Git credentials for AWS CodeCommit** select **Generate credentials**.
 
    NOTE:
    This Git user ID and password is specific to communicating with CodeCommit. Do
@@ -169,9 +167,9 @@ To set up a mirror from GitLab to AWS CodeCommit:
 
 1. Copy or download special Git HTTPS user ID and password.
 1. In the AWS CodeCommit console, create a new repository to mirror from your GitLab repository.
-1. Open your new repository and click **Clone URL > Clone HTTPS** (not **Clone HTTPS (GRC)**).
+1. Open your new repository, and then select **Clone URL > Clone HTTPS** (not **Clone HTTPS (GRC)**).
 1. In GitLab, open the repository to be push-mirrored.
-1. Click **Settings > Repository** and expand **Mirroring repositories**.
+1. Go to **Settings > Repository**, and then expand **Mirroring repositories**.
 1. Fill in the **Git repository URL** field using this format:
 
    ```plaintext
@@ -185,17 +183,17 @@ To set up a mirror from GitLab to AWS CodeCommit:
 1. For **Authentication method**, select **Password** and fill in the **Password** field with the special IAM Git clone user ID **password** created earlier in AWS.
 1. The option **Only mirror protected branches** should be good for CodeCommit as it pushes more
    frequently (from every five minutes to every minute).
-   CodePipeline requires individual pipeline setups for named branches you wish to have a AWS CI setup for. Since feature branches that have dynamic names will not be supported anyway, configuring **Only mirror protected branches** does not cause flexibility problems with CodePipeline integration as long as you are also willing to protect all the named branches you want to build CodePipelines for.
+   CodePipeline requires individual pipeline setups for named branches you wish to have a AWS CI setup for. Because feature branches that have dynamic names are unsupported, configuring **Only mirror protected branches** doesn't cause flexibility problems with CodePipeline integration as long as you are also willing to protect all the named branches you want to build CodePipelines for.
 
-1. Click **Mirror repository**. You should see the mirrored repository appear:
+1. Select **Mirror repository**. You should see the mirrored repository appear:
 
    ```plaintext
    https://*****:*****@git-codecommit.<aws-region>.amazonaws.com/v1/repos/<your_codecommit_repo>
    ```
 
-To test mirroring by forcing a push, click the half-circle arrows button (hover text is **Update now**).
+To test mirroring by forcing a push, select the half-circle arrows button (hover text is **Update now**).
 If **Last successful update** shows a date, you have configured mirroring correctly.
-If it is not working correctly a red `error` tag appears and shows the error message as hover text.
+If it isn't working correctly, a red `error` tag appears and shows the error message as hover text.
 
 ### Setting up a push mirror to another GitLab instance with 2FA activated
 
@@ -203,11 +201,10 @@ If it is not working correctly a red `error` tag appears and shows the error mes
 1. On the source GitLab instance:
    1. Fill in the **Git repository URL** field using this format: `https://oauth2@<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`.
    1. Fill in the **Password** field with the GitLab personal access token created on the destination GitLab instance.
-   1. Click the **Mirror repository** button.
+   1. Select **Mirror repository**.
 
 ## Pulling from a remote repository **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51) in GitLab Enterprise Edition 8.2.
 > - [Added Git LFS support](https://gitlab.com/gitlab-org/gitlab/-/issues/10871) in GitLab 11.11.
 > - Moved to GitLab Premium in 13.9.
 
@@ -242,15 +239,15 @@ To configure mirror pulling for an existing project:
 
 Because GitLab is now set to pull changes from the upstream repository, you should not push commits
 directly to the repository on GitLab. Instead, any commits should be pushed to the remote repository.
-Changes pushed to the remote repository will be pulled into the GitLab repository, either:
+Changes pushed to the remote repository are pulled into the GitLab repository, either:
 
 - Automatically within a certain period of time.
 - When a [forced update](#forcing-an-update) is initiated.
 
 WARNING:
-If you do manually update a branch in the GitLab repository, the branch will become diverged from
-upstream and GitLab will no longer automatically update this branch to prevent any changes from being lost.
-Also note that deleted branches and tags in the upstream repository will not be reflected in the GitLab repository.
+If you do manually update a branch in the GitLab repository, the branch becomes diverged from
+upstream, and GitLab no longer automatically updates this branch to prevent any changes from being lost.
+Deleted branches and tags in the upstream repository are not reflected in the GitLab repository.
 
 ### How it works
 
@@ -263,13 +260,12 @@ Once per minute, a Sidekiq cron job schedules repository mirrors to update, base
 
 Repository mirrors are updated as Sidekiq becomes available to process them. If the process of updating the repository mirror:
 
-- Succeeds, an update will be enqueued again with at least a 30 minute wait.
-- Fails (for example, a branch diverged from upstream), it will be attempted again later. Mirrors can fail
-  up to 14 times before they will not be enqueued for update again.
+- **Succeeds**: An update is enqueued again with at least a 30 minute wait.
+- **Fails**: (For example, a branch diverged from upstream.), The update attempted again later. Mirrors can fail
+  up to 14 times before they are no longer enqueued for updates.
 
 ### Overwrite diverged branches **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4559) in GitLab 10.6.
 > - Moved to GitLab Premium in 13.9.
 
 You can choose to always update your local branches with remote versions, even if they have
@@ -282,42 +278,39 @@ To use this option, check the **Overwrite diverged branches** box when creating
 
 ### Trigger pipelines for mirror updates **(PREMIUM)**
 
-> Moved to GitLab Premium in 13.9.
+> - Moved to GitLab Premium in 13.9.
 
-If this option is enabled, pipelines will be triggered when branches or tags are
+If this option is enabled, pipelines trigger when branches or tags are
 updated from the remote repository. Depending on the activity of the remote
 repository, this may greatly increase the load on your CI runners. Only enable
-this if you know they can handle the load. CI will run using the credentials
+this if you know they can handle the load. CI uses the credentials
 assigned when you set up pull mirroring.
 
 ### Hard failure **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3117) in GitLab 10.2.
 > - Moved to GitLab Premium in 13.9.
 
-Once the mirroring process is unsuccessfully retried 14 times in a row, it will get marked as hard
-failed. This will become visible in either the:
+After 14 consecutive unsuccessful retries, the mirroring process is marked as a hard failure
+and mirroring attempts stop. This failure is visible in either the:
 
 - Project's main dashboard.
 - Pull mirror settings page.
 
-When a project is hard failed, it will no longer get picked up for mirroring.
 You can resume the project mirroring again by [forcing an update](#forcing-an-update).
 
 ### Trigger an update using the API **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3453) in GitLab 10.3.
 > - Moved to GitLab Premium in 13.9.
 
 Pull mirroring uses polling to detect new branches and commits added upstream, often minutes
 afterwards. If you notify GitLab by [API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project),
-updates will be pulled immediately.
+updates are pulled immediately.
 
 For more information, see [Start the pull mirroring process for a Project](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project).
 
 ## Mirror only protected branches **(PREMIUM)**
 
-> Moved to GitLab Premium in 13.9.
+> - Moved to GitLab Premium in 13.9.
 
 Based on the mirror direction that you choose, you can opt to mirror only the
 [protected branches](../protected_branches.md) from/to your remote repository.
@@ -328,7 +321,6 @@ creating a repository mirror. **(PREMIUM)**
 
 ## SSH authentication
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2551) in GitLab 9.5 for Pull mirroring.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22982) in GitLab 11.6 for Push mirroring.
 
 SSH authentication is mutual:
@@ -340,7 +332,7 @@ You provide your credentials as a password or public key. The server that the
 other repository resides on provides its credentials as a "host key", the
 fingerprint of which needs to be verified manually.
 
-If you're mirroring over SSH (that is, using an `ssh://` URL), you can authenticate using:
+If you're mirroring over SSH (using an `ssh://` URL), you can authenticate using:
 
 - Password-based authentication, just as over HTTPS.
 - Public key authentication. This is often more secure than password authentication,
@@ -348,7 +340,7 @@ If you're mirroring over SSH (that is, using an `ssh://` URL), you can authentic
 
 To get started:
 
-1. Navigate to your project's **Settings > Repository** and expand the **Mirroring repositories** section.
+1. In your project, go to **Settings > Repository**, and then expand the **Mirroring repositories** section.
 1. Enter an `ssh://` URL for mirroring.
 
 NOTE:
@@ -359,9 +351,9 @@ Entering the URL adds two buttons to the page:
 - **Detect host keys**.
 - **Input host keys manually**.
 
-If you click the:
+If you select the:
 
-- **Detect host keys** button, GitLab will fetch the host keys from the server and display the fingerprints.
+- **Detect host keys** button, GitLab fetches the host keys from the server and display the fingerprints.
 - **Input host keys manually** button, a field is displayed where you can paste in host keys.
 
 Assuming you used the former, you now need to verify that the fingerprints are
@@ -376,7 +368,7 @@ fingerprints in the open for you to check:
 - [Savannah](http://savannah.gnu.org/maintenance/SshAccess/)
 - [SourceForge](https://sourceforge.net/p/forge/documentation/SSH%20Key%20Fingerprints/)
 
-Other providers will vary. If you're running self-managed GitLab, or otherwise
+Other providers vary. If you're running self-managed GitLab, or otherwise
 have access to the server for the other repository, you can securely gather the
 key fingerprints:
 
@@ -390,15 +382,15 @@ $ cat /etc/ssh/ssh_host*pub | ssh-keygen -E md5 -l -f -
 NOTE:
 You may need to exclude `-E md5` for some older versions of SSH.
 
-When mirroring the repository, GitLab will now check that at least one of the
+When mirroring the repository, GitLab checks that at least one of the
 stored host keys matches before connecting. This can prevent malicious code from
 being injected into your mirror, or your password being stolen.
 
 ### SSH public key authentication
 
-To use SSH public key authentication, you'll also need to choose that option
+To use SSH public key authentication, you must also choose that option
 from the **Authentication method** dropdown. When the mirror is created,
-GitLab generates a 4096-bit RSA key that can be copied by clicking the **Copy SSH public key** button.
+GitLab generates a 4096-bit RSA key that can be copied by selecting the **Copy SSH public key** button.
 
 ![Repository mirroring copy SSH public key to clipboard button](img/repository_mirroring_copy_ssh_public_key_button.png)
 
@@ -411,7 +403,7 @@ You then need to add the public SSH key to the other repository's configuration:
   file on its own line and save it.
 
 If you need to change the key at any time, you can remove and re-add the mirror
-to generate a new key. You'll have to update the other repository with the new
+to generate a new key. Update the other repository with the new
 key to keep the mirror running.
 
 NOTE:
@@ -427,17 +419,17 @@ update button which is available on the **Mirroring repositories** section of th
 
 ## Bidirectional mirroring **(PREMIUM)**
 
-> Moved to GitLab Premium in 13.9.
+> - Moved to GitLab Premium in 13.9.
 
 WARNING:
 Bidirectional mirroring may cause conflicts.
 
 If you configure a GitLab repository to both pull from, and push to, the same remote source, there
-is no guarantee that either repository will update correctly. If you set up a repository for
-bidirectional mirroring, you should prepare for the likely conflicts by deciding who will resolve
-them and how they will be resolved.
+is no guarantee that either repository updates correctly. If you set up a repository for
+bidirectional mirroring, you should prepare for the likely conflicts by deciding who resolves
+them and how.
 
-Rewriting any mirrored commit on either remote will cause conflicts and mirroring to fail. This can
+Rewriting any mirrored commit on either remote causes conflicts and mirroring to fail. This can
 be prevented by [mirroring only protected branches](#mirror-only-protected-branches).
 
 You should [protect the branches](../protected_branches.md) you wish to mirror on both
@@ -451,34 +443,35 @@ protected branches.
 
 ### Configure a webhook to trigger an immediate pull to GitLab
 
-Assuming you have already configured the [push](#setting-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated) and [pull](#pulling-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an immediate pull as suggested above, you will need to configure a [Push Event Web Hook](../integrations/webhooks.md#push-events) in the downstream instance.
+Assuming you have already configured the [push](#setting-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated) and [pull](#pulling-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an immediate pull as suggested above, you must configure a [Push Event Web Hook](../integrations/webhooks.md#push-events) in the downstream instance.
 
 To do this:
 
-- Create a [personal access token](../../profile/personal_access_tokens.md) with `API` scope.
-- Navigate to **Settings > Webhooks**
-- Add the webhook URL which in this case will use the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project) request to trigger an immediate pull after updates to the repository.
+1. Create a [personal access token](../../profile/personal_access_tokens.md) with `API` scope.
+1. In your project, go to **Settings > Webhooks**.
+1. Add the webhook URL which (in this case) uses the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project) request to trigger an immediate pull after updates to the repository.
+
+   ```plaintext
+   https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token>
+   ```
 
-  ```plaintext
-  https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token>
-  ```
+1. Ensure the **Push Events** checkbox is selected.
+1. Select **Add Webhook** to save the webhook.
 
-- Ensure that the **Push Events** checkbox is selected.
-- Click on **Add Webhook** button to save the webhook.
-- To test the integration click on the **Test** button and confirm GitLab does not return any error.
+To test the integration, select the **Test** button and confirm GitLab doesn't return an error message.
 
 ### Preventing conflicts using a `pre-receive` hook
 
 WARNING:
-The solution proposed will negatively impact the performance of
-Git push operations because they will be proxied to the upstream Git
+The solution proposed negatively affects the performance of
+Git push operations because they are proxied to the upstream Git
 repository.
 
 A server-side `pre-receive` hook can be used to prevent the race condition
 described above by only accepting the push after first pushing the commit to
 the upstream Git repository. In this configuration one Git repository acts as
 the authoritative upstream, and the other as downstream. The `pre-receive` hook
-will be installed on the downstream repository.
+is installed on the downstream repository.
 
 Read about [configuring Server hooks](../../../administration/server_hooks.md) on the GitLab server.
 
@@ -544,11 +537,11 @@ fi
 Note that this sample has a few limitations:
 
 - This example may not work verbatim for your use case and might need modification.
-  - It does not regard different types of authentication mechanisms for the mirror.
-  - It does not work with forced updates (rewriting history).
-  - Only branches that match the `allowlist` patterns will be proxy pushed.
+  - It doesn't regard different types of authentication mechanisms for the mirror.
+  - It doesn't work with forced updates (rewriting history).
+  - Only branches that match the `allowlist` patterns are proxy pushed.
 - The script circumvents the Git hook quarantine environment because the update of `$TARGET_REPO`
-  is seen as a ref update and Git will complain about it.
+  is seen as a ref update, and Git displays warnings about it.
 
 ### Mirroring with Perforce Helix via Git Fusion **(PREMIUM)**
 
@@ -564,22 +557,22 @@ mirror projects with GitLab. This may be useful in some situations when migratin
 to GitLab where overlapping Perforce Helix workspaces cannot be migrated simultaneously to GitLab.
 
 If using mirroring with Perforce Helix, you should only mirror protected branches. Perforce Helix
-will reject any pushes that rewrite history. Only the fewest number of branches should be mirrored
+rejects any pushes that rewrite history. Only the fewest number of branches should be mirrored
 due to the performance limitations of Git Fusion.
 
 When configuring mirroring with Perforce Helix via Git Fusion, the following Git Fusion
 settings are recommended:
 
-- `change-pusher` should be disabled. Otherwise, every commit will be rewritten as being committed
+- `change-pusher` should be disabled. Otherwise, every commit is rewritten as being committed
   by the mirroring account, rather than being mapped to existing Perforce Helix users or the `unknown_git` user.
-- `unknown_git` user will be used as the commit author if the GitLab user does not exist in
+- `unknown_git` user is used as the commit author if the GitLab user doesn't exist in
   Perforce Helix.
 
 Read about [Git Fusion settings on Perforce.com](https://www.perforce.com/manuals/git-fusion/Content/Git-Fusion/section_vss_bdw_w3.html#section_zdp_zz1_3l).
 
 ## Troubleshooting
 
-Should an error occur during a push, GitLab will display an "Error" highlight for that repository. Details on the error can then be seen by hovering over the highlight text.
+Should an error occur during a push, GitLab displays an **Error** highlight for that repository. Details on the error can then be seen by hovering over the highlight text.
 
 ### 13:Received RST_STREAM with error code 2 with GitHub
 
@@ -591,6 +584,6 @@ When upgrading to GitLab 11.11.8 or newer, a change in how usernames are represe
 
 ### Connection blocked because server only allows public key authentication
 
-As the error indicates, the connection is getting blocked between GitLab and the remote repository. Even if a [TCP Check](../../../administration/raketasks/maintenance.md#check-tcp-connectivity-to-a-remote-site) is successful, you will need to check any networking components in the route from GitLab to the remote Server to ensure there's no blockage.
+As the error indicates, the connection is getting blocked between GitLab and the remote repository. Even if a [TCP Check](../../../administration/raketasks/maintenance.md#check-tcp-connectivity-to-a-remote-site) is successful, you must check any networking components in the route from GitLab to the remote Server to ensure there's no blockage.
 
 For example, we've seen this error when a Firewall was performing a `Deep SSH Inspection` on outgoing packets.
diff --git a/doc/user/project/repository/x509_signed_commits/index.md b/doc/user/project/repository/x509_signed_commits/index.md
index 29c1c32145d..c89f3a267ba 100644
--- a/doc/user/project/repository/x509_signed_commits/index.md
+++ b/doc/user/project/repository/x509_signed_commits/index.md
@@ -39,7 +39,7 @@ recommend using certificates from a PKI that are in line with
 
 ## Obtaining an X.509 key pair
 
-If your organization has Public Key Infrastructure (PKI), that PKI will provide
+If your organization has Public Key Infrastructure (PKI), that PKI provides
 an S/MIME key.
 
 If you do not have an S/MIME key pair from a PKI, you can either create your
@@ -49,7 +49,7 @@ and some of them generate keys for free.
 
 ## Associating your X.509 certificate with Git
 
-To take advantage of X.509 signing, you will need Git 2.19.0 or later. You can
+To take advantage of X.509 signing, you need Git 2.19.0 or later. You can
 check your Git version with:
 
 ```shell
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 246818f32c5..c3427830426 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -103,8 +103,7 @@ Some features depend on others:
   When the **Issues** option is disabled, you can still access **Milestones**
   from merge requests.
 
-- Additionally, if you disable both **Issues** and **Merge Requests**, you will no
-  longer have access to:
+- Additionally, if you disable both **Issues** and **Merge Requests**, you cannot access:
   - **Labels**
   - **Milestones**
 
@@ -220,7 +219,7 @@ To rename a repository:
 1. Click **Change path**.
 
 Remember that this can have unintended side effects since everyone with the
-old URL won't be able to push or pull. Read more about what happens with the
+old URL can't push or pull. Read more about what happens with the
 [redirects when renaming repositories](../repository/index.md#redirects-when-changing-repository-paths).
 
 #### Transferring an existing project into another namespace
@@ -243,7 +242,7 @@ To transfer a project:
    project to.
 1. Confirm the transfer by typing the project's path as instructed.
 
-Once done, you will be taken to the new project's namespace. At this point,
+Once done, you are redirected to the new project's namespace. At this point,
 read what happens with the
 [redirects from the old project to the new one](../repository/index.md#redirects-when-changing-repository-paths).
 
@@ -293,7 +292,7 @@ If you want to use the fork for yourself and don't need to send
 you can safely remove the fork relationship.
 
 WARNING:
-Once removed, the fork relationship cannot be restored. You will no longer be able to send merge requests to the source, and if anyone has forked your project, their fork will also lose the relationship.
+Once removed, the fork relationship cannot be restored. You can't send merge requests to the source, and if anyone has forked your project, their fork also loses the relationship.
 
 To do so: