Add latest changes from gitlab-org/gitlab@13-9-stable-eev13.9.0-rc42

19 files changed, 204 insertions, 174 deletions

diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md
index 028858c96f6..70416c224c7 100644
--- a/doc/user/admin_area/settings/account_and_limit_settings.md
+++ b/doc/user/admin_area/settings/account_and_limit_settings.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Account and limit settings **(CORE ONLY)**
+# Account and limit settings **(FREE SELF)**
 
 ## Default projects limit
 
@@ -13,7 +13,8 @@ You can change the default maximum number of projects that users can create in t
 Navigate to **Admin Area > Settings > General**, then expand **Account and Limit**.
 You can increase or decrease that `Default projects limit` value.
 
-- If you set `Default projects limit` to 0, users are not allowed to create projects in their users personal namespace. However, projects can still be created within a group.
+- If you set `Default projects limit` to 0, users are not allowed to create projects
+  in their users personal namespace. However, projects can still be created in a group.
 
 ## Max attachment size
 
@@ -22,8 +23,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit
 From here, you can increase or decrease by changing the value in `Maximum attachment size (MB)`.
 
 NOTE:
-If you choose a size larger than what is currently configured for the web server,
-you will likely get errors. See the [troubleshooting section](#troubleshooting) for more
+If you choose a size larger than the configured value for the web server,
+you may receive errors. See the [troubleshooting section](#troubleshooting) for more
 details.
 
 ## Max push size
@@ -39,8 +40,8 @@ Navigate to **Admin Area > Settings > General**, then expand **Account and Limit
 From here, you can increase or decrease by changing the value in `Maximum import size (MB)`.
 
 NOTE:
-If you choose a size larger than what is currently configured for the web server,
-you will likely get errors. See the [troubleshooting section](#troubleshooting) for more
+If you choose a size larger than the configured value for the web server,
+you may receive errors. See the [troubleshooting section](#troubleshooting) for more
 details.
 
 ## Personal Access Token prefix
@@ -62,14 +63,11 @@ to any PAT generated in the system by any user:
 It is also possible to configure the prefix via the [settings API](../../../api/settings.md)
 using the `personal_access_token_prefix` field.
 
-## Repository size limit **(STARTER ONLY)**
+## Repository size limit **(PREMIUM SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/740) in [GitLab Enterprise Edition 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/#limit-project-size-ee).
-
-Repositories within your GitLab instance can grow quickly, especially if you are
+Repositories in your GitLab instance can grow quickly, especially if you are
 using LFS. Their size can grow exponentially, rapidly consuming available storage.
-
-To avoid this from happening, you can set a hard limit for your repositories' size.
+To prevent this from happening, you can set a hard limit for your repositories' size.
 This limit can be set globally, per group, or per project, with per project limits
 taking the highest priority.
 
@@ -88,7 +86,7 @@ For instance, consider the following workflow:
 Only a GitLab administrator can set those limits. Setting the limit to `0` means
 there are no restrictions.
 
-These settings can be found within:
+These settings can be found in:
 
 - Each project's settings:
   1. From the Project's homepage, navigate to **Settings > General**.
@@ -104,9 +102,9 @@ These settings can be found within:
   1. Fill in the **Size limit per repository (MB)** field.
   1. Click **Save changes**.
 
-The first push of a new project, including LFS objects, will be checked for size
-and **will** be rejected if the sum of their sizes exceeds the maximum allowed
-repository size.
+The first push of a new project, including LFS objects, is checked for size.
+If the sum of their sizes exceeds the maximum allowed repository size, the push
+is rejected.
 
 NOTE:
 The repository size limit includes repository files and LFS, but does not include artifacts, uploads,
@@ -121,29 +119,46 @@ For GitLab.com repository size limits, see [accounts and limit settings](../../g
 
 ### 413 Request Entity Too Large
 
-If you are attaching a file to a comment or reply in GitLab and receive the `413 Request Entity Too Large`
-error, it is likely caused by having a [max attachment size](#max-attachment-size)
-larger than what the web server is configured to allow.
+When attaching a file to a comment or reply in GitLab displays a `413 Request Entity Too Large`
+error, the [max attachment size](#max-attachment-size)
+is probably larger than the web server's allowed value.
 
-If you wanted to increase the max attachment size to 200m in a GitLab
-[Omnibus](https://docs.gitlab.com/omnibus/) install, for example, you might need to
+To increase the max attachment size to 200 MB in a
+[Omnibus GitLab](https://docs.gitlab.com/omnibus/) install, you may need to
 add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size:
 
 ```ruby
 nginx['client_max_body_size'] = "200m"
 ```
 
-## Limiting lifetime of personal access tokens **(ULTIMATE ONLY)**
+## Customize session duration for Git Operations when 2FA is enabled **(PREMIUM)**
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/296669) in GitLab 13.9.
+> - It's deployed behind a feature flag, disabled by default.
+> - It's disabled on GitLab.com.
+> - It's not recommended for production use.
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](../../../security/two_factor_authentication.md#enable-or-disable-two-factor-authentication-2fa-for-git-operations)
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.6.
+GitLab administrators can choose to customize the session duration (in minutes) for Git operations when 2FA is enabled. The default is 15 and this can be set to a value between 1 and 10080.
+
+To set a limit on how long these sessions are valid:
+
+1. Navigate to **Admin Area > Settings > General**.
+1. Expand the **Account and limit** section.
+1. Fill in the **Session duration for Git operations when 2FA is enabled (minutes)** field.
+1. Click **Save changes**.
+
+## Limiting lifetime of personal access tokens **(ULTIMATE SELF)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab Ultimate 12.6.
 
 Users can optionally specify an expiration date for
 [personal access tokens](../../profile/personal_access_tokens.md).
 This expiration date is not a requirement, and can be set to any arbitrary date.
 
-Since personal access tokens are the only token needed for programmatic access to GitLab,
-organizations with security requirements may want to enforce more protection to require
-regular rotation of these tokens.
+Personal access tokens are the only tokens needed for programmatic access to GitLab.
+However, organizations with security requirements may want to enforce more protection by
+requiring the regular rotation of these tokens.
 
 ### Setting a limit
 
@@ -157,48 +172,40 @@ To set a limit on how long personal access tokens are valid:
 1. Fill in the **Maximum allowable lifetime for personal access tokens (days)** field.
 1. Click **Save changes**.
 
-Once a lifetime for personal access tokens is set, GitLab will:
+Once a lifetime for personal access tokens is set, GitLab:
 
-- Apply the lifetime for new personal access tokens, and require users to set an expiration date
+- Applies the lifetime for new personal access tokens, and require users to set an expiration date
   and a date no later than the allowed lifetime.
 - After three hours, revoke old tokens with no expiration date or with a lifetime longer than the
   allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
   or remove it, before revocation takes place.
 
-## Optional enforcement of Personal Access Token expiry **(ULTIMATE ONLY)**
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.1.
-> - It is deployed behind a feature flag, disabled by default.
-> - It is disabled on GitLab.com.
-> - It is not recommended for production use.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-optional-enforcement-of-personal-access-token-expiry-feature). **(CORE ONLY)**
+## Enforcement of SSH key expiration **(ULTIMATE SELF)**
 
-GitLab administrators can choose to prevent personal access tokens from expiring automatically. The tokens will be usable after the expiry date, unless they are revoked explicitly.
+GitLab administrators can choose to enforce the expiration of SSH keys after their expiration dates.
+If you enable this feature, this disables all _expired_ SSH keys.
 
 To do this:
 
 1. Navigate to **Admin Area > Settings > General**.
 1. Expand the **Account and limit** section.
-1. Uncheck the **Enforce personal access token expiration** checkbox.
+1. Select the **Enforce SSH key expiration** checkbox.
 
-### Enable or disable optional enforcement of Personal Access Token expiry Feature **(CORE ONLY)**
+## Optional enforcement of Personal Access Token expiry **(ULTIMATE SELF)**
 
-Optional Enforcement of Personal Access Token Expiry is deployed behind a feature flag and is **disabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) can enable it for your instance from the [rails console](../../../administration/feature_flags.md#start-the-gitlab-rails-console).
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab Ultimate 13.1.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/296881) in GitLab 13.9.
 
-To enable it:
+GitLab administrators can choose to prevent personal access tokens from expiring
+automatically. The tokens are usable after the expiry date, unless they are revoked explicitly.
 
-```ruby
-Feature.enable(:enforce_pat_expiration)
-```
-
-To disable it:
+To do this:
 
-```ruby
-Feature.disable(:enforce_pat_expiration)
-```
+1. Navigate to **Admin Area > Settings > General**.
+1. Expand the **Account and limit** section.
+1. Uncheck the **Enforce personal access token expiration** checkbox.
 
-## Disabling user profile name changes **(PREMIUM ONLY)**
+## Disabling user profile name changes **(PREMIUM SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24605) in GitLab 12.7.
 
@@ -210,4 +217,6 @@ To do this:
 1. Check the **Prevent users from changing their profile name** checkbox.
 
 NOTE:
-When this ability is disabled, GitLab administrators will still be able to update the name of any user in their instance via the [Admin UI](../index.md#administering-users) or the [API](../../../api/users.md#user-modification)
+When this ability is disabled, GitLab administrators can still use the
+[Admin UI](../index.md#administering-users) or the
+[API](../../../api/users.md#user-modification) to update usernames.
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 6418be13ee9..761fc6477d6 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -5,14 +5,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Continuous Integration and Deployment Admin settings **(CORE ONLY)**
+# Continuous Integration and Deployment Admin settings **(FREE SELF)**
 
 In this area, you will find settings for Auto DevOps, runners, and job artifacts.
 You can find it in the **Admin Area > Settings > CI/CD**.
 
 ![Admin Area settings button](../img/admin_area_settings_button.png)
 
-## Auto DevOps **(CORE ONLY)**
+## Auto DevOps **(FREE SELF)**
 
 To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md)
 for all projects:
@@ -29,7 +29,7 @@ From now on, every existing project and newly created ones that don't have a
 If you want to disable it for a specific project, you can do so in
 [its settings](../../../topics/autodevops/index.md#enablingdisabling-auto-devops).
 
-## Maximum artifacts size **(CORE ONLY)**
+## Maximum artifacts size **(FREE SELF)**
 
 The maximum size of the [job artifacts](../../../administration/job_artifacts.md)
 can be set at:
@@ -65,7 +65,7 @@ To change it at the:
 NOTE:
 The setting at all levels is only available to GitLab administrators.
 
-## Default artifacts expiration **(CORE ONLY)**
+## Default artifacts expiration **(FREE SELF)**
 
 The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)
 can be set in the Admin Area of your GitLab instance. The syntax of duration is
@@ -86,9 +86,28 @@ be updated for artifacts created before this setting was changed.
 The administrator may need to manually search for and expire previously-created
 artifacts, as described in the [troubleshooting documentation](../../../administration/troubleshooting/gitlab_rails_cheat_sheet.md#remove-artifacts-more-than-a-week-old).
 
-## Shared runners pipeline minutes quota **(STARTER ONLY)**
+## Keep the latest artifacts for all jobs in the latest successful pipelines **(CORE ONLY)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1078) in GitLab Starter 8.16.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50889) in GitLab Core 13.9.
+
+When enabled (default), the artifacts for the most recent pipeline for a ref are
+locked against deletion and kept regardless of the expiry time.
+
+When disabled, the latest artifacts for any **new** successful or fixed pipelines
+are allowed to expire.
+
+This setting takes precedence over the [project level setting](../../../ci/pipelines/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
+If disabled at the instance level, you cannot enable this per-project.
+
+When you disable the feature, the latest artifacts do not immediately expire.
+A new pipeline must run before the latest artifacts can expire and be deleted.
+
+NOTE:
+All application settings have a [customizable cache expiry interval](../../../administration/application_settings_cache.md) which can delay the settings affect.
+
+## Shared runners pipeline minutes quota **(PREMIUM SELF)**
+
+> [Moved](https://about.gitlab.com/blog/2021/01/26/new-gitlab-product-subscription-model/) to GitLab Premium in 13.9.
 
 If you have enabled shared runners for your GitLab instance, you can limit their
 usage by setting a maximum number of pipeline minutes that a group can use on
@@ -126,7 +145,7 @@ a group in the **Usage Quotas** page available to the group page settings list.
 
 ![Group pipelines quota](img/group_pipelines_quota.png)
 
-## Archive jobs **(CORE ONLY)**
+## Archive jobs **(FREE SELF)**
 
 Archiving jobs is useful for reducing the CI/CD footprint on the system by
 removing some of the capabilities of the jobs (metadata needed to run the job),
@@ -156,21 +175,9 @@ Area of your GitLab instance (`.gitlab-ci.yml` if not set):
 1. Input the new path in the **Default CI configuration path** field.
 1. Hit **Save changes** for the changes to take effect.
 
-It is also possible to specify a [custom CI configuration path for a specific project](../../../ci/pipelines/settings.md#custom-ci-configuration-path).
+It is also possible to specify a [custom CI/CD configuration path for a specific project](../../../ci/pipelines/settings.md#custom-cicd-configuration-path).
 
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
-
-## Required pipeline configuration **(PREMIUM ONLY)**
+## Required pipeline configuration **(PREMIUM SELF)**
 
 WARNING:
 This feature is being re-evaluated in favor of a different
@@ -204,18 +211,18 @@ To set required pipeline configuration:
 
 ## Package Registry configuration
 
-### NPM Forwarding **(PREMIUM ONLY)**
+### npm Forwarding **(PREMIUM SELF)**
 
-GitLab administrators can disable the forwarding of NPM requests to [npmjs.com](https://www.npmjs.com/).
+GitLab administrators can disable the forwarding of npm requests to [npmjs.com](https://www.npmjs.com/).
 
 To disable it:
 
 1. Go to **Admin Area > Settings > CI/CD**.
 1. Expand the **Package Registry** section.
-1. Uncheck **Enable forwarding of NPM package requests to npmjs.org**.
+1. Uncheck **Enable forwarding of npm package requests to npmjs.org**.
 1. Click **Save changes**.
 
-![NPM package requests forwarding](img/admin_package_registry_npm_package_requests_forward.png)
+![npm package requests forwarding](img/admin_package_registry_npm_package_requests_forward.png)
 
 ### Package file size limits
 
@@ -228,3 +235,14 @@ To set the maximum file size:
 1. Find the package type you would like to adjust.
 1. Enter the maximum file size, in bytes.
 1. Click **Save size limits**.
+
+## Troubleshooting
+
+### 413 Request Entity Too Large
+
+When build jobs fail with the following error,
+increase the [maximum artifacts size](#maximum-artifacts-size).
+
+```plaintext
+Uploading artifacts as "archive" to coordinator... too large archive <job-id> responseStatus=413 Request Entity Too Large status=413" at end of a build job on pipeline when trying to store artifacts to <object-storage>.
+```
diff --git a/doc/user/admin_area/settings/email.md b/doc/user/admin_area/settings/email.md
index 4ebfac57715..2eaff417ba3 100644
--- a/doc/user/admin_area/settings/email.md
+++ b/doc/user/admin_area/settings/email.md
@@ -5,7 +5,7 @@ group: Project Management
 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
 ---
 
-# Email **(CORE ONLY)**
+# Email **(FREE SELF)**
 
 You can customize some of the content in emails sent from your GitLab instance.
 
@@ -13,7 +13,7 @@ You can customize some of the content in emails sent from your GitLab instance.
 
 The logo in the header of some emails can be customized, see the [logo customization section](../appearance.md#navigation-bar).
 
-## Custom additional text **(PREMIUM ONLY)**
+## Custom additional text **(PREMIUM SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/5031) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
 
@@ -40,7 +40,7 @@ In order to change this option:
 1. Select **Save changes**.
 
 NOTE:
-Once the hostname gets configured, every private commit email using the previous hostname, will not get
+After the hostname gets configured, every private commit email using the previous hostname is not
 recognized by GitLab. This can directly conflict with certain [Push rules](../../../push_rules/push_rules.md) such as
 `Check whether author is a GitLab user` and `Check whether committer is the current authenticated user`.
 
diff --git a/doc/user/admin_area/settings/external_authorization.md b/doc/user/admin_area/settings/external_authorization.md
index 18ae7e6f05a..0975b93f98f 100644
--- a/doc/user/admin_area/settings/external_authorization.md
+++ b/doc/user/admin_area/settings/external_authorization.md
@@ -5,10 +5,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# External authorization control **(CORE ONLY)**
+# External authorization control **(FREE SELF)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4216) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.6.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27056) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.10.
+> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27056) to GitLab Free in 11.10.
 
 In highly controlled environments, it may be necessary for access policy to be
 controlled by an external service that permits access based on project
diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md
index d196dc1730e..3570634b9ba 100644
--- a/doc/user/admin_area/settings/gitaly_timeouts.md
+++ b/doc/user/admin_area/settings/gitaly_timeouts.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Gitaly timeouts **(CORE ONLY)**
+# Gitaly timeouts **(FREE SELF)**
 
 [Gitaly](../../../administration/gitaly/index.md) timeouts are configurable. The timeouts can be
 configured to make sure that long running Gitaly calls don't needlessly take up resources.
diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md
index 9a661fa9716..3377b1674db 100644
--- a/doc/user/admin_area/settings/index.md
+++ b/doc/user/admin_area/settings/index.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: index
 ---
 
-# Admin Area settings **(CORE ONLY)**
+# Admin Area settings **(FREE SELF)**
 
 As an administrator of a GitLab self-managed instance, you can manage the behavior of your deployment. To do so, select **Admin Area > Settings**.
 
@@ -36,7 +36,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | [Elasticsearch](../../../integration/elasticsearch.md#enabling-advanced-search) | Elasticsearch integration. Elasticsearch AWS IAM. |
 | [Kroki](../../../administration/integration/kroki.md#enable-kroki-in-gitlab) | Allow rendering of diagrams in AsciiDoc and Markdown documents using [kroki.io](https://kroki.io). |
 | [PlantUML](../../../administration/integration/plantuml.md#gitlab) | Allow rendering of PlantUML diagrams in AsciiDoc and Markdown documents. |
-| [Slack application](../../../user/project/integrations/gitlab_slack_application.md#configuration) **(FREE ONLY)** | Slack integration allows you to interact with GitLab via slash commands in a chat window. This option is only available on GitLab.com, though it may be [available for self-managed instances in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/28164). |
+| [Slack application](../../../user/project/integrations/gitlab_slack_application.md#configuration) **(FREE SAAS)** | Slack integration allows you to interact with GitLab via slash commands in a chat window. This option is only available on GitLab.com, though it may be [available for self-managed instances in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/28164). |
 | [Third party offers](third_party_offers.md) | Control the display of third party offers. |
 | [Snowplow](../../../development/snowplow.md) | Configure the Snowplow integration. |
 | [Google GKE](../../project/clusters/add_gke_clusters.md) | Google GKE integration allows you to provision GKE clusters from GitLab. |
@@ -52,7 +52,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | Repository maintenance | ([Repository checks](../../../administration/repository_checks.md) and [Housekeeping](../../../administration/housekeeping.md)). Configure automatic Git checks and housekeeping on repositories. |
 | [Repository static objects](../../../administration/static_objects_external_storage.md) | Serve repository static objects (for example, archives, blobs, ...) from an external storage (for example, a CDN). |
 
-## Templates **(PREMIUM ONLY)**
+## Templates **(PREMIUM SELF)**
 
 | Option | Description |
 | ------ | ----------- |
@@ -64,7 +64,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | Option | Description |
 | ------ | ----------- |
 | [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. |
-| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. |
+| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM SELF)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. |
 | [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using the GitLab Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
 
 ## Reporting
@@ -80,7 +80,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | ------ | ----------- |
 | [Metrics - Prometheus](../../../administration/monitoring/prometheus/gitlab_metrics.md) | Enable and configure Prometheus metrics. |
 | [Metrics - Grafana](../../../administration/monitoring/performance/grafana_configuration.md#integration-with-gitlab-ui) | Enable and configure Grafana. |
-| [Profiling - Performance bar](../../../administration/monitoring/performance/performance_bar.md#enable-the-performance-bar-via-the-admin-panel) | Enable access to the Performance Bar for a given group. |
+| [Profiling - Performance bar](../../../administration/monitoring/performance/performance_bar.md#enable-the-performance-bar-via-the-admin-area) | Enable access to the Performance Bar for a given group. |
 | [Self monitoring](../../../administration/monitoring/gitlab_self_monitoring_project/index.md#creating-the-self-monitoring-project) | Enable or disable instance self monitoring. |
 | [Usage statistics](usage_statistics.md) | Enable or disable version check and usage ping. |
 | [Pseudonymizer data collection](../../../administration/pseudonymizer.md) **(ULTIMATE)** | Enable or disable the Pseudonymizer data collection. |
@@ -94,6 +94,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | [Outbound requests](../../../security/webhooks.md) | Allow requests to the local network from hooks and services. |
 | [Protected Paths](protected_paths.md) | Configure paths to be protected by Rack Attack. |
 | [Incident Management](../../../operations/incident_management/index.md) Limits | Configure limits on the number of inbound alerts able to be sent to a project. |
+| [Notes creation limit](rate_limit_on_notes_creation.md)| Set a rate limit on the note creation requests. |
 
 ## Geo
 
diff --git a/doc/user/admin_area/settings/instance_template_repository.md b/doc/user/admin_area/settings/instance_template_repository.md
index 42fa7fe6f54..7630f0c2fbd 100644
--- a/doc/user/admin_area/settings/instance_template_repository.md
+++ b/doc/user/admin_area/settings/instance_template_repository.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Instance template repository **(PREMIUM ONLY)**
+# Instance template repository **(PREMIUM SELF)** **(FREE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/5986) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
 
@@ -22,10 +22,9 @@ select the project to serve as the custom template repository.
 
 ![File templates in the Admin Area](img/file_template_admin_area.png)
 
-Once a project has been selected, you can add custom templates to the repository,
-and they will appear in the appropriate places in the
-[frontend](../../project/repository/web_editor.md#template-dropdowns) and
-[API](../../../api/settings.md).
+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)
+and through the [API settings](../../../api/settings.md).
 
 Templates must be added to a specific subdirectory in the repository,
 corresponding to the kind of template. The following types of custom templates
@@ -61,9 +60,7 @@ extension and not be empty. So, the hierarchy should look like this:
     |-- another_metrics-dashboard.yml
 ```
 
-Once this is established, the list of custom templates will be included when
-creating a new file and the template type is selected. These will appear at the
-top of the list.
+Your custom templates will be 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)
 
diff --git a/doc/user/admin_area/settings/project_integration_management.md b/doc/user/admin_area/settings/project_integration_management.md
index adb192f5b4a..18491f92650 100644
--- a/doc/user/admin_area/settings/project_integration_management.md
+++ b/doc/user/admin_area/settings/project_integration_management.md
@@ -17,7 +17,7 @@ for all projects that didn't have it already enabled.
 
 Only the complete settings for an integration can be inherited. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137).
 
-## Manage instance-level default settings for a project integration **(CORE ONLY)**
+## Manage instance-level default settings for a project integration **(FREE SELF)**
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2137) in GitLab 13.3 for project-level integrations.
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6 for group-level integrations.
diff --git a/doc/user/admin_area/settings/protected_paths.md b/doc/user/admin_area/settings/protected_paths.md
index a03156511e2..061e9fa05d3 100644
--- a/doc/user/admin_area/settings/protected_paths.md
+++ b/doc/user/admin_area/settings/protected_paths.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Protected paths **(CORE ONLY)**
+# Protected paths **(FREE SELF)**
 
 Rate limiting is a common technique used to improve the security and durability
 of a web application. For more details, see
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 484bb7b0a14..1d6424face0 100644
--- a/doc/user/admin_area/settings/push_event_activities_limit.md
+++ b/doc/user/admin_area/settings/push_event_activities_limit.md
@@ -5,21 +5,21 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Push event activities limit and bulk push events
+# Push event activities limit and bulk push events **(FREE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31007) in GitLab 12.4.
 
-This allows you to set the number of changes (branches or tags) in a single push
-to determine whether individual push events or bulk push event will be created.
-Bulk push events will be created if it surpasses that value.
+Set the number of branches or tags to limit the number of single push events
+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:
 
 ![Bulk push event](img/bulk_push_event_v12_4.png)
 
-With this feature, when a single push includes a lot of changes (e.g. 1,000
-branches), only 1 bulk push event will be created instead of creating 1,000 push
+With this feature, when a single push includes a lot of changes (for example, 1,000
+branches), only 1 bulk push event is created instead of 1,000 push
 events. This helps in maintaining good system performance and preventing spam on
 the activity feed.
 
diff --git a/doc/user/admin_area/settings/rate_limit_on_notes_creation.md b/doc/user/admin_area/settings/rate_limit_on_notes_creation.md
new file mode 100644
index 00000000000..54b5da35dac
--- /dev/null
+++ b/doc/user/admin_area/settings/rate_limit_on_notes_creation.md
@@ -0,0 +1,32 @@
+---
+type: reference
+stage: Plan
+group: Project Management
+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
+---
+
+# Rate limits on note creation
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53637) in GitLab 13.9.
+
+This setting allows you to rate limit the requests to the note creation endpoint.
+
+To change the note creation rate limit:
+
+1. Go to **Admin Area > Settings > Network**.
+1. Expand the **Notes Rate Limits** section.
+1. Enter the new value.
+1. Select **Save changes**.
+
+This limit is:
+
+- Applied independently per user.
+- Not applied per IP address.
+
+The default value is `300`.
+
+Requests over the rate limit are logged into the `auth.log` file.
+
+For example, if you set a limit of 300, requests using the
+[Projects::NotesController#create](https://gitlab.com/gitlab-org/gitlab/blob/master/app/controllers/projects/notes_controller.rb)
+action exceeding a rate of 300 per minute are blocked. Access to the endpoint is allowed after one minute.
diff --git a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
index 9ffd46e9ba6..a9b23b3dc50 100644
--- a/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
+++ b/doc/user/admin_area/settings/rate_limits_on_raw_endpoints.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Rate limits on raw endpoints **(CORE ONLY)**
+# Rate limits on raw endpoints **(FREE SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30829) in GitLab 12.2.
 
diff --git a/doc/user/admin_area/settings/sign_in_restrictions.md b/doc/user/admin_area/settings/sign_in_restrictions.md
index 92ad8eced95..a34a63f4543 100644
--- a/doc/user/admin_area/settings/sign_in_restrictions.md
+++ b/doc/user/admin_area/settings/sign_in_restrictions.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Sign-in restrictions **(CORE ONLY)**
+# Sign-in restrictions **(FREE SELF)**
 
 You can use **Sign-in restrictions** to customize authentication restrictions for web interfaces as well as Git over HTTP(S).
 
@@ -27,7 +27,7 @@ You can restrict the password authentication for web interface and Git over HTTP
 
 When this feature enabled, all users must use the [two-factor authentication](../../profile/account/two_factor_authentication.md).
 
-Once the two-factor authentication is configured as mandatory, the users are allowed
+After the two-factor authentication is configured as mandatory, users are allowed
 to skip forced configuration of two-factor authentication for the configurable grace
 period in hours.
 
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
index ddd3dbda9cc..0945471b11b 100644
--- a/doc/user/admin_area/settings/sign_up_restrictions.md
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Sign-up restrictions **(CORE ONLY)**
+# Sign-up restrictions **(FREE SELF)**
 
 You can enforce the following restrictions on sign ups:
 
@@ -50,12 +50,10 @@ To enforce confirmation of the email address used for new sign ups:
 1. Go to **Admin Area > Settings > General** and expand **Sign-up restrictions**.
 1. Select the **Enable email restrictions for sign ups** checkbox, then select **Save changes**.
 
-## User cap **(CORE ONLY)**
+## User cap **(FREE SELF)**
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.7.
-> - It's [deployed behind a feature flag](../../feature_flags.md), enabled by default.
-> - It's recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-user-cap). **(CORE ONLY)**
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9.
 
 When the number of billable users reaches the user cap, any user who is added or requests access must be
 [approved](../approving_users.md#approving-a-user) by an administrator before they can start using
@@ -64,29 +62,10 @@ their account.
 If an administrator increases or removes the user cap, the users in pending approval state are
 automatically approved in a background job.
 
-### Enable or disable User cap **(CORE ONLY)**
-
-User cap is under development but ready for production use.
-It is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
-can opt to disable it.
-
-To disable it:
-
-```ruby
-Feature.disable(:admin_new_user_signups_cap)
-```
-
-To enable it:
-
-```ruby
-Feature.enable(:admin_new_user_signups_cap)
-```
-
 ## Soft email confirmation
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47003) in GitLab 12.2.
-> - It's [deployed behind a feature flag](../../..//user/feature_flags.md), disabled by default.
+> - It's [deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
 > - It's enabled on GitLab.com.
 > - It's recommended for production use.
 > - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-soft-email-confirmation).
@@ -94,7 +73,7 @@ Feature.enable(:admin_new_user_signups_cap)
 WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
 
-The soft email confirmation improves the signup experience for new users by allowing
+The soft email confirmation improves the sign-up experience for new users by allowing
 them to sign in without an immediate confirmation when an email confirmation is required.
 GitLab shows the user a reminder to confirm their email address, and the user can't
 create or update pipelines until their email address is confirmed.
diff --git a/doc/user/admin_area/settings/terms.md b/doc/user/admin_area/settings/terms.md
index b6826035116..3e0636ef7ac 100644
--- a/doc/user/admin_area/settings/terms.md
+++ b/doc/user/admin_area/settings/terms.md
@@ -5,9 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Enforce accepting Terms of Service **(CORE ONLY)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18570) in [GitLab Core](https://about.gitlab.com/pricing/) 10.8.
+# Enforce accepting Terms of Service **(FREE SELF)**
 
 An admin can enforce acceptance of a terms of service and privacy policy. When this option is enabled, new and existing users must accept the terms.
 
diff --git a/doc/user/admin_area/settings/third_party_offers.md b/doc/user/admin_area/settings/third_party_offers.md
index 84511339842..59845a8d0d8 100644
--- a/doc/user/admin_area/settings/third_party_offers.md
+++ b/doc/user/admin_area/settings/third_party_offers.md
@@ -5,9 +5,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Third party offers **(CORE ONLY)**
+# Third party offers **(FREE SELF)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20379) in [GitLab Core](https://about.gitlab.com/pricing/) 11.1.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20379) in GitLab Free 11.1.
 
 Within GitLab, we inform users of available third-party offers they might find valuable in order
 to enhance the development of their projects. An example is the Google Cloud Platform free credit
diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md
index 06b39d67228..2bb6adbc32b 100644
--- a/doc/user/admin_area/settings/usage_statistics.md
+++ b/doc/user/admin_area/settings/usage_statistics.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Usage statistics **(CORE ONLY)**
+# Usage statistics **(FREE SELF)**
 
 GitLab Inc. periodically collects information about your instance in order
 to perform various actions.
@@ -20,7 +20,7 @@ usage statistics to GitLab Inc.
 
 If your GitLab instance is behind a proxy, set the appropriate [proxy configuration variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html).
 
-## Version Check **(CORE ONLY)**
+## Version Check **(FREE SELF)**
 
 If enabled, version check informs you if a new version is available and the
 importance of it through a status. This is shown on the help page (i.e. `/help`)
@@ -59,7 +59,7 @@ sequenceDiagram
     Version Application->>GitLab instance: Response (PNG/SVG)
 ```
 
-## Usage Ping **(CORE ONLY)**
+## Usage Ping **(FREE SELF)**
 
 See [Usage Ping guide](../../../development/usage_ping.md).
 
diff --git a/doc/user/admin_area/settings/user_and_ip_rate_limits.md b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
index e2040ef19d6..ba4ef890caa 100644
--- a/doc/user/admin_area/settings/user_and_ip_rate_limits.md
+++ b/doc/user/admin_area/settings/user_and_ip_rate_limits.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# User and IP rate limits **(CORE ONLY)**
+# User and IP rate limits **(FREE SELF)**
 
 Rate limiting is a common technique used to improve the security and durability
 of a web application. For more details, see
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
index fe1841e7020..0fcdbf3ca90 100644
--- a/doc/user/admin_area/settings/visibility_and_access_controls.md
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -5,22 +5,22 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Visibility and access controls **(CORE ONLY)**
+# Visibility and access controls **(FREE SELF)**
 
 GitLab allows administrators to enforce specific controls.
 
 To access the visibility and access control options:
 
-1. Log in to GitLab as an admin.
+1. Sign in to GitLab as a user with Administrator [permissions](../../permissions.md).
 1. Go to **Admin Area > Settings > General**.
 1. Expand the **Visibility and access controls** section.
 
 ## Default branch protection
 
 This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
-branches. In this case _Default_ refers to a repository's default branch, which in most cases is _master_.
+branches. In this case _Default_ refers to a repository's default branch, which in most cases is `master`.
 
-This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md).
+This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [protected branches](../../project/protected_branches.md).
 
 To change the default branch protection:
 
@@ -31,7 +31,7 @@ For more details, see [Protected branches](../../project/protected_branches.md).
 
 To change this setting for a specific group, see [Default branch protection for groups](../../group/index.md#changing-the-default-branch-protection-of-a-group)
 
-### Disable group owners from updating default branch protection **(PREMIUM ONLY)**
+### Disable group owners from updating default branch protection **(PREMIUM SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211944) in GitLab 13.0.
 
@@ -57,30 +57,30 @@ To change the default project creation protection:
 
 For more details, see [Default project-creation level](../../group/index.md#default-project-creation-level).
 
-## Default project deletion protection **(PREMIUM ONLY)**
+## Default project deletion protection **(PREMIUM SELF)**
 
 By default, a project can be deleted by anyone with the **Owner** role, either at the project or
 group level.
 
-To ensure only admin users can delete projects:
+To ensure only Administrator users can delete projects:
 
 1. Check the **Default project deletion protection** checkbox.
 1. Click **Save changes**.
 
-## Default deletion delay **(PREMIUM ONLY)**
+## Default deletion delay **(PREMIUM SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6.
 
-By default, a project marked for deletion will be permanently removed with immediate effect.
-By default, a group marked for deletion will be permanently removed after 7 days.
+By default, a project marked for deletion is permanently removed with immediate effect.
+By default, a group marked for deletion is permanently removed after seven days.
 
 WARNING:
 The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to
 [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
 
-Projects within a group (but not a personal namespace) can be deleted after a delayed period, by [configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
-
-The default period is 7 days, and can be changed. Setting this period to 0 will enable immediate removal
+Projects in a group (but not a personal namespace) can be deleted after a delayed period, by
+[configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
+The default period is seven days, and can be changed. Setting this period to `0` enables immediate removal
 of projects or groups.
 
 To change this period:
@@ -124,10 +124,10 @@ For more details on group visibility, see [Public access](../../../public_access
 
 ## Restricted visibility levels
 
-To set the available visibility levels for projects, snippets, and selected pages:
+To set the restricted visibility levels for projects, snippets, and selected pages:
 
-1. Check the desired visibility levels.
-1. Click **Save changes**.
+1. Select the desired visibility levels to restrict.
+1. Select **Save changes**.
 
 For more details on project visibility, see [Public access](../../../public_access/public_access.md).
 
@@ -149,13 +149,11 @@ For more details, see [Exporting a project and its data](../../../user/project/s
 
 ## Enabled Git access protocols
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4696) in GitLab 8.10.
-
 With GitLab access restrictions, you can select with which protocols users can communicate with
 GitLab.
 
-Disabling an access protocol does not block access to the server itself via those ports. The ports
-used for the protocol, SSH or HTTP(S), will still be accessible. The GitLab restrictions apply at the
+Disabling an access protocol does not block access to the server itself by using those ports. The ports
+used for the protocol, SSH or HTTP(S), are still accessible. The GitLab restrictions apply at the
 application level.
 
 To specify the enabled Git access protocols:
@@ -170,26 +168,26 @@ When both SSH and HTTP(S) are enabled, users can choose either protocol.
 
 When only one protocol is enabled:
 
-- The project page will only show the allowed protocol's URL, with no option to
+- The project page shows only the allowed protocol's URL, with no option to
   change it.
-- A tooltip will be shown when you hover over the URL's protocol, if an action
-  on the user's part is required, e.g. adding an SSH key, or setting a password.
+- A tooltip is shown when you hover over the URL's protocol, if an action
+  on the user's part is required. For example, adding an SSH key or setting a password.
 
 ![Project URL with SSH only access](img/restricted_url.png)
 
-On top of these UI restrictions, GitLab will deny all Git actions on the protocol
+On top of these UI restrictions, GitLab denies all Git actions on the protocol
 not selected.
 
 WARNING:
-Starting with [GitLab 10.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021),
-HTTP(S) protocol will be allowed for Git clone or fetch requests done by GitLab Runner
-from CI/CD jobs, even if _Only SSH_ was selected.
+GitLab versions [10.7 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18021),
+allow the HTTP(S) protocol for Git clone or fetch requests done by GitLab Runner
+from CI/CD jobs, even if **Only SSH** was selected.
 
 ## Custom Git clone URL for HTTP(S)
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18422) in GitLab 12.4.
 
-You can customize project Git clone URLs for HTTP(S). This will affect the clone
+You can customize project Git clone URLs for HTTP(S), which affects the clone
 panel:
 
 ![Clone panel](img/clone_panel_v12_4.png)
@@ -225,10 +223,9 @@ For more details, see [SSH key restrictions](../../../security/ssh_keys_restrict
 
 ## Allow mirrors to be set up for projects
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3586) in GitLab 10.3.
-
-This option is enabled by default. By disabling it, both [pull and push mirroring](../../project/repository/repository_mirroring.md) will no longer
-work in every repository and can only be re-enabled by an admin on a per-project basis.
+This option is enabled by default. By disabling it, both
+[pull and push mirroring](../../project/repository/repository_mirroring.md) no longer
+work in every repository. They can only be re-enabled by an administrator user on a per-project basis.
 
 ![Mirror settings](img/mirror_settings.png)