Add latest changes from gitlab-org/gitlab@master

13 files changed, 53 insertions, 52 deletions

diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index d1ea2978202..7c6f4a32b57 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -62,8 +62,7 @@ must disable the **primary** node.
 
 - If you do not have SSH access to the **primary** node, take the machine offline and
   prevent it from rebooting by any means at your disposal.
-  Since there are many ways you may prefer to accomplish this, we will avoid a
-  single recommendation. You may need to:
+  You might need to:
 
   - Reconfigure the load balancers.
   - Change DNS records (for example, point the primary DNS record to the
@@ -240,11 +239,11 @@ an external PostgreSQL database, as it can only perform changes on a **secondary
 node with GitLab and the database on the same machine. As a result, a manual process is
 required:
 
-1. Promote the replica database associated with the **secondary** site. This will
-   set the database to read-write. The instructions vary depending on where your database is hosted:
+1. Promote the replica database associated with the **secondary** site. This
+   sets the database to read-write. The instructions vary depending on where your database is hosted:
    - [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Promote)
    - [Azure PostgreSQL](https://docs.microsoft.com/en-us/azure/postgresql/howto-read-replicas-portal#stop-replication)
-   - For other external PostgreSQL databases, save the following script in you
+   - For other external PostgreSQL databases, save the following script in your
      secondary node, for example `/tmp/geo_promote.sh`, and modify the connection
      parameters to match your environment. Then, execute it to promote the replica:
 
@@ -292,7 +291,7 @@ required:
 ### Step 4. (Optional) Updating the primary domain DNS record
 
 Updating the DNS records for the primary domain to point to the **secondary** node
-will prevent the need to update all references to the primary domain to the
+to prevent the need to update all references to the primary domain to the
 secondary domain, like changing Git remotes and API URLs.
 
 1. SSH into the **secondary** node and login as root:
@@ -311,7 +310,7 @@ secondary domain, like changing Git remotes and API URLs.
    ```
 
    NOTE:
-   Changing `external_url` won't prevent access via the old secondary URL, as
+   Changing `external_url` does not prevent access via the old secondary URL, as
    long as the secondary DNS records are still intact.
 
 1. Reconfigure the **secondary** node for the change to take effect:
@@ -326,7 +325,7 @@ secondary domain, like changing Git remotes and API URLs.
    gitlab-rake geo:update_primary_node_url
    ```
 
-   This command will use the changed `external_url` configuration defined
+   This command uses the changed `external_url` configuration defined
    in `/etc/gitlab/gitlab.rb`.
 
 1. For GitLab 11.11 through 12.7 only, you may need to update the **primary**
@@ -334,7 +333,7 @@ secondary domain, like changing Git remotes and API URLs.
 
    To determine if you need to do this, search for the
    `gitlab_rails["geo_node_name"]` setting in your `/etc/gitlab/gitlab.rb`
-   file. If it is commented out with `#` or not found at all, then you will
+   file. If it is commented out with `#` or not found at all, then you
    need to update the **primary** node's name in the database. You can search for it
    like so:
 
@@ -444,7 +443,7 @@ and after that you also need two extra steps.
 
 Now we need to make each **secondary** node listen to changes on the new **primary** node. To do that you need
 to [initiate the replication process](../setup/database.md#step-3-initiate-the-replication-process) again but this time
-for another **primary** node. All the old replication settings will be overwritten.
+for another **primary** node. All the old replication settings are overwritten.
 
 ## Promoting a secondary Geo cluster in GitLab Cloud Native Helm Charts
 
@@ -479,8 +478,7 @@ must disable the **primary** site:
 
 - If you do not have access to the **primary** Kubernetes cluster, take the cluster offline and
   prevent it from coming back online by any means at your disposal.
-  Since there are many ways you may prefer to accomplish this, we will avoid a
-  single recommendation. You may need to:
+  You might need to:
 
   - Reconfigure the load balancers.
   - Change DNS records (for example, point the primary DNS record to the
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 8026842248d..6cec13fde02 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -27,7 +27,7 @@ to clone and fetch large repositories, speeding up development.
 
 For a video introduction to Geo, see [Introduction to GitLab Geo - GitLab Features](https://www.youtube.com/watch?v=-HDLxSjEh6w).
 
-To make sure you're using the right version of the documentation, navigate to [this page on GitLab.com](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab/blob/v11.2.3-ee/doc/administration/geo/index.md).
+To make sure you're using the right version of the documentation, navigate to [the Geo page on GitLab.com](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/index.md) and choose the appropriate release from the **Switch branch/tag** dropdown. For example, [`v11.2.3-ee`](https://gitlab.com/gitlab-org/gitlab/blob/v11.2.3-ee/doc/administration/geo/index.md).
 
 ## Use cases
 
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index d8c018c83f8..d9a9c456235 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -1304,8 +1304,8 @@ GitLab Rails application, the Docker Registry, or something else. In this
 case, since we know that since the login succeeded, we probably need to look
 at the communication between the client and the Registry.
 
-The REST API between the Docker client and Registry is [described
-here](https://docs.docker.com/registry/spec/api/). Normally, one would just
+The REST API between the Docker client and Registry is described
+[in the Docker documentation](https://docs.docker.com/registry/spec/api/). Normally, one would just
 use Wireshark or tcpdump to capture the traffic and see where things went
 wrong. However, since all communications between Docker clients and servers
 are done over HTTPS, it's a bit difficult to decrypt the traffic quickly even
diff --git a/doc/api/events.md b/doc/api/events.md
index 5664d97d7db..49d99cc43fe 100644
--- a/doc/api/events.md
+++ b/doc/api/events.md
@@ -71,10 +71,10 @@ Parameters:
 | --------- | ---- | -------- | ----------- |
 | `action` | string | no | Include only events of a particular [action type](#action-types) |
 | `target_type` | string | no | Include only events of a particular [target type](#target-types) |
-| `before` | date | no |  Include only events created before a particular date. Please see [here for the supported format](#date-formatting) |
-| `after` | date | no |  Include only events created after a particular date. Please see [here for the supported format](#date-formatting)  |
+| `before` | date | no |  Include only events created before a particular date. [View how to format dates](#date-formatting). |
+| `after` | date | no |  Include only events created after a particular date. [View how to format dates](#date-formatting).  |
 | `scope` | string | no | Include all events across a user's projects. |
-| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc` |
+| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc`. |
 
 Example request:
 
@@ -148,9 +148,9 @@ Parameters:
 | `id` | integer | yes | The ID or Username of the user |
 | `action` | string | no | Include only events of a particular [action type](#action-types) |
 | `target_type` | string | no | Include only events of a particular [target type](#target-types) |
-| `before` | date | no |  Include only events created before a particular date. Please see [here for the supported format](#date-formatting) |
-| `after` | date | no |  Include only events created after a particular date. Please see [here for the supported format](#date-formatting)  |
-| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc` |
+| `before` | date | no |  Include only events created before a particular date. [View how to format dates](#date-formatting). |
+| `after` | date | no |  Include only events created after a particular date. [View how to format dates](#date-formatting). |
+| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc`. |
 | `page` | integer | no | The page of results to return. Defaults to 1. |
 | `per_page` | integer | no | The number of results per page. Defaults to 20. |
 
@@ -286,9 +286,9 @@ Parameters:
 | `project_id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
 | `action` | string | no | Include only events of a particular [action type](#action-types) |
 | `target_type` | string | no | Include only events of a particular [target type](#target-types) |
-| `before` | date | no |  Include only events created before a particular date. Please see [here for the supported format](#date-formatting) |
-| `after` | date | no |  Include only events created after a particular date. Please see [here for the supported format](#date-formatting)  |
-| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc` |
+| `before` | date | no |  Include only events created before a particular date. [View how to format dates](#date-formatting). |
+| `after` | date | no |  Include only events created after a particular date. [View how to format dates](#date-formatting).  |
+| `sort` | string | no | Sort events in `asc` or `desc` order by `created_at`. Default is `desc`. |
 
 Example request:
 
diff --git a/doc/architecture/blueprints/container_registry_metadata_database/index.md b/doc/architecture/blueprints/container_registry_metadata_database/index.md
index 4e40f249e56..86628b31536 100644
--- a/doc/architecture/blueprints/container_registry_metadata_database/index.md
+++ b/doc/architecture/blueprints/container_registry_metadata_database/index.md
@@ -26,7 +26,7 @@ graph LR
    R -- Write/read metadata --> B
 ```
 
-Client applications (e.g. GitLab Rails and Docker CLI) interact with the Container Registry through its [HTTP API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md). The most common operations are pushing and pulling images to/from the registry, which require a series of HTTP requests in a specific order. The request flow for these operations is detailed [here](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/push-pull-request-flow.md).
+Client applications (e.g. GitLab Rails and Docker CLI) interact with the Container Registry through its [HTTP API](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/spec/api.md). The most common operations are pushing and pulling images to/from the registry, which require a series of HTTP requests in a specific order. The request flow for these operations is detailed in the [Request flow](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs-gitlab/push-pull-request-flow.md).
 
 The registry supports multiple [storage backends](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#storage), including Google Cloud Storage (GCS) which is used for the GitLab.com registry. In the storage backend, images are stored as blobs, deduplicated, and shared across repositories. These are then linked (like a symlink) to each repository that relies on them, giving them access to the central storage location.
 
@@ -156,7 +156,7 @@ Running *online* and [*post deployment*](../../../development/post_deployment_mi
 
 The registry database will be partitioned from start to achieve greater performance (by limiting the amount of data to act upon and enable parallel execution), easier maintenance (by splitting tables and indexes into smaller units), and high availability (with partition independence). By partitioning the database from start we can also facilitate a sharding implementation later on if necessary.
 
-Although blobs are shared across repositories, manifest and tag metadata are scoped by repository. This is also visible at the API level, where all write and read requests (except [listing repositories](https://gitlab.com/gitlab-org/container-registry/-/blob/a113d0f0ab29b49cf88e173ee871893a9fc56a90/docs/spec/api.md#listing-repositories)) are scoped by repository, with its namespace being part of the request URI. For this reason, after [identifying access patterns](https://gitlab.com/gitlab-org/gitlab/-/issues/234255), we decided to partition manifests and tags by repository and blobs by digest, ensuring that lookups are always performed by partition key for optimal performance. The initial version of the partitioned schema was documented [here](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/60918).
+Although blobs are shared across repositories, manifest and tag metadata are scoped by repository. This is also visible at the API level, where all write and read requests (except [listing repositories](https://gitlab.com/gitlab-org/container-registry/-/blob/a113d0f0ab29b49cf88e173ee871893a9fc56a90/docs/spec/api.md#listing-repositories)) are scoped by repository, with its namespace being part of the request URI. For this reason, after [identifying access patterns](https://gitlab.com/gitlab-org/gitlab/-/issues/234255), we decided to partition manifests and tags by repository and blobs by digest, ensuring that lookups are always performed by partition key for optimal performance. The initial version of the partitioned schema was documented [in a merge request](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/60918).
 
 #### GitLab.com
 
diff --git a/doc/architecture/blueprints/image_resizing/index.md b/doc/architecture/blueprints/image_resizing/index.md
index 686a2f9c8f5..26c15d7a035 100644
--- a/doc/architecture/blueprints/image_resizing/index.md
+++ b/doc/architecture/blueprints/image_resizing/index.md
@@ -35,10 +35,10 @@ sequenceDiagram
 
 Content image resizing is a more complex problem to tackle. There are no set size restrictions and there are additional features or requirements to consider.
 
-- Dynamic WebP support - the WebP format typically achieves an average of 30% more compression than JPEG without the loss of image quality. More details [here](https://developers.google.com/speed/webp/docs/c_study)
+- Dynamic WebP support - the WebP format typically achieves an average of 30% more compression than JPEG without the loss of image quality. More details are in [this Google Comparative Study](https://developers.google.com/speed/webp/docs/c_study)
 - Extract first image of GIF's so we can prevent from loading 10MB pixels
 - Check Device Pixel Ratio to deliver nice images on High DPI screens
-- Progressive image loading, similar to what is described [here](https://www.sitepoint.com/how-to-build-your-own-progressive-image-loader/)
+- Progressive image loading, similar to what is described in [this article about how to build a progressive image loader](https://www.sitepoint.com/how-to-build-your-own-progressive-image-loader/)
 - Resizing recommendations (size, clarity, etc.)
 - Storage
 
diff --git a/doc/development/feature_flags/controls.md b/doc/development/feature_flags/controls.md
index c9538c38850..08a4401181b 100644
--- a/doc/development/feature_flags/controls.md
+++ b/doc/development/feature_flags/controls.md
@@ -266,7 +266,7 @@ Changes to the issue format can be submitted in the
 Any feature flag change that affects any GitLab instance is automatically logged in
 [features_json.log](../../administration/logs.md#features_jsonlog).
 You can search the change history in [Kibana](https://about.gitlab.com/handbook/support/workflows/kibana.html).
-You can access the feature flag change history for GitLab.com [here](https://log.gprd.gitlab.net/goto/d060337c017723084c6d97e09e591fc6).
+You can also access the feature flag change history for GitLab.com [in Kibana](https://log.gprd.gitlab.net/goto/d060337c017723084c6d97e09e591fc6).
 
 ## Cleaning up
 
diff --git a/doc/development/multi_version_compatibility.md b/doc/development/multi_version_compatibility.md
index 8a8026d6e09..44e93bfb8a8 100644
--- a/doc/development/multi_version_compatibility.md
+++ b/doc/development/multi_version_compatibility.md
@@ -65,7 +65,7 @@ Let's see how we can handle them safely.
 ### Route changes
 
 When changing routing we should pay attention to make sure a route generated from the new version can be served by the old one and vice versa.
-As you can see in [this page](#some-links-to-issues-and-mrs-were-broken), not doing it can lead to an outage.
+[As you can see](#some-links-to-issues-and-mrs-were-broken), not doing it can lead to an outage.
 This type of change may look like an immediate switch between the two implementations. However,
 especially with the canary stage, there is an extended period of time where both version of the code
 coexists in production.
diff --git a/doc/development/packages.md b/doc/development/packages.md
index 2dd712f2692..3727376d957 100644
--- a/doc/development/packages.md
+++ b/doc/development/packages.md
@@ -219,8 +219,8 @@ demonstrates adding an instance-level endpoint for Conan to workhorse. You can a
 implemented in the same file.
 
 Once the route has been added, you must add an additional `/authorize` version of the upload endpoint to your API file.
-[Here is an example](https://gitlab.com/gitlab-org/gitlab/blob/398fef1ca26ae2b2c3dc89750f6b20455a1e5507/ee/lib/api/maven_packages.rb#L164)
-of the additional endpoint added for Maven. The `/authorize` endpoint verifies and authorizes the request from workhorse,
+[This example](https://gitlab.com/gitlab-org/gitlab/blob/398fef1ca26ae2b2c3dc89750f6b20455a1e5507/ee/lib/api/maven_packages.rb#L164)
+shows the additional endpoint added for Maven. The `/authorize` endpoint verifies and authorizes the request from workhorse,
 then the normal upload endpoint is implemented below, consuming the metadata that workhorse provides in order to
 create the package record. Workhorse provides a variety of file metadata such as type, size, and different checksum formats.
 
diff --git a/doc/integration/jira/connect-app.md b/doc/integration/jira/connect-app.md
index b096d5bff61..a080d513afa 100644
--- a/doc/integration/jira/connect-app.md
+++ b/doc/integration/jira/connect-app.md
@@ -4,12 +4,12 @@ group: Ecosystem
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab for Jira app **(FREE SAAS)**
+# GitLab.com for Jira Cloud app **(FREE SAAS)**
 
 You can integrate GitLab.com and Jira Cloud using the
-[GitLab for Jira](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud)
-app in the Atlassian Marketplace. The user configuring GitLab for Jira must have
-[Maintainer](../../user/permissions.md) permissions in the GitLab namespace.
+[GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud)
+app in the Atlassian Marketplace. The user configuring GitLab.com for Jira Cloud must have
+[Maintainer](../../user/permissions.md) permissions in the GitLab.com namespace.
 
 This integration method supports [smart commits](dvcs.md#smart-commits).
 
@@ -18,30 +18,30 @@ synchronized in real-time. The DVCS connector updates data only once per hour.
 If you are not using both of these environments, use the [Jira DVCS Connector](dvcs.md) method.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For a walkthrough of the integration with GitLab for Jira, watch
-[Configure GitLab Jira Integration using Marketplace App](https://youtu.be/SwR-g1s1zTo) on YouTube.
+For a walkthrough of the integration with GitLab.com for Jira Cloud, watch
+[Configure GitLab.com Jira Could Integration using Marketplace App](https://youtu.be/SwR-g1s1zTo) on YouTube.
 
 1. Go to **Jira Settings > Apps > Find new apps**, then search for GitLab.
-1. Click **GitLab for Jira**, then click **Get it now**, or go to the
+1. Click **GitLab.com for Jira Cloud**, then click **Get it now**, or go to the
    [App in the marketplace directly](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud).
 
-   ![Install GitLab App on Jira](img/jira_dev_panel_setup_com_1.png)
+   ![Install GitLab.com app on Jira Cloud](img/jira_dev_panel_setup_com_1.png)
 1. After installing, click **Get started** to go to the configurations page.
    This page is always available under **Jira Settings > Apps > Manage apps**.
 
-   ![Start GitLab App configuration on Jira](img/jira_dev_panel_setup_com_2.png)
+   ![Start GitLab.com app configuration on Jira Cloud](img/jira_dev_panel_setup_com_2.png)
 1. If not already signed in to GitLab.com, you must sign in as a user with
    [Maintainer](../../user/permissions.md) permissions to add namespaces.
 
-   ![Sign in to GitLab.com in GitLab Jira App](img/jira_dev_panel_setup_com_3_v13_9.png)
+   ![Sign in to GitLab.com in GitLab.com for Jira Cloud app](img/jira_dev_panel_setup_com_3_v13_9.png)
 1. Select **Add namespace** to open the list of available namespaces.
 
 1. Identify the namespace you want to link, and select **Link**.
 
-   ![Link namespace in GitLab Jira App](img/jira_dev_panel_setup_com_4_v13_9.png)
+   ![Link namespace in GitLab.com for Jira Cloud app](img/jira_dev_panel_setup_com_4_v13_9.png)
 
 NOTE:
-The GitLab user only needs access when adding a new namespace. For syncing with
+The GitLab.com user only needs access when adding a new namespace. For syncing with
 Jira, we do not depend on the user's token.
 
 After a namespace is added:
@@ -52,10 +52,10 @@ After a namespace is added:
 
 Support for syncing past branch and commit data [is planned](https://gitlab.com/gitlab-org/gitlab/-/issues/263240).
 
-## Install the GitLab Jira Cloud application for self-managed instances **(FREE SELF)**
+## Install the GitLab.com for Jira Cloud application for self-managed instances **(FREE SELF)**
 
 If your GitLab instance is self-managed, you must follow some
-extra steps to install the GitLab Jira Cloud application.
+extra steps to install the GitLab.com for Jira Cloud application.
 
 Each Jira Cloud application must be installed from a single location. Jira fetches
 a [manifest file](https://developer.atlassian.com/cloud/jira/platform/connect-app-descriptor/)
@@ -91,7 +91,7 @@ from outside the Marketplace, which allows you to install the application:
 
 1. Disable [development mode](https://developer.atlassian.com/cloud/jira/platform/getting-started-with-connect/#step-2--enable-development-mode) on your Jira instance.
 
-The **GitLab for Jira** app now displays under **Manage apps**. You can also
+The **GitLab.com for Jira Cloud** app now displays under **Manage apps**. You can also
 click **Get started** to open the configuration page rendered from your GitLab instance.
 
 NOTE:
@@ -121,9 +121,9 @@ for details.
 NOTE:
 DVCS means distributed version control system.
 
-## Troubleshooting GitLab for Jira
+## Troubleshooting GitLab.com for Jira Cloud
 
-The GitLab for Jira App uses an iframe to add namespaces on the settings page. Some browsers block cross-site cookies. This can lead to a message saying that the user needs to log in on GitLab.com even though the user is already logged in.
+The GitLab.com for Jira Cloud app uses an iframe to add namespaces on the settings page. Some browsers block cross-site cookies. This can lead to a message saying that the user needs to log in on GitLab.com even though the user is already logged in.
 
 > "You need to sign in or sign up before continuing."
 
diff --git a/doc/integration/jira/development_panel.md b/doc/integration/jira/development_panel.md
index 1617e950104..cc1a3a96577 100644
--- a/doc/integration/jira/development_panel.md
+++ b/doc/integration/jira/development_panel.md
@@ -52,7 +52,7 @@ self-managed GitLab) set up the integration to simplify administration.
 
 | If you use Jira on: | GitLab.com customers need: | GitLab self-managed customers need: |
 |-|-|-|
-| [Atlassian cloud](https://www.atlassian.com/cloud) | The [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?hosting=cloud&tab=overview) application installed from the [Atlassian Marketplace](https://marketplace.atlassian.com). This offers real-time sync between GitLab and Jira. | The [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?hosting=cloud&tab=overview), using a workaround process. See the documentation for [installing the GitLab Jira Cloud application for self-managed instances](connect-app.md#install-the-gitlab-jira-cloud-application-for-self-managed-instances) for more information. |
+| [Atlassian cloud](https://www.atlassian.com/cloud) | The [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?hosting=cloud&tab=overview) application installed from the [Atlassian Marketplace](https://marketplace.atlassian.com). This offers real-time sync between GitLab and Jira. | The [GitLab.com for Jira Cloud](https://marketplace.atlassian.com/apps/1221011/gitlab-com-for-jira-cloud?hosting=cloud&tab=overview), using a workaround process. See the documentation for [installing the GitLab Jira Cloud application for self-managed instances](connect-app.md#install-the-gitlabcom-for-jira-cloud-application-for-self-managed-instances) for more information. |
 | Your own server | The Jira DVCS (distributed version control system) connector. This syncs data hourly. | The [Jira DVCS Connector](dvcs.md). |
 
 Each GitLab project can be configured to connect to an entire Jira instance. That means one GitLab
diff --git a/doc/user/project/integrations/prometheus_library/cloudwatch.md b/doc/user/project/integrations/prometheus_library/cloudwatch.md
index 0eaa9cae7c0..b35ebacbd31 100644
--- a/doc/user/project/integrations/prometheus_library/cloudwatch.md
+++ b/doc/user/project/integrations/prometheus_library/cloudwatch.md
@@ -31,7 +31,7 @@ Cloudwatch exporter retrieves and parses the specified Cloudwatch metrics, and
 translates them into a Prometheus monitoring endpoint.
 
 The only supported AWS resource is the Elastic Load Balancer, whose Cloudwatch
-metrics are [documented here](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloudwatch-metrics.html).
+metrics are listed in [this AWS documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-cloudwatch-metrics.html).
 
 You can [download a sample Cloudwatch Exporter configuration file](../samples/cloudwatch.yml)
 that's configured for basic AWS ELB monitoring.
diff --git a/doc/user/project/repository/repository_mirroring.md b/doc/user/project/repository/repository_mirroring.md
index f6857623bc4..3bbe9e6cb66 100644
--- a/doc/user/project/repository/repository_mirroring.md
+++ b/doc/user/project/repository/repository_mirroring.md
@@ -65,7 +65,10 @@ For an existing project, you can set up push mirroring as follows:
 ![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. The mirrored repository receives all changes when:
+mirror diverging. 
+
+Unlike [pull mirroring](#how-it-works), the mirrored repository is not periodically auto-synced. 
+The mirrored repository receives all changes only when:
 
 - Commits are pushed to GitLab.
 - A [forced update](#forcing-an-update) is initiated.