Add latest changes from gitlab-org/gitlab@master

19 files changed, 157 insertions, 219 deletions

diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index f6e72092a5f..6bf7f5751a6 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -735,11 +735,23 @@ For each Patroni instance on the secondary site:
    ```
 
 1. Reconfigure GitLab for the changes to take effect.
-   This is required to bootstrap PostgreSQL users and settings:
+   This is required to bootstrap PostgreSQL users and settings.
 
-   ```shell
-   gitlab-ctl reconfigure
-   ```
+   - If this is a fresh installation of Patroni:
+
+     ```shell
+     gitlab-ctl reconfigure
+     ```
+
+   - If you are configuring a Patroni standby cluster on a site that previously had a working Patroni cluster:
+
+     ```shell
+     gitlab-ctl stop patroni 
+     rm -rf /var/opt/gitlab/postgresql/data
+     /opt/gitlab/embedded/bin/patronictl -c /var/opt/gitlab/patroni/patroni.yaml remove postgresql-ha
+     gitlab-ctl reconfigure
+     gitlab-ctl start patroni
+     ```
 
 ### Migrating from repmgr to Patroni
 
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index 120d864147a..e8477eaf686 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -6,22 +6,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Puma **(FREE SELF)**
 
-NOTE:
-Starting with GitLab 13.0, Puma
-is the default web server and Unicorn has been
-disabled by default. In GitLab 14.0, Unicorn was removed from the Linux package
-and only Puma is available.
-
 Puma is a simple, fast, multi-threaded, and highly concurrent HTTP 1.1 server for
 Ruby applications. It's the default GitLab web server since GitLab 13.0
 and has replaced Unicorn. From GitLab 14.0, Unicorn is no longer supported.
 
+NOTE:
+Starting with GitLab 13.0, Puma is the default web server and Unicorn has been disabled.
+In GitLab 14.0, Unicorn was removed from the Linux package and only Puma is available.
+
 ## Configure Puma
 
 To configure Puma:
 
 1. Determine suitable Puma worker and thread [settings](../../install/requirements.md#puma-settings).
-1. If you're swithcing from Unicorn, [convert any custom settings to Puma](#convert-unicorn-settings-to-puma).
+1. If you're switching from Unicorn, [convert any custom settings to Puma](#convert-unicorn-settings-to-puma).
 1. For multi-node deployments, configure the load balancer to use the
    [readiness check](../load_balancer.md#readiness-check).
 1. Reconfigure GitLab so the above changes take effect:
@@ -30,7 +28,7 @@ To configure Puma:
    sudo gitlab-ctl reconfigure
    ```
 
-For Helm based deployments, see the
+For Helm-based deployments, see the
 [`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
 
 For more details about the Puma configuration, see the
@@ -38,9 +36,11 @@ For more details about the Puma configuration, see the
 
 ## Puma Worker Killer
 
-By default, the [Puma Worker Killer](https://github.com/schneems/puma_worker_killer) will restart
-a worker if it exceeds a [memory limit](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/cluster/puma_worker_killer_initializer.rb). Additionally, rolling restarts of
-Puma workers are performed every 12 hours.
+By default:
+
+- The [Puma Worker Killer](https://github.com/schneems/puma_worker_killer) restarts a worker if it
+  exceeds a [memory limit](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/cluster/puma_worker_killer_initializer.rb).
+- Rolling restarts of Puma workers are performed every 12 hours.
 
 To change the memory limit setting:
 
@@ -80,20 +80,22 @@ To change the worker timeout:
    sudo gitlab-ctl reconfigure
    ```
 
-## Running in memory-constrained environments
+## Memory-constrained environments
 
-In a memory-constrained environment with less than 4GB of RAM available, consider disabling Puma [Clustered mode](https://github.com/puma/puma#clustered-mode).
+In a memory-constrained environment with less than 4GB of RAM available, consider disabling Puma
+[Clustered mode](https://github.com/puma/puma#clustered-mode).
 
 Configuring Puma by setting the amount of `workers` to `0` could reduce memory usage by hundreds of MB.
 For details on Puma worker and thread settings, see the [Puma requirements](../../install/requirements.md#puma-settings).
 
 Unlike in a Clustered mode, which is set up by default, only a single Puma process would serve the application.
 
-The downside of running Puma with such configuration is the reduced throughput, and it could be considered as a fair tradeoff in a memory-constraint environment.
+The downside of running Puma with such configuration is the reduced throughput, which could be
+considered as a fair tradeoff in a memory-constraint environment.
 
 When running Puma in Single mode, some features are not supported:
 
-- Phased restart will not work: [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300665)
+- Phased restart do not work: [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300665)
 - [Phased restart](https://gitlab.com/gitlab-org/gitlab/-/issues/300665)
 - [Puma Worker Killer](https://gitlab.com/gitlab-org/gitlab/-/issues/300664)
 
@@ -142,7 +144,8 @@ and only Puma is available.
 Puma has a multi-thread architecture which uses less memory than a multi-process
 application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory
 consumption. Most Rails applications requests normally include a proportion of I/O wait time.
-During I/O wait time MRI Ruby will release the GVL (Global VM Lock) to other threads.
+
+During I/O wait time MRI Ruby releases the GVL (Global VM Lock) to other threads.
 Multi-threaded Puma can therefore still serve more requests than a single process.
 
 When switching to Puma, any Unicorn server configuration will _not_ carry over
diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md
index bb5b3a97abf..c706d346146 100644
--- a/doc/ci/merge_request_pipelines/index.md
+++ b/doc/ci/merge_request_pipelines/index.md
@@ -200,7 +200,7 @@ related to using `only/except` above (or, consider moving to `rules`).
 
 In [GitLab 13.7](https://gitlab.com/gitlab-org/gitlab/-/issues/201845) and later,
 you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/README.md#switch-between-branch-pipelines-and-merge-request-pipelines).
-The pipeline switches to merge request pipelines this after a merge request is open on the branch.
+After a merge request is open on the branch, the pipeline switches to a merge request pipeline.
 
 ### Two pipelines created when pushing an invalid CI configuration file
 
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 3d4c2654f83..a98ea4e4c30 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -304,7 +304,6 @@ GitLab documentation should be clear and easy to understand. Avoid unnecessary w
 
 - Be clear, concise, and stick to the goal of the topic.
 - Write in US English with US grammar. (Tested in [`British.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/British.yml).)
-- Use [inclusive language](#inclusive-language).
 - Rewrite to avoid wordiness:
   - there is
   - there are
@@ -385,80 +384,6 @@ references to user interface elements. For example:
 
 - To sign in to product X, enter your credentials, and then select **Log in**.
 
-### Inclusive language
-
-We strive to create documentation that's inclusive. This section includes
-guidance and examples for these categories:
-
-- [Gender-specific wording](#avoid-gender-specific-wording).
-  (Tested in [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml).)
-- [Ableist language](#avoid-ableist-language).
-  (Tested in [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml).)
-- [Cultural sensitivity](#culturally-sensitive-language).
-  (Tested in [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml).)
-
-We write our developer documentation with inclusivity and diversity in mind. This
-page is not an exhaustive reference, but describes some general guidelines and
-examples that illustrate some best practices to follow.
-
-#### Avoid gender-specific wording
-
-When possible, use gender-neutral pronouns. For example, you can use a singular
-[they](https://developers.google.com/style/pronouns#gender-neutral-pronouns) as
-a gender-neutral pronoun.
-
-Avoid the use of gender-specific pronouns, unless referring to a specific person.
-
-<!-- vale gitlab.InclusionGender = NO -->
-
-| Use                               | Avoid                           |
-|-----------------------------------|---------------------------------|
-| People, humanity                  | Mankind                         |
-| GitLab Team Members               | Manpower                        |
-| You can install; They can install | He can install; She can install |
-
-<!-- vale gitlab.InclusionGender = YES -->
-
-If you need to set up [Fake user information](#fake-user-information), use
-diverse or non-gendered names with common surnames.
-
-#### Avoid ableist language
-
-Avoid terms that are also used in negative stereotypes for different groups.
-
-<!-- vale gitlab.InclusionAbleism = NO -->
-
-| Use                    | Avoid                |
-|------------------------|----------------------|
-| Check for completeness | Sanity check         |
-| Uncertain outliers     | Crazy outliers       |
-| Slows the service      | Cripples the service |
-| Placeholder variable   | Dummy variable       |
-| Active/Inactive        | Enabled/Disabled     |
-| On/Off                 | Enabled/Disabled     |
-
-<!-- vale gitlab.InclusionAbleism = YES -->
-
-Credit: [Avoid ableist language](https://developers.google.com/style/inclusive-documentation#ableist-language)
-in the Google Developer Style Guide.
-
-#### Culturally sensitive language
-
-Avoid terms that reflect negative cultural stereotypes and history. In most
-cases, you can replace terms such as `master` and `slave` with terms that are
-more precise and functional, such as `primary` and `secondary`.
-
-<!-- vale gitlab.InclusionCultural = NO -->
-
-| Use                  | Avoid                 |
-|----------------------|-----------------------|
-| Primary / secondary  | Master / slave        |
-| Allowlist / denylist | Blacklist / whitelist |
-
-<!-- vale gitlab.InclusionCultural = YES -->
-
-For more information see the [Internet Draft specification](https://tools.ietf.org/html/draft-knodel-terminology-02).
-
 ### Fake user information
 
 You may need to include user information in entries such as a REST call or user profile.
@@ -1512,25 +1437,6 @@ It renders on the GitLab documentation site as:
 
 To maintain consistency through GitLab documentation, use these styles and terms.
 
-### Merge requests (MRs)
-
-Merge requests allow you to exchange changes you made to source code and
-collaborate with other people on the same project.
-
-- Use lowercase _merge requests_ regardless of whether referring to the feature
-  or individual merge requests.
-
-As noted in the GitLab [Writing Style Guidelines](https://about.gitlab.com/handbook/communication/#writing-style-guidelines),
-if you use the _MR_ acronym, expand it at least once per document page.
-Typically, the first use would be phrased as _merge request (MR)_ with subsequent
-instances being _MR_.
-
-Examples:
-
-- "We prefer GitLab merge requests".
-- "Open a merge request to fix a broken link".
-- "After you open a merge request (MR), submit your MR for review and approval".
-
 ### Describe UI elements
 
 Follow these styles when you're describing user interface elements in an
diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md
index d3cde5e4e9c..cd2ee5b83dd 100644
--- a/doc/development/documentation/styleguide/word_list.md
+++ b/doc/development/documentation/styleguide/word_list.md
@@ -32,6 +32,10 @@ Instead of **and/or**, use or or rewrite the sentence to spell out both options.
 
 Try to avoid extra words when referring to an example or table in a documentation page, but if required, use **following** instead.
 
+## blacklist
+
+Do not use. Another option is **denylist**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+
 ## currently
 
 Do not use when talking about the product or its features. The documentation describes the product as it is today. ([Vale](../testing.md#vale) rule: [`CurrentStatus.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/CurrentStatus.yml))
@@ -43,6 +47,11 @@ to mean someone who is assigned the Developer role. Instead, write it out. "If y
 
 Do not use "Developer permissions." A user who is assigned the Developer role has a set of associated permissions.
 
+## disable
+
+See [the Microsoft style guide](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/d/disable-disabled) for guidance.
+Use **inactive** or **off** instead. ([Vale](../testing.md#vale) rule: [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml))
+
 ## easily
 
 Do not use. If the user doesn't find the process to be these things, we lose their trust.
@@ -51,6 +60,11 @@ Do not use. If the user doesn't find the process to be these things, we lose the
 
 Do not use Latin abbreviations. Use **for example**, **such as**, **for instance**, or **like** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
 
+## enable
+
+See [the Microsoft style guide](https://docs.microsoft.com/en-us/style-guide/a-z-word-list-term-collections/e/enable-enables) for guidance.
+Use **active** or **on** instead. ([Vale](../testing.md#vale) rule: [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml))
+
 ## future tense
 
 When possible, use present tense instead. For example, use `after you execute this command, GitLab displays the result` instead of `after you execute this command, GitLab will display the result`. ([Vale](../testing.md#vale) rule: [`FutureTense.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FutureTense.yml))
@@ -89,6 +103,18 @@ to mean someone who is assigned the Maintainer role. Instead, write it out. "If
 
 Do not use "Maintainer permissions." A user who is assigned the Maintainer role has a set of associated permissions.
 
+## mankind
+
+Do not use. Use **people** or **humanity** instead. ([Vale](../testing.md#vale) rule: [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml))
+
+## manpower
+
+Do not use. Use words like **workforce** or **GitLab team members**. ([Vale](../testing.md#vale) rule: [`InclusionGender.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionGender.yml))
+
+## master
+
+Do not use. Options are **primary** or **main**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+
 ## may, might
 
 **Might** means something has the probability of occurring. **May** gives permission to do something. Consider **can** instead of **may**.
@@ -97,6 +123,10 @@ Do not use "Maintainer permissions." A user who is assigned the Maintainer role
 
 Do not use first-person singular. Use **you**, **we**, or **us** instead. ([Vale](../testing.md#vale) rule: [`FirstPerson.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/FirstPerson.yml))
 
+## merge requests
+
+Lowercase. If you use **MR** as the acronym, spell it out on first use.
+
 ## Owner
 
 When writing about the Owner role, use a capital "O." Do not use the phrase, "if you are an owner"
@@ -127,6 +157,10 @@ Do not use "Reporter permissions." A user who is assigned the Reporter role has
 
 Do not use roles and permissions interchangeably. Each user is assigned a role. Each role includes a set of permissions.
 
+## sanity check
+
+Do not use. Use **check for completeness** instead. ([Vale](../testing.md#vale) rule: [`InclusionAbleism.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionAbleism.yml))
+
 ## scalability
 
 Do not use when talking about increasing GitLab performance for additional users. The words scale or scaling are sometimes acceptable, but references to increasing GitLab performance for additional users should direct readers to the GitLab [reference architectures](../../../administration/reference_architectures/index.md) page.
@@ -139,6 +173,10 @@ Do not use. If the user doesn't find the process to be these things, we lose the
 
 Instead of **and/or**, use **or** or another sensible construction. This rule also applies to other slashes, like **follow/unfollow**. Some exceptions (like **CI/CD**) are allowed.
 
+## slave
+
+Do not use. Another option is **secondary**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+
 ## subgroup
 
 Use instead of `sub-group`.
@@ -147,6 +185,12 @@ Use instead of `sub-group`.
 
 Do not use. Example: `the file that you save` can be `the file you save`.
 
+## they
+
+Avoid the use of gender-specific pronouns, unless referring to a specific person.
+Use a singular [they](https://developers.google.com/style/pronouns#gender-neutral-pronouns) as
+a gender-neutral pronoun.
+
 ## useful
 
 Do not use. If the user doesn't find the process to be these things, we lose their trust.
@@ -159,5 +203,9 @@ Do not use. Use **use** instead. It's more succinct and easier for non-native En
 
 Do not use Latin abbreviations. Use **with**, **through**, or **by using** instead. ([Vale](../testing.md#vale) rule: [`LatinTerms.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/LatinTerms.yml))
 
+## whitelist
+
+Do not use. Another option is **allowlist**. ([Vale](../testing.md#vale) rule: [`InclusionCultural.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/InclusionCultural.yml))
+
 <!-- vale on -->
 <!-- markdownlint-enable -->
diff --git a/doc/development/experiment_guide/gitlab_experiment.md b/doc/development/experiment_guide/gitlab_experiment.md
index 820d1da0080..3c7d60e1f60 100644
--- a/doc/development/experiment_guide/gitlab_experiment.md
+++ b/doc/development/experiment_guide/gitlab_experiment.md
@@ -588,7 +588,7 @@ When there is no experiment data in the `window.gon.experiment` object for the g
 
 NOTE:
 We use the terms "enabled" and "disabled" here, even though it's against our
-[documentation style guide recommendations](../documentation/styleguide/index.md#avoid-ableist-language)
+[documentation style guide recommendations](../documentation/styleguide/word_list.md#enable)
 because these are the terms that the feature flag documentation uses.
 
 You may already be familiar with the concept of feature flags in GitLab, but using
diff --git a/doc/operations/incident_management/alerts.md b/doc/operations/incident_management/alerts.md
index def54d8dae2..7b6391cc76e 100644
--- a/doc/operations/incident_management/alerts.md
+++ b/doc/operations/incident_management/alerts.md
@@ -85,11 +85,10 @@ The **Alert details** tab has two sections. The top section provides a short lis
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217768) in GitLab 13.2.
 
-The **Metrics** tab displays a metrics chart for alerts coming from Prometheus. If the alert originated from any other tool, the **Metrics** tab is empty. To set up alerts for GitLab-managed Prometheus instances, see [Managed Prometheus instances](../metrics/alerts.md#managed-prometheus-instances). For externally-managed Prometheus instances, you must configure your alerting
-rules to display a chart in the alert. For information about how to configure
+The **Metrics** tab displays a metrics chart for alerts coming from Prometheus. If the alert originated from any other tool, the **Metrics** tab is empty.
+For externally-managed Prometheus instances, you must configure your alerting rules to display a chart in the alert. For information about how to configure
 your alerting rules, see [Embedding metrics based on alerts in incident issues](../metrics/embed.md#embedding-metrics-based-on-alerts-in-incident-issues). See
-[External Prometheus instances](../metrics/alerts.md#external-prometheus-instances)
-for information about setting up alerts for your self-managed Prometheus
+[External Prometheus instances](../metrics/alerts.md#external-prometheus-instances) for information about setting up alerts for your self-managed Prometheus
 instance.
 
 To view the metrics for an alert:
@@ -201,19 +200,6 @@ add a to-do item:
 
 Select the **To-Do List** **{todo-done}** in the navigation bar to view your current to-do list.
 
-## Link runbooks to alerts
-
-> Runbook URLs [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39315) in GitLab 13.3.
-
-When creating alerts from the metrics dashboard for
-[managed Prometheus instances](../metrics/alerts.md#managed-prometheus-instances),
-you can link a runbook. When the alert triggers, you can access the runbook through
-the [chart context menu](../metrics/dashboards/index.md#chart-context-menu) in the
-upper-right corner of the metrics chart, making it easy for you to locate and access
-the correct runbook:
-
-![Linked Runbook in charts](img/link_runbooks_to_alerts_v13_5.png)
-
 ## View the environment that generated the alert
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/232492) in GitLab 13.5 behind a feature flag, disabled by default.
diff --git a/doc/operations/incident_management/img/link_runbooks_to_alerts_v13_5.png b/doc/operations/incident_management/img/link_runbooks_to_alerts_v13_5.png
deleted file mode 100644
index a63001b4cde..00000000000
--- a/doc/operations/incident_management/img/link_runbooks_to_alerts_v13_5.png
+++ /dev/null
diff --git a/doc/operations/metrics/alerts.md b/doc/operations/metrics/alerts.md
index 16cfb05ad9a..fc0db5f8b2d 100644
--- a/doc/operations/metrics/alerts.md
+++ b/doc/operations/metrics/alerts.md
@@ -9,54 +9,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/42640) to GitLab Free in 12.10.
 
 After [configuring metrics for your CI/CD environment](index.md), you can set up
-alerting for Prometheus metrics depending on the location of your instances, and
+alerting for Prometheus metrics, and
 [trigger actions from alerts](#trigger-actions-from-alerts) to notify
 your team when environment performance falls outside of the boundaries you set.
 
-## Managed Prometheus instances
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6590) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.2 for [custom metrics](index.md#adding-custom-metrics), and GitLab 11.3 for [library metrics](../../user/project/integrations/prometheus_library/index.md).
-
-WARNING:
-Managed Prometheus on Kubernetes is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/327796)
-and scheduled for [removal in GitLab 14.0](https://gitlab.com/groups/gitlab-org/-/epics/4280).
-
-For managed Prometheus instances using auto configuration, you can
-[configure alerts for metrics](index.md#adding-custom-metrics) directly in the
-[metrics dashboard](index.md). To set an alert:
-
-1. In your project, navigate to **Monitor > Metrics**,
-1. Identify the metric you want to create the alert for, and click the
-   **ellipsis** **{ellipsis_v}** icon in the top right corner of the metric.
-1. Choose **Alerts**.
-1. Set threshold and operator.
-1. (Optional) Add a Runbook URL.
-1. Click **Add** to save and activate the alert.
-
-![Adding an alert](img/prometheus_alert.png)
-
-To remove the alert, click back on the alert icon for the desired metric, and click **Delete**.
-
-### Link runbooks to alerts
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39315) in GitLab 13.3.
-> - [Deprecated](https://gitlab.com/groups/gitlab-org/-/epics/5877) in GitLab 13.11.
-> - [Removed](https://gitlab.com/groups/gitlab-org/-/epics/4280) in GitLab 14.0.
-
-WARNING:
-Linking runbooks to alerts through the alerts UI is [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/5877)
-and scheduled for [removal in GitLab 14.0](https://gitlab.com/groups/gitlab-org/-/epics/4280).
-However, you can still add runbooks to your alert payload. They show up in the alert UI when the
-alert is triggered.
-
-When creating alerts from the metrics dashboard for [managed Prometheus instances](#managed-prometheus-instances),
-you can also link a runbook. When the alert triggers, the
-[chart context menu](dashboards/index.md#chart-context-menu) on the metrics chart
-links to the runbook, making it easy for you to locate and access the correct runbook
-as soon as the alert fires:
-
-![Linked Runbook in charts](img/linked_runbooks_on_charts.png)
-
 ## Prometheus cluster integrations
 
 Alerts are not currently supported for [Prometheus cluster integrations](../../user/clusters/integrations.md).
diff --git a/doc/operations/metrics/dashboards/img/panel_context_menu_v13_3.png b/doc/operations/metrics/dashboards/img/panel_context_menu_v13_3.png
deleted file mode 100644
index 1259917608b..00000000000
--- a/doc/operations/metrics/dashboards/img/panel_context_menu_v13_3.png
+++ /dev/null
diff --git a/doc/operations/metrics/dashboards/img/panel_context_menu_v14_0.png b/doc/operations/metrics/dashboards/img/panel_context_menu_v14_0.png
new file mode 100644
index 00000000000..78cce5d30b7
--- /dev/null
+++ b/doc/operations/metrics/dashboards/img/panel_context_menu_v14_0.png
diff --git a/doc/operations/metrics/dashboards/index.md b/doc/operations/metrics/dashboards/index.md
index d7b748034d5..d59f72f2a91 100644
--- a/doc/operations/metrics/dashboards/index.md
+++ b/doc/operations/metrics/dashboards/index.md
@@ -123,7 +123,7 @@ You can take action related to a chart's data by clicking the
 **{ellipsis_v}** **More actions** dropdown box above the upper right corner of
 any chart on a dashboard:
 
-![Context Menu](img/panel_context_menu_v13_3.png)
+![Context Menu](img/panel_context_menu_v14_0.png)
 
 The options are:
 
@@ -135,10 +135,6 @@ The options are:
   feature, logs narrow down to the selected time range. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/122013) in GitLab 12.8.)
 - **Download CSV** - Data from Prometheus charts on the metrics dashboard can be downloaded as CSV.
 - [Copy link to chart](../embed.md#embedding-gitlab-managed-kubernetes-metrics)
-- **Alerts** - Display any [alerts](../alerts.md) configured for this metric.
-- **View Runbook** - Displays the runbook for an alert. For information about configuring
-  runbooks, read [Set up alerts for Prometheus metrics](../alerts.md).
-  ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211844) in GitLab 13.3.)
 
 ### Timeline zoom and URL sharing
 
diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md
index e8ae80d1de1..2036a15d77e 100644
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@@ -103,7 +103,8 @@ To enable or disable Auto DevOps at the group level:
 Even when disabled at the instance level, group owners and project maintainers
 can still enable Auto DevOps at the group and project level, respectively.
 
-1. As an administrator, go to **Admin Area > Settings > CI/CD > Continuous Integration and Deployment**.
+1. As an administrator, on the top bar, select **Menu >** **{admin}** **Admin**.
+1. Go to **Settings > CI/CD > Continuous Integration and Deployment**.
 1. Select **Default to Auto DevOps pipeline for all projects** to enable it.
 1. (Optional) You can set up the Auto DevOps [base domain](#auto-devops-base-domain),
    for Auto Deploy and Auto Review Apps to use.
@@ -222,13 +223,13 @@ The Auto DevOps base domain is required to use
 [Auto Monitoring](stages.md#auto-monitoring). You can define the base domain in
 any of the following places:
 
-- either under the cluster's settings, whether for an instance,
+- Either under the cluster's settings, whether for an instance,
   [projects](../../user/project/clusters/index.md#base-domain) or
   [groups](../../user/group/clusters/index.md#base-domain)
-- or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
-- or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
-- or as an instance-wide fallback in **Admin Area > Settings > CI/CD** under the
-  **Continuous Integration and Delivery** section
+- Or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
+- Or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
+- Or as an instance-wide fallback in **Menu >** **{admin}** **Admin >**
+  **Settings > CI/CD** under the **Continuous Integration and Delivery** section.
 
 The base domain variable `KUBE_INGRESS_BASE_DOMAIN` follows the same order of precedence
 as other environment [variables](../../ci/variables/README.md#cicd-variable-precedence).
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 675d01373d4..9f057982a11 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -743,7 +743,7 @@ DAST can be [configured](#customizing-the-dast-settings) using CI/CD variables.
 | `DAST_SUBMIT_FIELD`                         | selector      | A selector describing the element that when clicked submits the login form, or the password form of a multi-page login process. Example: `xpath://input[@value='Login']`. [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9894) in GitLab 12.4. |
 | `DAST_FIRST_SUBMIT_FIELD`                   | selector      | A selector describing the element that when clicked submits the username form of a multi-page login process. Example: `.submit`. [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/9894) in GitLab 12.4. |
 | `DAST_ZAP_CLI_OPTIONS`                      | string        | ZAP server command-line options. For example, `-Xmx3072m` would set the Java maximum memory allocation pool size. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12652) in GitLab 13.1. |
-| `DAST_ZAP_LOG_CONFIGURATION`                | string        | Set to a semicolon-separated list of additional log4j properties for the ZAP Server. For example, `log4j.logger.org.parosproxy.paros.network.HttpSender=DEBUG;log4j.logger.com.crawljax=DEBUG` |
+| `DAST_ZAP_LOG_CONFIGURATION`                | string        | Set to a semicolon-separated list of additional log4j properties for the ZAP Server. |
 | `DAST_AGGREGATE_VULNERABILITIES`            | boolean       | Vulnerability aggregation is set to `true` by default. To disable this feature and see each vulnerability individually set to `false`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/254043) in GitLab 14.0. |
 | `DAST_MAX_URLS_PER_VULNERABILITY`           | number        | The maximum number of URLs reported for a single vulnerability. `DAST_MAX_URLS_PER_VULNERABILITY` is set to `50` by default. To list all the URLs set to `0`. [Introduced](https://gitlab.com/gitlab-org/security-products/dast/-/merge_requests/433) in GitLab 13.12. |
 | `DAST_AUTH_REPORT`                  | boolean       | Used in combination with exporting the `gl-dast-debug-auth-report.html` artifact to aid in debugging authentication issues. |
@@ -880,6 +880,8 @@ Debug mode of the ZAP server can be enabled using the `DAST_ZAP_LOG_CONFIGURATIO
 The following table outlines examples of values that can be set and the effect that they have on the output that is logged.
 Multiple values can be specified, separated by semicolons.
 
+For example, `log4j.logger.org.parosproxy.paros.network.HttpSender=DEBUG;log4j.logger.com.crawljax=DEBUG`.
+
 | Log configuration value                                      | Effect                                                            |
 |--------------------------------------------------            | ----------------------------------------------------------------- |
 | `log4j.rootLogger=DEBUG`                                     | Enable all debug logging statements.                              |
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index 435ca8f76c5..def0847486b 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -45,12 +45,11 @@ To use a cluster management project for a cluster:
 To select a cluster management project to use:
 
 1. Navigate to the appropriate configuration page. For a:
-   - [Project-level cluster](../project/clusters/index.md), navigate to your project's
+   - [Project-level cluster](../project/clusters/index.md), go to your project's
      **Infrastructure > Kubernetes clusters** page.
-   - [Group-level cluster](../group/clusters/index.md), navigate to your group's **Kubernetes**
-     page.
-   - [Instance-level cluster](../instance/clusters/index.md), navigate to Admin Area's **Kubernetes**
+   - [Group-level cluster](../group/clusters/index.md), go to your group's **Kubernetes**
      page.
+   - [Instance-level cluster](../instance/clusters/index.md), go to **Menu >** **{admin}** **Admin > Kubernetes** page.
 1. Select the project using **Cluster management project field** in the **Advanced settings**
    section.
 
diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md
index cf57afb8324..86a87e5be32 100644
--- a/doc/user/discussions/index.md
+++ b/doc/user/discussions/index.md
@@ -10,32 +10,46 @@ type: reference, howto
 GitLab encourages communication through comments, threads, and
 [code suggestions](../project/merge_requests/reviews/suggestions.md).
 
-For example, you can create a comment in the following places:
+There are two types of comments:
 
-- Issues
+- A standard comment.
+- A comment in a thread, which has to be resolved.
+
+In a comment, you can enter [Markdown](../markdown.md) and use [quick actions](../project/quick_actions.md).
+
+You can [suggest code changes](../project/merge_requests/reviews/suggestions.md) in your commit diff comment,
+which the user can accept through the user interface.
+
+## Where you can create comments
+
+You can create comments in places like:
+
+- Commit diffs
+- Commits
+- Designs
 - Epics
+- Issues
 - Merge requests
 - Snippets
-- Commits
-- Commit diffs
 
-There are standard comments, and you also have the option to create a comment
-in the form of a thread. A comment can also be [turned into a thread](#start-a-thread-by-replying-to-a-standard-comment)
-when it receives a reply.
+Each object can have as many as 5,000 comments.
 
-The comment area supports [Markdown](../markdown.md) and [quick actions](../project/quick_actions.md).
-You can [suggest code changes](../project/merge_requests/reviews/suggestions.md) in your comment,
-which the user can accept through the user interface. You can edit your own
-comment at any time, and anyone with the [Maintainer role](../permissions.md) or
-higher can also edit a comment made by someone else.
+## Reply to a comment by sending email
 
-You can also reply to a comment notification email to reply to the comment if
-[Reply by email](../../administration/reply_by_email.md) is configured for your GitLab instance. Replying to a standard comment
-creates another standard comment. Replying to a threaded comment creates a reply in the thread. Email replies support
-[Markdown](../markdown.md) and [quick actions](../project/quick_actions.md), just as if you replied from the web.
+If you have ["reply by email"](../../administration/reply_by_email.md) configured,
+you can reply to comments by sending an email. 
 
-NOTE:
-There is a limit of 5,000 comments for every object, for example: issue, epic, and merge request.
+- When you reply to a standard comment, another standard comment is created.
+- When you reply to a threaded comment, it creates a reply in the thread.
+
+You can use [Markdown](../markdown.md) and [quick actions](../project/quick_actions.md) in your email replies.
+
+## Who can edit comments
+
+You can edit your own comment at any time.
+
+Anyone with the [Maintainer role](../permissions.md) or
+higher can also edit a comment made by someone else.
 
 ## Resolvable comments and threads
 
diff --git a/doc/user/group/contribution_analytics/index.md b/doc/user/group/contribution_analytics/index.md
index 12d7eaf2f12..670ecc48370 100644
--- a/doc/user/group/contribution_analytics/index.md
+++ b/doc/user/group/contribution_analytics/index.md
@@ -8,12 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3090) in GitLab 12.2 for subgroups.
 
-With Contribution Analytics you can get an overview of the following activity in your
-group:
-
-- Issues
-- Merge requests
-- Push events
+With Contribution Analytics you can get an overview of the [contribution actions](../../../api/events.md#action-types) in your
+group.
 
 To view the Contribution Analytics, go to your group and select **Analytics > Contribution**.
 
diff --git a/doc/user/packages/nuget_repository/index.md b/doc/user/packages/nuget_repository/index.md
index f19d565ef36..783fc1d4ab0 100644
--- a/doc/user/packages/nuget_repository/index.md
+++ b/doc/user/packages/nuget_repository/index.md
@@ -8,6 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20050) in GitLab Premium 12.8.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/221259) to GitLab Free in 13.3.
+> - Symbol package support [added](https://gitlab.com/gitlab-org/gitlab/-/issues/262081) in GitLab 14.1.
 
 Publish NuGet packages in your project's Package Registry. Then, install the
 packages whenever you need to use them as a dependency.
@@ -394,6 +395,24 @@ dotnet add package <package_id> \
 - `<package_id>` is the package ID.
 - `<package_version>` is the package version. Optional.
 
+## Symbol packages
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/262081) in GitLab 14.1.
+
+If you push a `.nupkg`, symbol package files in the `.snupkg` format are uploaded automatically. You
+can also push them manually:
+
+```shell
+nuget push My.Package.snupkg -Source <source_name>
+```
+
+Consuming symbol packages is not yet guaranteed using clients such as Visual Studio or
+dotnet-symbol. The `.snupkg` files are available for download through the UI or the
+[API](../../../api/packages/nuget.md#download-a-package-file).
+
+Follow the [NuGet symbol package issue](https://gitlab.com/gitlab-org/gitlab/-/issues/262081)
+for further updates.
+
 ## Supported CLI commands
 
 The GitLab NuGet repository supports the following commands for the NuGet CLI (`nuget`) and the .NET
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index 9d714a6efd0..9c2fccfea82 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -98,7 +98,7 @@ To add links to other accounts:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/14078) in GitLab 11.3.
 
-In the user contribution calendar graph and recent activity list, you can show contributions to private projects.
+In the user contribution calendar graph and recent activity list, you can see your [contribution actions](../../api/events.md#action-types) to private projects.
 
 To show private contributions: