Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42

83 files changed, 500 insertions, 2087 deletions

diff --git a/doc/user/project/clusters/img/kubernetes_pod_logs_v12_10.png b/doc/user/project/clusters/img/kubernetes_pod_logs_v12_10.png
deleted file mode 100644
index abac22e3f1f..00000000000
--- a/doc/user/project/clusters/img/kubernetes_pod_logs_v12_10.png
+++ /dev/null
diff --git a/doc/user/project/clusters/img/pod_logs_deploy_board.png b/doc/user/project/clusters/img/pod_logs_deploy_board.png
deleted file mode 100644
index 7f83382968b..00000000000
--- a/doc/user/project/clusters/img/pod_logs_deploy_board.png
+++ /dev/null
diff --git a/doc/user/project/clusters/kubernetes_pod_logs.md b/doc/user/project/clusters/kubernetes_pod_logs.md
index 58006c29057..bd87ab1024d 100644
--- a/doc/user/project/clusters/kubernetes_pod_logs.md
+++ b/doc/user/project/clusters/kubernetes_pod_logs.md
@@ -2,120 +2,11 @@
 stage: Monitor
 group: Respond
 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
+remove_date: '2022-18-10'
+redirect_to: '../../clusters/agent/index.md'
 ---
 
-# Kubernetes Logs (DEPRECATED) **(FREE SELF)**
+# Kubernetes Logs (removed) **(FREE SELF)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/4752) in GitLab 11.0.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26383) from GitLab Ultimate to GitLab Free 12.9.
-> - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/360182) behind a [feature flag](../../../administration/feature_flags.md) named `monitor_logging` in GitLab 15.0. Disabled by default.
-> - [Disabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/353410) in GitLab 15.0.
-
-WARNING:
-This feature is in its end-of-life process.
-This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
-It will be [removed completely](https://gitlab.com/gitlab-org/gitlab/-/issues/346485) in GitLab 15.2.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `monitor_logging` and the one named `certificate_based_clusters`.
-On GitLab.com, this feature is not available.
-This feature is not recommended for production use.
-
-GitLab makes it easy to view the logs of running pods in
-[connected Kubernetes clusters](index.md). By displaying the logs directly in GitLab
-in the **Log Explorer**, developers can avoid managing console tools or jumping
-to a different interface. The **Log Explorer** interface provides a set of filters
-above the log file data, depending on your configuration:
-
-![Pod logs](img/kubernetes_pod_logs_v12_10.png)
-
-- **Namespace** - Select the environment to display. Users with Maintainer or
-  greater [permissions](../../permissions.md) can also see pods in the
-  `gitlab-managed-apps` namespace.
-- **Search** - Only available if the [Elastic Stack integration](../../clusters/integrations.md#elastic-stack-cluster-integration) is enabled.
-- **Select time range** - Select the range of time to display.
-  Only available if the [Elastic Stack integration](../../clusters/integrations.md#elastic-stack-cluster-integration) is enabled.
-- **Scroll to bottom** **{scroll_down}** - Scroll to the end of the displayed logs.
-- **Refresh** **{retry}** - Reload the displayed logs.
-
-<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-To learn more about the Log Explorer, see [APM - Log Explorer](https://www.youtube.com/watch?v=hWclZHA7Dgw).
-
-[Learn more about Kubernetes + GitLab](https://about.gitlab.com/solutions/kubernetes/).
-Everything you need to build, test, deploy, and run your application at scale.
-
-## Requirements
-
-[Deploying to a Kubernetes environment](../deploy_boards.md#enabling-deploy-boards)
-is required to use Logs.
-
-## Accessing the log explorer
-
-To access the **Log explorer**, select the **More actions** **{ellipsis_v}** menu on
-a [metrics dashboard](../../../operations/metrics/index.md) and select **View logs**, or:
-
-1. Sign in as a user with the _View pod logs_
-   [permissions](../../permissions.md#project-members-permissions) in the project.
-1. To navigate to the **Log Explorer** from the sidebar menu, go to **Monitor > Logs**
-   ([Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) in GitLab 12.5.).
-1. To navigate to the **Log Explorer** from a specific pod on a [deploy board](../deploy_boards.md):
-
-   1. Go to **Deployments > Environments** and find the environment
-      which contains the desired pod, like `production`.
-   1. On the **Environments** page, you should see the status of the environment's
-      pods with [deploy boards](../deploy_boards.md).
-   1. When mousing over the list of pods, GitLab displays a tooltip with the exact pod name
-      and status.
-      ![deploy boards pod list](img/pod_logs_deploy_board.png)
-   1. Select the desired pod to display the **Log Explorer**.
-
-### Logs view
-
-The **Log Explorer** lets you filter the logs by:
-
-- Pods.
-- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/5769), environments.
-- [From GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21656),
-  [full text search](#full-text-search).
-- [From GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/197879), dates.
-- [From GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/208790), managed apps.
-
-Loading more than 500 log lines is possible from
-[GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/198050) onward.
-
-Support for pods with multiple containers is coming
-[in a future release](https://gitlab.com/gitlab-org/gitlab/-/issues/13404).
-
-Support for historical data is coming
-[in a future release](https://gitlab.com/gitlab-org/gitlab/-/issues/196191).
-
-### Filter by date
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/197879) in GitLab 12.8.
-
-When you enable [Elastic Stack](../../clusters/integrations.md#elastic-stack-cluster-integration)
-on your cluster, you can filter logs displayed in the **Log Explorer** by date.
-
-Select **Show last** in the **Log Explorer** to see the available options.
-
-### Full text search
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21656) in GitLab 12.7.
-
-When you enable [Elastic Stack](../../clusters/integrations.md#elastic-stack-cluster-integration) on your cluster,
-you can search the content of your logs through a search bar. The search is passed
-to Elasticsearch using the
-[simple_query_string](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-simple-query-string-query.html)
-Elasticsearch function, which supports the following operators:
-
-| Operator                   | Description                                                 |
-|----------------------------|-------------------------------------------------------------|
-|  `\|`                      | An `OR` operation.                                          |
-| `-`                        | Negates a single token.                                     |
-| `+`                        | An `AND` operation.                                         |
-| `"`                        | Wraps a number of tokens to signify a phrase for searching. |
-| `*` (at the end of a term) | A prefix query.                                             |
-| `(` and `)`                | Precedence.                                                 |
-| `~N` (after a word)        | Edit distance (fuzziness).                                  |
-| `~N` (after a phrase)      | Slop amount.                                                |
+This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5
+and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/360193) in GitLab 15.2.
diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md
index 197a995952a..adea5dad7b8 100644
--- a/doc/user/project/code_owners.md
+++ b/doc/user/project/code_owners.md
@@ -85,6 +85,12 @@ Inviting **Subgroup Y** to a parent group of **Project A**
 [is not supported](https://gitlab.com/gitlab-org/gitlab/-/issues/288851). To set **Subgroup Y** as
 Code Owners, add this group directly to the project itself.
 
+NOTE:
+For approval to be required, groups as Code Owners must have a direct membership
+(not inherited membership) in the project. Approval can only be optional for groups
+that inherit membership. Members in the Code Owners group also must be direct members,
+and not inherit membership from any parent groups.
+
 ### Add a group as a Code Owner
 
 To set a group as a Code Owner:
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index 8f1da4b278a..c64afd95d8d 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -82,7 +82,7 @@ Prerequisites:
 A project deploy key is enabled when it is created. You can modify only a project deploy key's
 name and permissions.
 
-## Create a public deploy key
+## Create a public deploy key **(FREE SELF)**
 
 Prerequisites:
 
diff --git a/doc/user/project/highlighting.md b/doc/user/project/highlighting.md
index 37ec7c8e8d3..1d62cd00b31 100644
--- a/doc/user/project/highlighting.md
+++ b/doc/user/project/highlighting.md
@@ -7,7 +7,7 @@ type: reference
 
 # Syntax Highlighting **(FREE)**
 
-GitLab provides syntax highlighting on all files through the
+GitLab provides syntax highlighting on all files through [Highlight.js](https://github.com/highlightjs/highlight.js/) and the
 [Rouge](https://rubygems.org/gems/rouge) Ruby gem. It attempts to guess what language
 to use based on the file extension, which most of the time is sufficient.
 
diff --git a/doc/user/project/img/labels_drag_priority_v12_1.gif b/doc/user/project/img/labels_drag_priority_v12_1.gif
deleted file mode 100644
index a568490da5f..00000000000
--- a/doc/user/project/img/labels_drag_priority_v12_1.gif
+++ /dev/null
diff --git a/doc/user/project/img/time_tracking_report_v15_1.png b/doc/user/project/img/time_tracking_report_v15_1.png
index a9ddefebb2f..4eeccf8a684 100644
--- a/doc/user/project/img/time_tracking_report_v15_1.png
+++ b/doc/user/project/img/time_tracking_report_v15_1.png
diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md
index b2425686024..dff5a602e8a 100644
--- a/doc/user/project/import/bitbucket.md
+++ b/doc/user/project/import/bitbucket.md
@@ -58,7 +58,7 @@ For user contributions to be mapped, each user must complete the following befor
    If they don't match, modify the public name in the Atlassian account settings to match the
    username in the Bitbucket account settings.
 
-1. Connect your Bitbucket account in [GitLab profile social sign-in](https://gitlab.com/-/profile/account).
+1. Connect your Bitbucket account in [GitLab profile service sign-in](https://gitlab.com/-/profile/account).
 
 1. [Set your public email](../../profile/index.md#set-your-public-email).
 
@@ -97,16 +97,16 @@ If you've accidentally started the import process with the wrong account, follow
 the username in the Bitbucket account settings must match the public name in the Atlassian account
 settings. If these names match but user mapping still fails, the user may have modified their
 Bitbucket username after connecting their Bitbucket account in the
-[GitLab profile social sign-in](https://gitlab.com/-/profile/account).
+[GitLab profile service sign-in](https://gitlab.com/-/profile/account).
 
 To fix this, the user must verify that their Bitbucket external UID in the GitLab database matches their
 current Bitbucket public name, and reconnect if there's a mismatch:
 
-1. [Use the API to get the currently authenticated user](../../../api/users.md#list-current-user-for-normal-users).
+1. [Use the API to get the currently authenticated user](../../../api/users.md#for-normal-users-1).
 
 1. In the API's response, the `identities` attribute contains the Bitbucket account that exists in
    the GitLab database. If the `extern_uid` doesn't match the current Bitbucket public name, the
-   user should reconnect their Bitbucket account in the [GitLab profile social sign-in](https://gitlab.com/-/profile/account).
+   user should reconnect their Bitbucket account in the [GitLab profile service sign-in](https://gitlab.com/-/profile/account).
 
 1. Following reconnection, the user should use the API again to verify that their `extern_uid` in
    the GitLab database now matches their current Bitbucket public name.
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index 60a4ca5c0ea..e4ae0c4b29b 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -150,7 +150,7 @@ There are numerous [APIs](../../api/index.md) to use with your projects:
 - [Traffic](../../api/project_statistics.md)
 - [Variables](../../api/project_level_variables.md)
 - [Aliases](../../api/project_aliases.md)
-- [DORA4 Analytics](../../api/dora4_project_analytics.md)
+- [DORA4 Analytics](../../api/dora/metrics.md)
 
 ## DORA4 analytics overview
 
@@ -158,4 +158,4 @@ Project details include the following analytics:
 
 - Deployment Frequency
 
-For more information, see [DORA4 Project Analytics API](../../api/dora4_project_analytics.md).
+For more information, see [DORA4 Project Analytics API](../../api/dora/metrics.md).
diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md
index 22e6d45dd96..75f099268cb 100644
--- a/doc/user/project/integrations/bamboo.md
+++ b/doc/user/project/integrations/bamboo.md
@@ -9,11 +9,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 You can automatically trigger builds in Atlassian Bamboo when you push changes
 to your project in GitLab.
 
-When this integration is configured, merge requests also display the following information:
-
-- A CI/CD status that shows if the build is pending, failed, or has completed successfully.
-- A link to the Bamboo build page for more information.
-
 Bamboo doesn't provide the same features as a traditional build system when
 accepting webhooks and commit data. You must configure a Bamboo
 build plan before you configure the integration in GitLab.
@@ -66,6 +61,65 @@ for example `PROJ-PLAN`.
 The build key is included in the browser URL when you view a plan in
 Bamboo. For example, `https://bamboo.example.com/browse/PROJ-PLAN`.
 
+## Update Bamboo build status in GitLab
+
+You can use a script that uses the [commit status API](../../../api/commits.md#post-the-build-status-to-a-commit)
+and Bamboo build variables to:
+
+- Update the commit with the build status.
+- Add the Bamboo build plan URL as the commit's `target_url`.
+
+For example:
+
+1. Create an [access token](../../../api/index.md#personalprojectgroup-access-tokens) in GitLab with `:api` permissions.
+1. Save the token as a `$GITLAB_TOKEN` variable in Bamboo.
+1. Add the following script as a final task to the Bamboo plan's jobs:
+
+   ```shell
+   #!/bin/bash
+
+   # Script to update CI status on GitLab.
+   # Add this script as final inline script task in a Bamboo job.
+   #
+   # General documentation: https://docs.gitlab.com/ee/user/project/integrations/bamboo.html
+   # Fix inspired from https://gitlab.com/gitlab-org/gitlab/-/issues/34744
+
+   # Stop at first error
+   set -e
+
+   # Access token. Set this as a CI variable in Bamboo.
+   #GITLAB_TOKEN=
+
+   # Status
+   cistatus="failed"
+   if [ "${bamboo_buildFailed}" = "false" ]; then
+     cistatus="success"
+   fi
+
+   repo_url="${bamboo_planRepository_repositoryUrl}"
+
+   # Check if we use SSH or HTTPS
+   protocol=${repo_url::4}
+   if [ "$protocol" == "git@" ]; then
+     repo=${repo_url:${#protocol}};
+     gitlab_url=${repo%%:*};
+   else
+     protocol="https://"
+     repo=${repo_url:${#protocol}};
+     gitlab_url=${repo%%/*};
+   fi
+
+   start=$((${#gitlab_url} + 1)) # +1 for the / (https) or : (ssh)
+   end=$((${#repo} - $start -4)) # -4 for the .git
+   repo=${repo:$start:$end}
+   repo=$(echo "$repo" | sed "s/\//%2F/g")
+
+   # Send request
+   url="https://${gitlab_url}/api/v4/projects/${repo}/statuses/${bamboo_planRepository_revision}?state=${cistatus}&target_url=${bamboo_buildResultsUrl}"
+   echo "Sending request to $url"
+   curl --fail --request POST --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "$url"
+   ```
+
 ## Troubleshooting
 
 ### Builds not triggered
diff --git a/doc/user/project/integrations/mock_ci.md b/doc/user/project/integrations/mock_ci.md
index 631c53dcc44..5cde17dbd83 100644
--- a/doc/user/project/integrations/mock_ci.md
+++ b/doc/user/project/integrations/mock_ci.md
@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Mock CI Service **(FREE)**
 
-**NB: This service is only listed if you are in a development environment!**
+NOTE:
+This service is only listed if you are in a [development environment](https://gitlab.com/gitlab-org/gitlab-mock-ci-service#setup-mockci-integration)!
 
 To set up the mock CI service server, respond to the following endpoints
 
diff --git a/doc/user/project/integrations/webhook_events.md b/doc/user/project/integrations/webhook_events.md
index ed62a34f6a3..32e5f949c15 100644
--- a/doc/user/project/integrations/webhook_events.md
+++ b/doc/user/project/integrations/webhook_events.md
@@ -824,6 +824,11 @@ The available values for `object_attributes.action` in the payload are:
 - `unapproval`
 - `merge`
 
+The field `object_attributes.oldrev` is only available when there are actual code changes, like:
+
+- New code is pushed.
+- A [suggestion](../merge_requests/reviews/suggestions.md) is applied.
+
 Request header:
 
 ```plaintext
@@ -868,6 +873,7 @@ Payload example:
   },
   "object_attributes": {
     "id": 99,
+    "iid": 1,
     "target_branch": "master",
     "source_branch": "ms-viewport",
     "source_project_id": 14,
@@ -879,10 +885,12 @@ Payload example:
     "milestone_id": null,
     "state": "opened",
     "blocking_discussions_resolved": true,
+    "work_in_progress": false,
+    "first_contribution": true,
     "merge_status": "unchecked",
     "target_project_id": 14,
-    "iid": 1,
     "description": "",
+    "url": "http://example.com/diaspora/merge_requests/1",
     "source": {
       "name":"Awesome Project",
       "description":"Aut reprehenderit ut est.",
@@ -925,8 +933,18 @@ Payload example:
         "email": "gitlabdev@dv6700.(none)"
       }
     },
-    "work_in_progress": false,
-    "url": "http://example.com/diaspora/merge_requests/1",
+    "labels": [{
+      "id": 206,
+      "title": "API",
+      "color": "#ffffff",
+      "project_id": 14,
+      "created_at": "2013-12-03T17:15:43Z",
+      "updated_at": "2013-12-03T17:15:43Z",
+      "template": false,
+      "description": "API related issues",
+      "type": "ProjectLabel",
+      "group_id": 41
+    }],
     "action": "open",
     "assignee": {
       "name": "User1",
@@ -985,6 +1003,9 @@ Payload example:
 }
 ```
 
+NOTE:
+The fields `assignee_id`, and `state` are deprecated.
+
 ## Wiki page events
 
 Wiki page events are triggered when a wiki page is created, updated, or deleted.
@@ -1147,6 +1168,9 @@ Payload example:
          "created_at": "2016-08-12 15:23:28 UTC",
          "started_at": null,
          "finished_at": null,
+         "duration": null,
+         "queued_duration": null,
+         "failure_reason": null,
          "when": "manual",
          "manual": true,
          "allow_failure": false,
@@ -1175,7 +1199,10 @@ Payload example:
          "status": "success",
          "created_at": "2016-08-12 15:23:28 UTC",
          "started_at": "2016-08-12 15:26:12 UTC",
-         "finished_at": null,
+         "finished_at": "2016-08-12 15:26:29 UTC",
+         "duration": 17.0,
+         "queued_duration": 196.0,
+         "failure_reason": null,
          "when": "on_success",
          "manual": false,
          "allow_failure": false,
@@ -1208,10 +1235,13 @@ Payload example:
          "id": 378,
          "stage": "test",
          "name": "test-build",
-         "status": "success",
+         "status": "failed",
          "created_at": "2016-08-12 15:23:28 UTC",
          "started_at": "2016-08-12 15:26:12 UTC",
          "finished_at": "2016-08-12 15:26:29 UTC",
+         "duration": 17.0,
+         "queued_duration": 196.0,
+         "failure_reason": "script_failure",
          "when": "on_success",
          "manual": false,
          "allow_failure": false,
@@ -1247,6 +1277,9 @@ Payload example:
          "created_at": "2016-08-12 15:23:28 UTC",
          "started_at": "2016-08-12 15:24:56 UTC",
          "finished_at": "2016-08-12 15:25:26 UTC",
+         "duration": 17.0,
+         "queued_duration": 196.0,
+         "failure_reason": null,
          "when": "on_success",
          "manual": false,
          "allow_failure": false,
@@ -1282,6 +1315,9 @@ Payload example:
          "created_at": "2016-08-12 15:23:28 UTC",
          "started_at": null,
          "finished_at": null,
+         "duration": null,
+         "queued_duration": null,
+         "failure_reason": null,
          "when": "on_success",
          "manual": false,
          "allow_failure": false,
diff --git a/doc/user/project/issues/csv_import.md b/doc/user/project/issues/csv_import.md
index 2fe3d78194c..1ae57c9a883 100644
--- a/doc/user/project/issues/csv_import.md
+++ b/doc/user/project/issues/csv_import.md
@@ -6,9 +6,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Importing issues from CSV **(FREE)**
 
-Issues can be imported to a project by uploading a CSV file with the columns
-`title` and `description`. Other columns are **not** imported. If you want to
-retain columns such as labels and milestones, consider the [Move Issue feature](managing_issues.md#move-an-issue).
+You can import issues to a project by uploading a CSV file with the following columns:
+
+| Name          | Required?              | Description                                      |
+|:--------------|:-----------------------|:-------------------------------------------------|
+| `title`       | **{check-circle}** Yes | Issue title.                                     |
+| `description` | **{check-circle}** Yes | Issue description.                               |
+| `due_date`    | **{dotted-circle}** No | Issue due date in `YYYY-MM-DD` format. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91317) in GitLab 15.2. |
+
+Data in other columns is not imported.
+
+You can use the `description` field to embed [quick actions](../quick_actions.md) to add other data to the issue.
+For example, labels, assignees, and milestones.
+
+Alternatively, you can [move an issue](managing_issues.md#move-an-issue). Moving issues preserves more data.
 
 The user uploading the CSV file is set as the author of the imported issues.
 
@@ -44,16 +55,22 @@ To import issues, GitLab requires CSV files have a specific format:
 | double-quote character | The double-quote (`"`) character is used to quote fields, enabling the use of the column separator in a field (see the third line in the sample CSV data below). To insert a double-quote (`"`) in a quoted field use two double-quote characters in succession (`""`). |
 | data rows              | After the header row, following rows must use the same column order. The issue title is required, but the description is optional. |
 
-If you have special characters in a field, (such as `\n` or `,`), surround the
-characters with double quotes (`"`).
+If you have special characters (for example, `,` or `\n`) or multiple lines in a field (for example,
+when using [quick actions](../quick_actions.md)), surround the characters with double quotes (`"`).
+
+When using [quick actions](../quick_actions.md), each action must be on a separate line.
 
 Sample CSV data:
 
 ```plaintext
-title,description
-My Issue Title,My Issue Description
-Another Title,"A description, with a comma"
-"One More Title","One More Description"
+title,description,due date
+My Issue Title,My Issue Description,2022-06-28
+Another Title,"A description, with a comma",
+"One More Title","One More Description",
+An Issue with Quick Actions,"Hey can we change the frontend?
+
+/assign @sjones
+/label ~frontend ~documentation",
 ```
 
 ### File size
diff --git a/doc/user/project/issues/img/close_issue_from_board.gif b/doc/user/project/issues/img/close_issue_from_board.gif
deleted file mode 100644
index 4814b42687b..00000000000
--- a/doc/user/project/issues/img/close_issue_from_board.gif
+++ /dev/null
diff --git a/doc/user/project/issues/img/multiple_assignees.gif b/doc/user/project/issues/img/multiple_assignees.gif
deleted file mode 100644
index 055a0efd9ae..00000000000
--- a/doc/user/project/issues/img/multiple_assignees.gif
+++ /dev/null
diff --git a/doc/user/project/issues/img/turn_off_confidentiality_v15_0.png b/doc/user/project/issues/img/turn_off_confidentiality_v15_0.png
deleted file mode 100644
index 37cbe0f4fd9..00000000000
--- a/doc/user/project/issues/img/turn_off_confidentiality_v15_0.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/turn_on_confidentiality_v15_0.png b/doc/user/project/issues/img/turn_on_confidentiality_v15_0.png
deleted file mode 100644
index 498867d1933..00000000000
--- a/doc/user/project/issues/img/turn_on_confidentiality_v15_0.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png b/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png
index 24a7ad554f8..c81ac85ab13 100644
--- a/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png
+++ b/doc/user/project/issues/img/turn_on_confidentiality_v15_1.png
diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md
index fbdce211295..15d8da7f544 100644
--- a/doc/user/project/issues/managing_issues.md
+++ b/doc/user/project/issues/managing_issues.md
@@ -385,8 +385,6 @@ To close an issue, you can do the following:
 - At the top of the issue, select **Close issue**.
 - In an [issue board](../issue_board.md), drag an issue card from its list into the **Closed** list.
 
-  ![close issue from the issue board](img/close_issue_from_board.gif)
-
 ### Reopen a closed issue
 
 Prerequisites:
diff --git a/doc/user/project/issues/multiple_assignees_for_issues.md b/doc/user/project/issues/multiple_assignees_for_issues.md
index 105dcd529c8..db160b6cfe8 100644
--- a/doc/user/project/issues/multiple_assignees_for_issues.md
+++ b/doc/user/project/issues/multiple_assignees_for_issues.md
@@ -4,39 +4,22 @@ 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
 ---
 
-# Multiple Assignees for Issues **(PREMIUM)**
+# Multiple assignees for issues **(PREMIUM)**
 
-> Moved to GitLab Premium in 13.9.
+> Moved from Starter to Premium in GitLab 13.9.
 
-In large teams, where there is shared ownership of an issue, it can be difficult
-to track who is working on it, who already completed their contributions, who
-didn't even start yet.
+In large teams with shared ownership, it can be difficult
+to track who is working on an issue, who's already done, or who hasn't started yet.
 
-You can also select multiple [assignees](managing_issues.md#assignee) for an issue, making it easier to
+You can add multiple [assignees](managing_issues.md#assignee) to an issue, making it easier to
 track, and making clearer who is accountable for it.
 
-![multiple assignees for issues](img/multiple_assignees_for_issues.png)
-
-## Use cases
-
-Consider a team formed by frontend developers, backend developers,
-UX designers, QA testers, and a product manager working together to bring an idea to
-market.
-
-Multiple Assignees for Issues makes collaboration smoother,
+Multiple assignees for issues makes collaboration smoother,
 and allows shared responsibilities to be clearly displayed.
 All assignees are shown across your team's workflows and receive notifications (as they
 would as single assignees), simplifying communication and ownership.
 
-Once an assignee had their work completed, they would remove themselves as assignees, making
-it clear that their role is complete.
+After an assignee completes their work, they remove themselves as an assignee, making
+it clear that their task is complete.
 
-## How it works
-
-From an opened issue, expand the right sidebar, locate the assignees entry,
-and select **Edit**. From the dropdown menu, select as many users as you want
-to assign the issue to.
-
-![adding multiple assignees](img/multiple_assignees.gif)
-
-To remove an assignee, clear them from the same dropdown menu.
+![multiple assignees for issues](img/multiple_assignees_for_issues.png)
diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md
index 160dade87bb..333b073ee40 100644
--- a/doc/user/project/labels.md
+++ b/doc/user/project/labels.md
@@ -441,8 +441,6 @@ This label now appears at the top of the label list, under **Prioritized Labels*
 To change the relative priority of these labels, drag them up and down the list.
 The labels higher in the list get higher priority.
 
-![Drag to change label priority](img/labels_drag_priority_v12_1.gif)
-
 To learn what happens when you sort by priority or label priority, see
 [Sorting and ordering issue lists](issues/sorting_issue_lists.md).
 
diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md
index 7bea57d180b..ff5f2ac8cb6 100644
--- a/doc/user/project/members/index.md
+++ b/doc/user/project/members/index.md
@@ -158,7 +158,7 @@ group itself.
 
 Prerequisites:
 
-- You must have the Owner role.
+- You must have the Maintainer or Owner role.
 - Optional. Unassign the member from all issues and merge requests that
   are assigned to them.
 
diff --git a/doc/user/project/members/share_project_with_groups.md b/doc/user/project/members/share_project_with_groups.md
index 02a9b76ce38..c4ae00f3c6c 100644
--- a/doc/user/project/members/share_project_with_groups.md
+++ b/doc/user/project/members/share_project_with_groups.md
@@ -24,6 +24,13 @@ members.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/352526) in GitLab 14.9.
     [Feature flag `invite_members_group_modal`](https://gitlab.com/gitlab-org/gitlab/-/issues/352526) removed.
 
+You can share a project only with:
+
+- Groups for which you have an explicitly defined [membership](index.md).
+- Groups that contain a nested subgroup or project for which you have an explicitly defined role.
+
+Administrators can share projects with any group in the namespace.
+
 The primary mechanism to give a group of users, say 'Engineering', access to a project,
 say 'Project Acme', in GitLab is to make the 'Engineering' group the owner of 'Project
 Acme'. But what if 'Project Acme' already belongs to another group, say 'Open Source'?
@@ -42,12 +49,11 @@ After sharing 'Project Acme' with 'Engineering':
 - The group is listed in the **Groups** tab.
 - The project is listed on the group dashboard.
 
-You can share a project only with:
-
-- Groups for which you have an explicitly defined membership.
-- Groups that contain a nested subgroup or project for which you have an explicitly defined role.
+When you share a project, be aware of the following restrictions and outcomes:
 
-Administrators can share projects with any group in the system.
+- [Maximum access level](#maximum-access-level)
+- [Sharing a public project with a private group](#share-a-public-project-with-private-group)
+- [Sharing project with group lock](#share-project-with-group-lock)
 
 ## Maximum access level
 
@@ -61,9 +67,13 @@ in. That means you can only share down the hierarchy. For example, `group/subgro
 - Can not be shared with `group`.
 - Can be shared with `group/subgroup02` or  `group/subgroup01/subgroup03`.
 
-## Share public project with private group
+## Share a public project with private group
+
+When you share a public project with a private group, be aware of the following outcomes:
 
-When sharing a public project with a private group, owners and maintainers of the project see the name of the group in the `members` page. Owners also have the possibility to see members of the private group they don't have access to when mentioning them in the issue or merge request.
+- The name of the group is no longer private and is visible to all users in the project members page.
+- Owners of the project have access to members of the private group when they mention them in issues or merge requests.
+- Project members who are direct or indirect members of the private group can see private group members listed in addition to members of the project.
 
 ## Share project with group lock
 
diff --git a/doc/user/project/merge_requests/accessibility_testing.md b/doc/user/project/merge_requests/accessibility_testing.md
index b8907532066..c1a87f7a5d4 100644
--- a/doc/user/project/merge_requests/accessibility_testing.md
+++ b/doc/user/project/merge_requests/accessibility_testing.md
@@ -1,76 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Insights
-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
+redirect_to: '../../../ci/testing/accessibility_testing.md'
+remove_date: '2022-08-31'
 ---
 
-# Accessibility testing **(FREE)**
+This document was moved to [another location](../../../ci/testing/accessibility_testing.md).
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25144) in GitLab 12.8.
-
-If your application offers a web interface, you can use
-[GitLab CI/CD](../../../ci/index.md) to determine the accessibility
-impact of pending code changes.
-
-[Pa11y](https://pa11y.org/) is a free and open source tool for
-measuring the accessibility of web sites. GitLab integrates Pa11y into a
-[CI job template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml).
-The `a11y` job analyzes a defined set of web pages and reports
-accessibility violations, warnings, and notices in a file named
-`accessibility`.
-
-As of [GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73309), Pa11y uses
-[WCAG 2.1 rules](https://www.w3.org/TR/WCAG21/#new-features-in-wcag-2-1).
-
-## Accessibility merge request widget
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/39425) in GitLab 13.0 behind the disabled [feature flag](../../../administration/feature_flags.md) `:accessibility_report_view`.
-> - [Feature Flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/217372) in GitLab 13.1.
-
-GitLab displays an **Accessibility Report** in the merge request widget area:
-
-![Accessibility merge request widget](img/accessibility_mr_widget_v13_0.png)
-
-## Configure accessibility testing
-
-You can run Pa11y with GitLab CI/CD using the
-[GitLab Accessibility Docker image](https://gitlab.com/gitlab-org/ci-cd/accessibility).
-
-To define the `a11y` job for GitLab 12.9 and later:
-
-1. [Include](../../../ci/yaml/index.md#includetemplate) the
-   [`Accessibility.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
-   from your GitLab installation.
-1. Add the following configuration to your `.gitlab-ci.yml` file.
-
-   ```yaml
-   stages:
-     - accessibility
-
-   variables:
-     a11y_urls: "https://about.gitlab.com https://gitlab.com/users/sign_in"
-
-   include:
-     - template: "Verify/Accessibility.gitlab-ci.yml"
-   ```
-
-1. Customize the `a11y_urls` variable to list the URLs of the web pages to test with Pa11y.
-
-The `a11y` job in your CI/CD pipeline generates these files:
-
-- One HTML report per URL listed in the `a11y_urls` variable.
-- One file containing the collected report data. In GitLab versions 12.11 and later, this
-  file is named `gl-accessibility.json`. In GitLab versions 12.10 and earlier, this file
-  is named [`accessibility.json`](https://gitlab.com/gitlab-org/ci-cd/accessibility/-/merge_requests/9).
-
-You can [view job artifacts in your browser](../../../ci/pipelines/job_artifacts.md#download-job-artifacts).
-
-NOTE:
-For GitLab versions earlier than 12.9, use `include:remote` and
-link to the [current template in the default branch](https://gitlab.com/gitlab-org/gitlab/-/raw/master/lib/gitlab/ci/templates/Verify/Accessibility.gitlab-ci.yml)
-
-NOTE:
-The job definition provided by the template does not support Kubernetes.
-
-You cannot pass configurations into Pa11y via CI configuration.
-To change the configuration, edit a copy of the template in your CI file.
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/merge_requests/approvals/img/mr_approvals_by_code_owners_v12_7.png b/doc/user/project/merge_requests/approvals/img/mr_approvals_by_code_owners_v12_7.png
deleted file mode 100644
index 669148a41d8..00000000000
--- a/doc/user/project/merge_requests/approvals/img/mr_approvals_by_code_owners_v12_7.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/approvals/img/mr_approvals_by_code_owners_v15_2.png b/doc/user/project/merge_requests/approvals/img/mr_approvals_by_code_owners_v15_2.png
new file mode 100644
index 00000000000..37dad4e5ae8
--- /dev/null
+++ b/doc/user/project/merge_requests/approvals/img/mr_approvals_by_code_owners_v15_2.png
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index 21cf5cca4d1..b79c8ee867f 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -152,9 +152,9 @@ become eligible approvers in the project. To enable this merge request approval
 
 1. Go to your project and select **Settings > General**.
 1. Expand **Merge request (MR) approvals**.
-1. Locate **Eligible users** and select the number of approvals required:
+1. Locate **All eligible users** and select the number of approvals required:
 
-   ![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v12_7.png)
+![MR approvals by Code Owners](img/mr_approvals_by_code_owners_v15_2.png)
 
 You can also
 [require code owner approval](../../protected_branches.md#require-code-owner-approval-on-a-protected-branch)
diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md
index 9295ea4c310..7b865a91106 100644
--- a/doc/user/project/merge_requests/approvals/settings.md
+++ b/doc/user/project/merge_requests/approvals/settings.md
@@ -55,7 +55,7 @@ this setting, unless you configure one of these options:
 > Moved to GitLab Premium in 13.9.
 
 By default, users who commit to a merge request can still approve it. At both
-the project level or [instance level](../../../admin_area/merge_requests_approvals.md)
+the project level or [instance level](../../../admin_area/merge_requests_approvals.md),
 you can prevent committers from approving merge requests that are partially
 their own. To do this:
 
@@ -82,7 +82,7 @@ read the official Git documentation for an explanation.
 ## Prevent editing approval rules in merge requests
 
 By default, users can override the approval rules you [create for a project](rules.md)
-on a per-merge request basis. If you don't want users to change approval rules
+on a per-merge-request basis. If you don't want users to change approval rules
 on merge requests, you can disable this setting:
 
 1. Go to your project and select **Settings > General**.
@@ -119,7 +119,7 @@ when more changes are added to it:
 1. Select the **Remove all approvals when commits are added to the source branch** checkbox.
 1. Select **Save changes**.
 
-Approvals aren't reset when a merge request is [rebased from the UI](../methods/index.md#rebasing-in-semi-linear-merge-methods)
+Approvals aren't reset when a merge request is [rebased from the UI](../methods/index.md#rebasing-in-semi-linear-merge-methods).
 However, approvals are reset if the target branch is changed.
 
 ## Code coverage check approvals
diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md
index 9c7d9e2bf19..95f749210c4 100644
--- a/doc/user/project/merge_requests/browser_performance_testing.md
+++ b/doc/user/project/merge_requests/browser_performance_testing.md
@@ -1,242 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Insights
-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
+redirect_to: '../../../ci/testing/browser_performance_testing.md'
+remove_date: '2022-08-31'
 ---
 
-# Browser Performance Testing **(PREMIUM)**
+This document was moved to [another location](../../../ci/testing/browser_performance_testing.md).
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3507) in GitLab 10.3.
-
-If your application offers a web interface and you're using
-[GitLab CI/CD](../../../ci/index.md), you can quickly determine the rendering performance
-impact of pending code changes in the browser.
-
-NOTE:
-You can automate this feature in your applications by using [Auto DevOps](../../../topics/autodevops/index.md).
-
-## Overview
-
-GitLab uses [Sitespeed.io](https://www.sitespeed.io), a free and open source
-tool, for measuring the rendering performance of web sites. The
-[Sitespeed plugin](https://gitlab.com/gitlab-org/gl-performance) that GitLab built outputs
-the performance score for each page analyzed in a file called `browser-performance.json`
-this data can be shown on Merge Requests.
-
-## Use cases
-
-Consider the following workflow:
-
-1. A member of the marketing team is attempting to track engagement by adding a new tool.
-1. With browser performance metrics, they see how their changes are impacting the usability
-   of the page for end users.
-1. The metrics show that after their changes, the performance score of the page has gone down.
-1. When looking at the detailed report, they see the new JavaScript library was
-   included in `<head>`, which affects loading page speed.
-1. They ask for help from a front end developer, who sets the library to load asynchronously.
-1. The frontend developer approves the merge request, and authorizes its deployment to production.
-
-## How browser performance testing works
-
-First, define a job in your `.gitlab-ci.yml` file that generates the
-[Browser Performance report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportsbrowser_performance).
-GitLab then checks this report, compares key performance metrics for each page
-between the source and target branches, and shows the information in the merge request.
-
-For an example Browser Performance job, see
-[Configuring Browser Performance Testing](#configuring-browser-performance-testing).
-
-NOTE:
-If the Browser Performance report has no data to compare, such as when you add the
-Browser Performance job in your `.gitlab-ci.yml` for the very first time,
-the Browser Performance report widget doesn't display. It must have run at least
-once on the target branch (`main`, for example), before it displays in a
-merge request targeting that branch.
-
-![Browser Performance Widget](img/browser_performance_testing.png)
-
-## Configuring Browser Performance Testing
-
-This example shows how to run the [sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/)
-on your code by using GitLab CI/CD and [sitespeed.io](https://www.sitespeed.io)
-using Docker-in-Docker.
-
-1. First, set up GitLab Runner with a
-   [Docker-in-Docker build](../../../ci/docker/using_docker_build.md#use-docker-in-docker).
-1. Configure the default Browser Performance Testing CI/CD job as follows in your `.gitlab-ci.yml` file:
-
-   ```yaml
-   include:
-     template: Verify/Browser-Performance.gitlab-ci.yml
-
-   browser_performance:
-     variables:
-       URL: https://example.com
-   ```
-
-WARNING:
-In GitLab 13.12 and earlier, the job [was named](https://gitlab.com/gitlab-org/gitlab/-/issues/225914) `performance`.
-
-The above example:
-
-- Creates a `browser_performance` job in your CI/CD pipeline and runs sitespeed.io against the webpage you
-  defined in `URL` to gather key metrics.
-- Uses a template that doesn't work with Kubernetes clusters. If you are using a Kubernetes cluster,
-  use [`template: Jobs/Browser-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Browser-Performance-Testing.gitlab-ci.yml)
-   instead.
-- Uses a CI/CD template that is included in all GitLab installations since 12.4. If you are using
-  GitLab 12.3 or earlier, you must [add the configuration manually](#gitlab-versions-132-and-earlier).
-
-The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance),
-and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportsbrowser_performance)
-that you can later download and analyze. This implementation always takes the latest
-Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled,
-you can view the report directly in your browser.
-
-You can also customize the jobs with CI/CD variables:
-
-- `SITESPEED_IMAGE`: Configure the Docker image to use for the job (default `sitespeedio/sitespeed.io`), but not the image version.
-- `SITESPEED_VERSION`: Configure the version of the Docker image to use for the job (default `14.1.0`).
-- `SITESPEED_OPTIONS`: Configure any additional sitespeed.io options as required (default `nil`). Refer to the [sitespeed.io documentation](https://www.sitespeed.io/documentation/sitespeed.io/configuration/) for more details.
-
-For example, you can override the number of runs sitespeed.io
-makes on the given URL, and change the version:
-
-```yaml
-include:
-  template: Verify/Browser-Performance.gitlab-ci.yml
-
-browser_performance:
-  variables:
-    URL: https://www.sitespeed.io/
-    SITESPEED_VERSION: 13.2.0
-    SITESPEED_OPTIONS: -n 5
-```
-
-### Configuring degradation threshold
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27599) in GitLab 13.0.
-
-You can configure the sensitivity of degradation alerts to avoid getting alerts for minor drops in metrics.
-This is done by setting the `DEGRADATION_THRESHOLD` CI/CD variable. In the example below, the alert only shows up
-if the `Total Score` metric degrades by 5 points or more:
-
-```yaml
-include:
-  template: Verify/Browser-Performance.gitlab-ci.yml
-
-browser_performance:
-  variables:
-    URL: https://example.com
-    DEGRADATION_THRESHOLD: 5
-```
-
-The `Total Score` metric is based on sitespeed.io's [coach performance score](https://www.sitespeed.io/documentation/sitespeed.io/metrics/#performance-score). There is more information in [the coach documentation](https://www.sitespeed.io/documentation/coach/how-to/#what-do-the-coach-do).
-
-### Performance testing on Review Apps
-
-The above CI YAML configuration is great for testing against static environments, and it can
-be extended for dynamic environments, but a few extra steps are required:
-
-1. The `browser_performance` job should run after the dynamic environment has started.
-1. In the `review` job:
-    1. Generate a URL list file with the dynamic URL.
-    1. Save the file as an artifact, for example with `echo $CI_ENVIRONMENT_URL > environment_url.txt`
-    in your job's `script`.
-    1. Pass the list as the URL environment variable (which can be a URL or a file containing URLs)
-    to the `browser_performance` job.
-1. You can now run the sitespeed.io container against the desired hostname and
-   paths.
-
-Your `.gitlab-ci.yml` file would look like:
-
-```yaml
-stages:
-  - deploy
-  - performance
-
-include:
-  template: Verify/Browser-Performance.gitlab-ci.yml
-
-review:
-  stage: deploy
-  environment:
-    name: review/$CI_COMMIT_REF_SLUG
-    url: http://$CI_COMMIT_REF_SLUG.$APPS_DOMAIN
-  script:
-    - run_deploy_script
-    - echo $CI_ENVIRONMENT_URL > environment_url.txt
-  artifacts:
-    paths:
-      - environment_url.txt
-  only:
-    - branches
-  except:
-    - master
-
-browser_performance:
-  dependencies:
-    - review
-  variables:
-    URL: environment_url.txt
-```
-
-### GitLab versions 13.2 and earlier
-
-Browser Performance Testing has gone through several changes since its introduction.
-In this section we detail these changes and how you can run the test based on your
-GitLab version:
-
-- In 13.2 the feature was renamed from `Performance` to `Browser Performance` with additional
-  template CI/CD variables.
-- In GitLab 12.4 [a job template was made available](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Browser-Performance.gitlab-ci.yml).
-- For 11.5 to 12.3 no template is available and the job has to be defined manually as follows:
-
-  ```yaml
-  performance:
-    stage: performance
-    image: docker:git
-    variables:
-      URL: https://example.com
-      SITESPEED_VERSION: 14.1.0
-      SITESPEED_OPTIONS: ''
-    services:
-      - docker:stable-dind
-    script:
-      - mkdir gitlab-exporter
-      - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/1.1.0/index.js
-      - mkdir sitespeed-results
-      - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:$SITESPEED_VERSION --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL $SITESPEED_OPTIONS
-      - mv sitespeed-results/data/performance.json performance.json
-    artifacts:
-      paths:
-        - performance.json
-        - sitespeed-results/
-      reports:
-        performance: performance.json
-  ```
-
-- For 11.4 and earlier the job should be defined as follows:
-
-  ```yaml
-  performance:
-    stage: performance
-    image: docker:git
-    variables:
-      URL: https://example.com
-    services:
-      - docker:stable-dind
-    script:
-      - mkdir gitlab-exporter
-      - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/1.1.0/index.js
-      - mkdir sitespeed-results
-      - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
-      - mv sitespeed-results/data/performance.json performance.json
-    artifacts:
-      paths:
-        - performance.json
-        - sitespeed-results/
-  ```
-
-Upgrading to the latest version and using the templates is recommended, to ensure
-you receive the latest updates, including updates to the sitespeed.io versions.
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md
index 623af914692..79e590cb905 100644
--- a/doc/user/project/merge_requests/code_quality.md
+++ b/doc/user/project/merge_requests/code_quality.md
@@ -1,634 +1,11 @@
 ---
-stage: Secure
-group: Static Analysis
-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
+redirect_to: '../../../ci/testing/code_quality.md'
+remove_date: '2022-08-31'
 ---
 
-# Code Quality **(FREE)**
+This document was moved to [another location](../../../ci/testing/code_quality.md).
 
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
-
-To ensure your project's code stays simple, readable, and easy to contribute to,
-you can use [GitLab CI/CD](../../../ci/index.md) to analyze your source code quality.
-
-For example, while you're implementing a feature, you can run Code Quality reports
-to analyze how your improvements are impacting your code's quality. You can
-use this information to ensure that your changes are improving performance rather
-than degrading it.
-
-Code Quality:
-
-- Uses [plugins](https://docs.codeclimate.com/docs/list-of-engines) supported by Code Climate, which are
-  free and open source. Code Quality does not require a Code Climate
-  subscription.
-- Runs in [pipelines](../../../ci/pipelines/index.md) by using a Docker image built in the
-  [GitLab Code Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project.
-- Uses [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults).
-- Can make use of a [template](#example-configuration).
-- Is available by using [Auto Code Quality](../../../topics/autodevops/stages.md#auto-code-quality), provided by [Auto DevOps](../../../topics/autodevops/index.md).
-- Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool).
-
-## Summary of features per tier
-
-Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/),
-as shown in the following table:
-
-| Capability                                                            | In Free             | In Premium          | In Ultimate        |
-|:----------------------------------------------------------------------|:--------------------|:--------------------|:-------------------|
-| [Configure scanners](#configuring-jobs-using-variables)               | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
-| [Integrate custom scanners](#implementing-a-custom-tool)              | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
-| [Generate JSON or HTML report artifacts](#generate-an-html-report)    | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
-| [See findings in merge request widget](#code-quality-widget)          | **{check-circle}**  | **{check-circle}**  | **{check-circle}** |
-| [See reports in CI pipelines](#code-quality-reports)                  | **{dotted-circle}** | **{check-circle}**  | **{check-circle}** |
-| [See findings in merge request diff view](#code-quality-in-diff-view) | **{dotted-circle}** | **{dotted-circle}** | **{check-circle}** |
-
-## Code Quality Widget
-
-> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/212499) to GitLab Free in 13.2.
-
-Going a step further, GitLab can show the Code Quality report right
-in the merge request widget area if a report from the target branch is available to compare to:
-
-![Code Quality Widget](img/code_quality_widget_13_11.png)
-
-Watch a quick walkthrough of Code Quality in action:
-
-<div class="video-fallback">
-  See the video: <a href="https://www.youtube.com/watch?v=B32LxtJKo9M">Code Quality: Speed Run</a>.
-</div>
-<figure class="video-container">
-  <iframe src="https://www.youtube.com/embed/B32LxtJKo9M" frameborder="0" allowfullscreen="true"> </iframe>
-</figure>
-
-NOTE:
-For one customer, the auditor found that having Code Quality, SAST, and Container Scanning all automated in GitLab CI/CD was almost better than a manual review! [Read more](https://about.gitlab.com/customers/bi_worldwide/).
-
-See also the Code Climate list of [Supported Languages for Maintainability](https://docs.codeclimate.com/docs/supported-languages-for-maintainability).
-
-## Code Quality in diff view **(ULTIMATE)**
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/267612) in GitLab 13.11, disabled by default behind the `codequality_mr_diff` [feature flag](../../../administration/feature_flags.md).
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/284140) in GitLab 13.12.
-> - [Disabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/2526) in GitLab 14.0 due to [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/334116).
-> - [Inline annotation added](https://gitlab.com/gitlab-org/gitlab/-/issues/2526) and [feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/284140) in GitLab 14.1.
-
-Changes to files in merge requests can cause Code Quality to fall if merged. In these cases,
-the merge request's diff view displays an indicator next to lines with new Code Quality violations. For example:
-
-![Code Quality MR diff report](img/code_quality_mr_diff_report_v14_2.png)
-
-## Example configuration
-
-This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
-
-- Using shared runners, the job should be configured For the [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker).
-- Using private runners, there is an [alternative configuration](#set-up-a-private-runner-for-code-quality-without-docker-in-docker) recommended for running Code Quality analysis more efficiently.
-
-In either configuration, the runner must have enough disk space to handle generated Code Quality files. For example on the [GitLab project](https://gitlab.com/gitlab-org/gitlab) the files are approximately 7 GB.
-
-Once you set up GitLab Runner, include the [Code Quality template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Code-Quality.gitlab-ci.yml) in your CI configuration:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-```
-
-The above example creates a `code_quality` job in your CI/CD pipeline which
-scans your source code for code quality issues. The report is saved as a
-[Code Quality report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportscodequality)
-that you can later download and analyze.
-
-It's also possible to override the URL to the Code Quality image by
-setting the `CODE_QUALITY_IMAGE` CI/CD variable. This is particularly useful if you want
-to lock in a specific version of Code Quality, or use a fork of it:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-
-code_quality:
-  variables:
-    CODE_QUALITY_IMAGE: "registry.example.com/codequality-fork:latest"
-```
-
-In [GitLab 13.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/11100), you can override the [Code Quality environment variables](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables):
-
-```yaml
-variables:
-  TIMEOUT_SECONDS: 1
-
-include:
-  - template: Code-Quality.gitlab-ci.yml
-```
-
-By default, report artifacts are not downloadable. If you need them downloadable on the
-job details page, you can add `gl-code-quality-report.json` to the artifact paths like so:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-
-code_quality:
-  artifacts:
-    paths: [gl-code-quality-report.json]
-```
-
-The included `code_quality` job is running in the `test` stage, so it needs to be included in your CI configuration, like so:
-
-```yaml
-stages:
-  - test
-```
-
-NOTE:
-This information is automatically extracted and shown right in the merge request widget.
-
-WARNING:
-On self-managed instances, if a malicious actor compromises the Code Quality job
-definition they could execute privileged Docker commands on the runner
-host. Having proper access control policies mitigates this attack vector by
-allowing access only to trusted actors.
-
-### Set up a private runner for code quality without Docker-in-Docker
-
-It's possible to configure your own runners and avoid Docker-in-Docker. You can use a
-configuration that may greatly speed up job execution without requiring your runners
-to operate in privileged mode.
-
-This alternative configuration uses socket binding to share the Runner's Docker daemon
-with the job environment. Be aware that this configuration [has significant considerations](../../../ci/docker/using_docker_build.md#use-docker-socket-binding)
-to be consider, but may be preferable depending on your use case.
-
-1. Register a new runner:
-
-   ```shell
-   $ gitlab-runner register --executor "docker" \
-     --docker-image="docker:stable" \
-     --url "https://gitlab.com/" \
-     --description "cq-sans-dind" \
-     --tag-list "cq-sans-dind" \
-     --locked="false" \
-     --access-level="not_protected" \
-     --docker-volumes "/cache"\
-     --docker-volumes "/builds:/builds"\
-     --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \
-     --registration-token="<project_token>" \
-     --non-interactive
-   ```
-
-1. **Optional, but recommended:** Set the builds directory to `/tmp/builds`,
-  so job artifacts are periodically purged from the runner host. If you skip
-  this step, you must clean up the default builds directory (`/builds`) yourself.
-  You can do this by adding the following two flags to `gitlab-runner register`
-  in the previous step.
-
-   ```shell
-   --builds-dir "/tmp/builds"
-   --docker-volumes "/tmp/builds:/tmp/builds" # Use this instead of --docker-volumes "/builds:/builds"
-   ```
-
-   The resulting configuration:
-
-   ```toml
-   [[runners]]
-     name = "cq-sans-dind"
-     url = "https://gitlab.com/"
-     token = "<project_token>"
-     executor = "docker"
-     builds_dir = "/tmp/builds"
-     [runners.docker]
-       tls_verify = false
-       image = "docker:stable"
-       privileged = false
-       disable_entrypoint_overwrite = false
-       oom_kill_disable = false
-       disable_cache = false
-       volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock", "/tmp/builds:/tmp/builds"]
-       shm_size = 0
-     [runners.cache]
-       [runners.cache.s3]
-       [runners.cache.gcs]
-   ```
-
-1. Apply two overrides to the `code_quality` job created by the template:
-
-   ```yaml
-   include:
-     - template: Code-Quality.gitlab-ci.yml
-
-   code_quality:
-     services:            # Shut off Docker-in-Docker
-     tags:
-       - cq-sans-dind     # Set this job to only run on our new specialized runner
-   ```
-
-The end result is that:
-
-- Privileged mode is not used.
-- Docker-in-Docker is not used.
-- Docker images, including all CodeClimate images, are cached, and not re-fetched for subsequent jobs.
-
-With this configuration, the run time for a second pipeline is much shorter. For example
-this [small change](https://gitlab.com/drew/test-code-quality-template/-/merge_requests/4/diffs?commit_id=1e705607aef7236c1b20bb6f637965f3f3e53a46)
-to an [open merge request](https://gitlab.com/drew/test-code-quality-template/-/merge_requests/4/pipelines)
-running Code Quality analysis ran significantly faster the second time:
-
-![Code Quality sequential runs without DinD](img/code_quality_host_bound_sequential.png)
-
-This configuration is not possible on `gitlab.com` shared runners. Shared runners
-are configured with `privileged=true`, and they do not expose `docker.sock` into
-the job container. As a result, socket binding cannot be used to make `docker` available
-in the context of the job script.
-
-[Docker-in-Docker](../../../ci/docker/using_docker_build.md#use-docker-in-docker)
-was chosen as an operational decision by the runner team, instead of exposing `docker.sock`.
-
-### Disabling the code quality job
-
-The `code_quality` job doesn't run if the `$CODE_QUALITY_DISABLED` CI/CD variable
-is present. Please refer to the CI/CD variables [documentation](../../../ci/variables/index.md)
-to learn more about how to define one.
-
-To disable the `code_quality` job, add `CODE_QUALITY_DISABLED` as a custom CI/CD variable.
-This can be done:
-
-- For [the whole project](../../../ci/variables/index.md#custom-cicd-variables).
-- For a single pipeline run:
-
-  1. Go to **CI/CD > Pipelines**
-  1. Select **Run pipeline**
-  1. Add `CODE_QUALITY_DISABLED` as the variable key, with any value.
-
-### Using with merge request pipelines
-
-The configuration provided by the Code Quality template does not let the `code_quality` job
-run on [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md).
-
-If merge request pipelines is enabled, the `code_quality:rules` must be redefined.
-
-The template has these [`rules`](../../../ci/yaml/index.md#rules) for the `code quality` job:
-
-```yaml
-code_quality:
-  rules:
-    - if: $CODE_QUALITY_DISABLED
-      when: never
-    - if: $CI_COMMIT_TAG || $CI_COMMIT_BRANCH
-```
-
-If you are using merge request pipelines, your `rules` (or [`workflow: rules`](../../../ci/yaml/index.md#workflow))
-might look like this example:
-
-```yaml
-job1:
-  rules:
-    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Run job1 in merge request pipelines
-    - if: $CI_COMMIT_BRANCH == "main"                  # Run job1 in pipelines on the main branch (but not in other branch pipelines)
-    - if: $CI_COMMIT_TAG                               # Run job1 in pipelines for tags
-```
-
-To make these work together, you need to overwrite the code quality `rules`
-so that they match your current `rules`. From the example above, it could look like:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-
-code_quality:
-  rules:
-    - if: $CODE_QUALITY_DISABLED
-      when: never
-    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # Run code quality job in merge request pipelines
-    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH      # Run code quality job in pipelines on the default branch (but not in other branch pipelines)
-    - if: $CI_COMMIT_TAG                               # Run code quality job in pipelines for tags
-```
-
-### Configure Code Quality to use a private container image registry
-
-> [Introduced](https://gitlab.com/gitlab-org/ci-cd/codequality/-/merge_requests/30) in 13.7.
-
-To reduce network time and external dependency, you can use your own
-container image registry to host the Code Quality Docker images. Because of
-the nested architecture of container execution, the registry prefix must
-be specifically configured to be passed down into CodeClimate's subsequent
-`docker pull` commands for individual engines.
-
-The following two variables can address all of the required image pulls:
-
-- `CODE_QUALITY_IMAGE`: A fully prefixed image name that can be located anywhere
-  accessible from your job environment. GitLab Container Registry can be used here
-  to host your own copy.
-- `CODECLIMATE_PREFIX`: The domain of your intended container image registry. This
-  is a configuration option supported by [CodeClimate CLI](https://github.com/codeclimate/codeclimate/pull/948). You must:
-  - Include a trailing slash (`/`).
-  - Not include a protocol prefix, such as `https://`.
-
-```yaml
-include:
-  - template: Jobs/Code-Quality.gitlab-ci.yml
-
-code_quality:
-  variables:
-    CODE_QUALITY_IMAGE: "my-private-registry.local:12345/codequality:0.85.24"
-    CODECLIMATE_PREFIX: "my-private-registry.local:12345/"
-```
-
-This example is specific to GitLab Code Quality. For more general
-instructions on how to configure DinD with a registry mirror, see the
-relevant [documentation](../../../ci/docker/using_docker_build.md#enable-registry-mirror-for-dockerdind-service).
-
-## Configuring jobs using variables
-
-The Code Quality job supports environment variables that users can set to
-configure job execution at runtime.
-
-For a list of available environment variables, see
-[Environment variables](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables).
-
-## Implementing a custom tool
-
-It's possible to have a custom tool provide Code Quality reports in GitLab. To
-do this:
-
-1. Define a job in your `.gitlab-ci.yml` file that generates the
-   [Code Quality report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportscodequality).
-1. Configure your tool to generate the Code Quality report artifact as a JSON
-   file that implements a subset of the [Code Climate
-   spec](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types).
-
-The Code Quality report artifact JSON file must contain an array of objects
-with the following properties:
-
-| Name                   | Description                                                                               |
-| ---------------------- | ----------------------------------------------------------------------------------------- |
-| `description`          | A description of the code quality violation.                                              |
-| `fingerprint`          | A unique fingerprint to identify the code quality violation. For example, an MD5 hash.    |
-| `severity`             | A severity string (can be `info`, `minor`, `major`, `critical`, or `blocker`).            |
-| `location.path`        | The relative path to the file containing the code quality violation.                      |
-| `location.lines.begin` or `location.positions.begin.line` | The line on which the code quality violation occurred. |
-
-Example:
-
-```json
-[
-  {
-    "description": "'unused' is assigned a value but never used.",
-    "fingerprint": "7815696ecbf1c96e6894b779456d330e",
-    "severity": "minor",
-    "location": {
-      "path": "lib/index.js",
-      "lines": {
-        "begin": 42
-      }
-    }
-  }
-]
-```
-
-NOTE:
-Although the Code Climate spec supports more properties, those are ignored by
-GitLab.
-The GitLab parser does not allow a [byte order mark](https://en.wikipedia.org/wiki/Byte_order_mark)
-at the beginning of the file.
-
-## Code Quality reports **(PREMIUM)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21527) in GitLab 12.9.
-
-![Code Quality Report](img/code_quality_report_13_11.png)
-
-After the Code Quality job completes:
-
-- Potential changes to code quality are shown directly in the merge request.
-  The Code Quality widget in the merge request compares the reports from the base and head of the branch,
-  then lists any violations that are resolved or created when the branch is merged.
-- The full JSON report is available as a
-  [downloadable artifact](../../../ci/pipelines/job_artifacts.md#download-job-artifacts)
-  for the `code_quality` job.
-- The full list of code quality violations generated by a pipeline is shown in the
-  Code Quality tab of the Pipeline Details page.
-
-## Generate an HTML report
-
-In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/ci-cd/codequality/-/issues/10),
-it is possible to generate an HTML report file by setting the `REPORT_FORMAT`
-CI/CD variable to `html`. This is useful if you just want to view the report in a more
-human-readable format or to publish this artifact on GitLab Pages for even
-easier reviewing.
-
-To generate both JSON and HTML report files, add another job to your template by using `extends: code_quality`:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-
-code_quality_html:
-  extends: code_quality
-  variables:
-    REPORT_FORMAT: html
-  artifacts:
-    paths: [gl-code-quality-report.html]
-```
-
-NOTE:
-Adding a job means your code is scanned twice: once to generate a JSON report and once to generate an HTML report.
-
-You can also generate _only_ an HTML report instead of the standard JSON report. To do so, set `REPORT_FORMAT` to `html` in the existing job:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-
-code_quality:
-  variables:
-    REPORT_FORMAT: html
-  artifacts:
-    paths: [gl-code-quality-report.html]
-```
-
-WARNING:
-If you only generate an HTML report, you can't see your results in the [merge request widget](#code-quality-widget), [pipeline report](#code-quality-reports), or [diff view](#code-quality-in-diff-view).
-These features require a JSON report.
-
-## Extending functionality
-
-### Using Analysis Plugins
-
-Should there be a need to extend the default functionality provided by Code Quality, as stated in [Code Quality](#code-quality), [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) are available.
-
-For example, to use the [SonarJava analyzer](https://docs.codeclimate.com/docs/sonar-java),
-add a file named `.codeclimate.yml` containing the [enablement code](https://docs.codeclimate.com/docs/sonar-java#enable-the-plugin)
-for the plugin to the root of your repository:
-
-```yaml
-version: "2"
-plugins:
-  sonar-java:
-    enabled: true
-```
-
-This adds SonarJava to the `plugins:` section of the [default `.codeclimate.yml`](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/codeclimate_defaults/.codeclimate.yml.template)
-included in your project.
-
-Changes to the `plugins:` section do not affect the `exclude_patterns` section of the
-default `.codeclimate.yml`. See the Code Climate documentation for
-[excluding files and folders](https://docs.codeclimate.com/docs/excluding-files-and-folders)
-for more details.
-
-Here's [an example project](https://gitlab.com/jheimbuck_gl/jh_java_example_project) that uses Code Quality with a `.codeclimate.yml` file.
-
-## Use a Code Quality image hosted in a registry with untrusted certificates
-
-If you set the `CODE_QUALITY_IMAGE` to an image that is hosted in a
-Docker registry which uses a TLS certificate that is not trusted, such as
-a self-signed certificate, you can see errors like the one below:
-
-```shell
-$ docker pull --quiet "$CODE_QUALITY_IMAGE"
-Error response from daemon: Get https://gitlab.example.com/v2/: x509: certificate signed by unknown authority
-```
-
-To fix this, configure the Docker daemon to [trust certificates](https://docs.docker.com/registry/insecure/#use-self-signed-certificates)
-by putting the certificate inside of the `/etc/docker/certs.d`
-directory.
-
-This Docker daemon is exposed to the subsequent Code Quality Docker container in the
-[GitLab Code Quality template](https://gitlab.com/gitlab-org/gitlab/-/blob/v13.8.3-ee/lib/gitlab/ci/templates/Jobs/Code-Quality.gitlab-ci.yml#L41)
-and should be to exposed any other containers in which you want to have
-your certificate configuration apply.
-
-### Docker
-
-If you have access to GitLab Runner configuration, add the directory as a
-[volume mount](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#volumes-in-the-runnersdocker-section). For example:
-
-```toml
-[[runners]]
-  ...
-  executor = "docker"
-  [runners.docker]
-    ...
-    privileged = true
-    volumes = ["/cache", "/etc/gitlab-runner/certs/gitlab.example.com.crt:/etc/docker/certs.d/gitlab.example.com/ca.crt:ro"]
-```
-
-Replace `gitlab.example.com` with the actual domain of the registry.
-
-### Kubernetes
-
-If you have access to GitLab Runner configuration and the Kubernetes cluster,
-you can [mount a ConfigMap](https://docs.gitlab.com/runner/executors/kubernetes.html#configmap-volumes):
-
-1. Create a ConfigMap with the certificate:
-
-   ```shell
-   kubectl create configmap registry-crt --namespace gitlab-runner --from-file /etc/gitlab-runner/certs/gitlab.example.com.crt
-   ```
-
-1. Update GitLab Runner `config.toml` to specify the ConfigMap:
-
-   ```toml
-   [[runners]]
-     ...
-     executor = "kubernetes"
-     [runners.kubernetes]
-       image = "alpine:3.12"
-       privileged = true
-       [[runners.kubernetes.volumes.config_map]]
-         name = "registry-crt"
-         mount_path = "/etc/docker/certs.d/gitlab.example.com/ca.crt"
-         sub_path = "gitlab.example.com.crt"
-   ```
-
-Replace `gitlab.example.com` with the actual domain of the registry.
-
-## Troubleshooting
-
-### Changing the default configuration has no effect
-
-A common issue is that the terms `Code Quality` (GitLab specific) and `Code Climate`
-(Engine used by GitLab) are very similar. You must add a **`.codeclimate.yml`** file
-to change the default configuration, **not** a `.codequality.yml` file. If you use
-the wrong filename, the [default `.codeclimate.yml`](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/codeclimate_defaults/.codeclimate.yml.template)
-is still used.
-
-### No Code Quality report is displayed in a merge request
-
-This can be due to multiple reasons:
-
-- You just added the Code Quality job in your `.gitlab-ci.yml`. The report does not
-  have anything to compare to yet, so no information can be displayed. It only displays
-  after future merge requests have something to compare to.
-- Your pipeline is not set to run the code quality job on your target branch. If there is no report generated from the target branch, your MR branch reports have nothing to compare to. In this situation you will see an error stating `Base pipeline codequality artifact not found`.
-- If no [degradation or error is detected](https://docs.codeclimate.com/docs/maintainability#section-checks),
-  nothing is displayed.
-- The [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in) CI/CD
-  setting can cause the Code Quality artifacts to expire faster than desired.
-- The widgets use the pipeline of the latest commit to the target branch. If commits are made to the default branch that do not run the code quality job, this may cause the merge request widget to have no base report for comparison.
-- If you use the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables), no report file is generated and nothing displays in the merge request.
-- Large `gl-code-quality-report.json` files (esp. >10 MB) are [known to prevent the report from being displayed](https://gitlab.com/gitlab-org/gitlab/-/issues/2737).
-  As a work-around, try removing [properties](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#data-types)
-  that are [ignored by GitLab](#implementing-a-custom-tool). You can:
-  - Configure the Code Quality tool to not output those types.
-  - Use `sed`, `awk` or similar commands in the `.gitlab-ci.yml` script to
-    edit the `gl-code-quality-report.json` before the job completes.
-
-### Only a single Code Quality report is displayed, but more are defined
-
-GitLab only uses the Code Quality artifact from the latest created job (with the largest job ID).
-If multiple jobs in a pipeline generate a code quality artifact, those of earlier jobs are ignored.
-To avoid confusion, configure only one job to generate a `gl-code-quality-report.json`.
-
-### RuboCop errors
-
-When using Code Quality jobs on a Ruby project, you can encounter problems running RuboCop.
-For example, the following error can appear when using either a very recent or very old version
-of Ruby:
-
-```plaintext
-/usr/local/bundle/gems/rubocop-0.52.1/lib/rubocop/config.rb:510:in `check_target_ruby':
-Unknown Ruby version 2.7 found in `.ruby-version`. (RuboCop::ValidationError)
-Supported versions: 2.1, 2.2, 2.3, 2.4, 2.5
-```
-
-This is caused by the default version of RuboCop used by the check engine not covering
-support for the Ruby version in use.
-
-To use a custom version of RuboCop that
-[supports the version of Ruby used by the project](https://docs.rubocop.org/rubocop/compatibility.html#support-matrix),
-you can [override the configuration through a `.codeclimate.yml` file](https://docs.codeclimate.com/docs/rubocop#using-rubocops-newer-versions)
-created in the project repository.
-
-For example, to specify using RuboCop release **0.67**:
-
-```yaml
-version: "2"
-plugins:
-  rubocop:
-    enabled: true
-    channel: rubocop-0-67
-```
-
-### No Code Quality appears on merge requests when using custom tool
-
-If your merge requests do not show any code quality changes when using a custom tool,
-ensure that the line property is an `integer`.
-
-### Code Quality CI job with Code Climate plugins enabled fails with error
-
-If you enabled any of the Code Climate plugins, and the Code Quality CI job fails with the error
-below, it's likely the job takes longer than the default timeout of 900 seconds:
-
-```shell
-error: (CC::CLI::Analyze::EngineFailure) engine pmd ran for 900 seconds and was killed
-Could not analyze code quality for the repository at /code
-```
-
-To work around this problem, set `TIMEOUT_SECONDS` to a higher value in your `.gitlab.-ci.yml` file.
-
-For example:
-
-```yaml
-variables:
-  TIMEOUT_SECONDS: 3600
-```
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/merge_requests/creating_merge_requests.md b/doc/user/project/merge_requests/creating_merge_requests.md
index 6ee02238a22..f30b20e9d34 100644
--- a/doc/user/project/merge_requests/creating_merge_requests.md
+++ b/doc/user/project/merge_requests/creating_merge_requests.md
@@ -104,7 +104,7 @@ You can create a merge request from your fork to contribute back to the main pro
 After your work is merged, if you don't intend to
 make any other contributions to the upstream project, you can unlink your
 fork from its upstream project. Go to **Settings > Advanced Settings** and
-[remove the forking relationship](../settings/index.md#removing-a-fork-relationship).
+[remove the forking relationship](../settings/index.md#remove-a-fork-relationship).
 
 For more information, [see the forking workflow documentation](../repository/forking_workflow.md).
 
diff --git a/doc/user/project/merge_requests/csv_export.md b/doc/user/project/merge_requests/csv_export.md
index aaa9bec945f..2adcc4d4575 100644
--- a/doc/user/project/merge_requests/csv_export.md
+++ b/doc/user/project/merge_requests/csv_export.md
@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Exporting merge requests CSV enables you and your team to export all the data collected from merge requests into a comma-separated values (CSV) file, which stores tabular data in plain text.
 
-To export merge requests to CSV, navigate to your **Merge requests** from the sidebar of a project and select **Export to CSV**.
+To export merge requests to CSV, navigate to your **Merge requests** from the sidebar of a project and select **Export as CSV**.
 
 ## CSV Output
 
diff --git a/doc/user/project/merge_requests/drafts.md b/doc/user/project/merge_requests/drafts.md
index 13cc68f02dd..4bb6034c0bd 100644
--- a/doc/user/project/merge_requests/drafts.md
+++ b/doc/user/project/merge_requests/drafts.md
@@ -75,12 +75,10 @@ draft merge requests:
 
 ## Pipelines for drafts
 
-When the [merged results pipelines](../../../ci/pipelines/merged_results_pipelines.md)
-feature is enabled, draft merge requests run
-[merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md) only.
+Draft merge requests run the same pipelines as merge request that are marked as ready.
 
-To run merged results pipelines, you must
-[mark the merge request as ready](#mark-merge-requests-as-ready).
+In GitLab 15.0 and older, you must [mark the merge request as ready](#mark-merge-requests-as-ready)
+if you want to run [merged results pipelines](../../../ci/pipelines/merged_results_pipelines.md).
 
 <!-- ## Troubleshooting
 
diff --git a/doc/user/project/merge_requests/fail_fast_testing.md b/doc/user/project/merge_requests/fail_fast_testing.md
index 355661516a7..c09a7c14c06 100644
--- a/doc/user/project/merge_requests/fail_fast_testing.md
+++ b/doc/user/project/merge_requests/fail_fast_testing.md
@@ -1,97 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Insights
-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
+redirect_to: '../../../ci/testing/fail_fast_testing.md'
+remove_date: '2022-08-31'
 ---
 
-# Fail Fast Testing **(PREMIUM)**
+This document was moved to [another location](../../../ci/testing/fail_fast_testing.md).
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/198550) in GitLab 13.1.
-
-For applications that use RSpec for running tests, we've introduced the `Verify/Failfast`
-[template to run subsets of your test suite](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Verify/FailFast.gitlab-ci.yml),
-based on the changes in your merge request.
-
-The template uses the [test_file_finder (`tff`) gem](https://gitlab.com/gitlab-org/ci-cd/test_file_finder/)
-that accepts a list of files as input, and returns a list of spec (test) files
-that it believes to be relevant to the input files.
-
-`tff` is designed for Ruby on Rails projects, so the `Verify/FailFast` template is
-configured to run when changes to Ruby files are detected. By default, it runs in
-the [`.pre` stage](../../../ci/yaml/index.md#stage-pre) of a GitLab CI/CD pipeline,
-before all other stages.
-
-## Example use case
-
-Fail fast testing is useful when adding new functionality to a project and adding
-new automated tests.
-
-Your project could have hundreds of thousands of tests that take a long time to complete.
-You may be confident that a new test will pass, but you have to wait for all the tests
-to complete to verify it. This could take an hour or more, even when using parallelization.
-
-Fail fast testing gives you a faster feedback loop from the pipeline. It lets you
-know quickly that the new tests are passing and the new functionality did not break
-other tests.
-
-## Requirements
-
-This template requires:
-
-- A project built in Rails that uses RSpec for testing.
-- CI/CD configured to:
-  - Use a Docker image with Ruby available.
-  - Use [Merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md#prerequisites)
-- [Merged results pipelines](../../../ci/pipelines/merged_results_pipelines.md#enable-merged-results-pipelines)
-  enabled in the project settings.
-- A Docker image with Ruby available. The template uses `image: ruby:2.6` by default, but you [can override](../../../ci/yaml/includes.md#override-included-configuration-values) this.
-
-## Configuring Fast RSpec Failure
-
-We use the following plain RSpec configuration as a starting point. It installs all the
-project gems and executes `rspec`, on merge request pipelines only.
-
-```yaml
-rspec-complete:
-  stage: test
-  rules:
-    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
-  script:
-    - bundle install
-    - bundle exec rspec
-```
-
-To run the most relevant specs first instead of the whole suite, [`include`](../../../ci/yaml/index.md#include)
-the template by adding the following to your CI/CD configuration:
-
-```yaml
-include:
-  - template: Verify/FailFast.gitlab-ci.yml
-```
-
-To customize the job, specific options may be set to override the template. For example, to override the default Docker image:
-
-```yaml
-include:
-  - template: Verify/FailFast.gitlab-ci.yml
-
-rspec-rails-modified-path-specs:
-  image: custom-docker-image-with-ruby
-```
-
-### Example test loads
-
-For illustrative purposes, let's say our Rails app spec suite consists of 100 specs per model for ten models.
-
-If no Ruby files are changed:
-
-- `rspec-rails-modified-paths-specs` does not run any tests.
-- `rspec-complete` runs the full suite of 1000 tests.
-
-If one Ruby model is changed, for example `app/models/example.rb`, then `rspec-rails-modified-paths-specs`
-runs the 100 tests for `example.rb`:
-
-- If all of these 100 tests pass, then the full `rspec-complete` suite of 1000 tests is allowed to run.
-- If any of these 100 tests fail, they fail quickly, and `rspec-complete` does not run any tests.
-
-The final case saves resources and time as the full 1000 test suite does not run.
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/merge_requests/img/accessibility_mr_widget_v13_0.png b/doc/user/project/merge_requests/img/accessibility_mr_widget_v13_0.png
deleted file mode 100644
index 4ada7e25b65..00000000000
--- a/doc/user/project/merge_requests/img/accessibility_mr_widget_v13_0.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/attention_request_list_v14_10.png b/doc/user/project/merge_requests/img/attention_request_list_v14_10.png
deleted file mode 100644
index 00427a0aa40..00000000000
--- a/doc/user/project/merge_requests/img/attention_request_list_v14_10.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/attention_request_sidebar_v14_10.png b/doc/user/project/merge_requests/img/attention_request_sidebar_v14_10.png
deleted file mode 100644
index 174cf01dbb0..00000000000
--- a/doc/user/project/merge_requests/img/attention_request_sidebar_v14_10.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/browser_performance_testing.png b/doc/user/project/merge_requests/img/browser_performance_testing.png
deleted file mode 100644
index a3d7022bcfc..00000000000
--- a/doc/user/project/merge_requests/img/browser_performance_testing.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/code_quality_host_bound_sequential.png b/doc/user/project/merge_requests/img/code_quality_host_bound_sequential.png
deleted file mode 100644
index 2b31f3b42ee..00000000000
--- a/doc/user/project/merge_requests/img/code_quality_host_bound_sequential.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/code_quality_mr_diff_report_v14_2.png b/doc/user/project/merge_requests/img/code_quality_mr_diff_report_v14_2.png
deleted file mode 100644
index c1e9aad24ac..00000000000
--- a/doc/user/project/merge_requests/img/code_quality_mr_diff_report_v14_2.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/code_quality_report_13_11.png b/doc/user/project/merge_requests/img/code_quality_report_13_11.png
deleted file mode 100644
index 36341548328..00000000000
--- a/doc/user/project/merge_requests/img/code_quality_report_13_11.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/code_quality_widget_13_11.png b/doc/user/project/merge_requests/img/code_quality_widget_13_11.png
deleted file mode 100644
index 57978a0ed96..00000000000
--- a/doc/user/project/merge_requests/img/code_quality_widget_13_11.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/load_performance_testing.png b/doc/user/project/merge_requests/img/load_performance_testing.png
deleted file mode 100644
index d5623867ee7..00000000000
--- a/doc/user/project/merge_requests/img/load_performance_testing.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/merge_method_ff_v15_0.png b/doc/user/project/merge_requests/img/merge_method_ff_v15_0.png
deleted file mode 100644
index 323fd03ffa2..00000000000
--- a/doc/user/project/merge_requests/img/merge_method_ff_v15_0.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/merge_method_merge_commit_v15_0.png b/doc/user/project/merge_requests/img/merge_method_merge_commit_v15_0.png
deleted file mode 100644
index b880c2c0e04..00000000000
--- a/doc/user/project/merge_requests/img/merge_method_merge_commit_v15_0.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/merge_method_merge_commit_with_semi_linear_history_v15_0.png b/doc/user/project/merge_requests/img/merge_method_merge_commit_with_semi_linear_history_v15_0.png
deleted file mode 100644
index 9eab71e9d3c..00000000000
--- a/doc/user/project/merge_requests/img/merge_method_merge_commit_with_semi_linear_history_v15_0.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/test_coverage_visualization_v12_9.png b/doc/user/project/merge_requests/img/test_coverage_visualization_v12_9.png
deleted file mode 100644
index 1922a566dd5..00000000000
--- a/doc/user/project/merge_requests/img/test_coverage_visualization_v12_9.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index 30b69c2fff5..a7a669d3b75 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -251,60 +251,13 @@ This feature works only when a merge request is merged. Selecting **Remove sourc
 after merging does not retarget open merge requests. This improvement is
 [proposed as a follow-up](https://gitlab.com/gitlab-org/gitlab/-/issues/321559).
 
-## Request attention to a merge request
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/343528) in GitLab 14.10 [with a flag](../../../administration/feature_flags.md) named `mr_attention_requests`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `mr_attention_requests`.
-On GitLab.com, this feature is dependent on the enablement status of the feature flag. Refer to the [enablement issue](https://gitlab.com/gitlab-org/gitlab/-/issues/343528) for details.
-
-To tell a merge request's assignee or reviewer that their attention is
-needed on a merge request, you can request their attention. If an assignee or a
-reviewer has their attention requested on a merge request, the **Attention request**
-icon (**{attention}**) is displayed as a solid icon (**{attention-solid}**) on
-the merge request list page:
-
-![Attention request icon](img/attention_request_list_v14_10.png)
-
-To view a list of merge requests that need your attention:
-
-1. On the top bar, select **Merge requests** (**{merge-request}**).
-1. Select **Attention requests**.
-
-To request attention from another user, use the `/attention @user`
-[quick action](../quick_actions.md) or:
-
-1. Go to the merge request.
-1. On the right sidebar, identify the user you want to request attention from.
-1. Next to the user's name, select **Request attention** (**{attention}**), and the appearance
-   of the icon changes:
-
-   ![Attention request toggle](img/attention_request_sidebar_v14_10.png)
-
-### Remove an attention request
-
-If your attention was requested as an assignee or reviewer, it's removed when you:
-
-- Manually remove the attention request by selecting **Remove attention request** (**{attention-solid}**).
-- Approve the merge request.
-- Add a new user as an assignee or reviewer.
-- Request the attention of a different assignee or reviewer.
-- Remove yourself (or are removed by someone else) as an assignee or reviewer.
-- Merge or close the merge request.
-
-If you are both the assignee and a reviewer on a merge request, you receive
-only one attention request, which is synced across both duties. If the
-attention request is removed from you, either as an assignee or a reviewer,
-it is removed from both your duties.
-
 ## Merge request workflows
 
 For a software developer working in a team:
 
 1. You checkout a new branch, and submit your changes through a merge request.
 1. You gather feedback from your team.
-1. You work on the implementation optimizing code with [Code Quality reports](code_quality.md).
+1. You work on the implementation optimizing code with [Code Quality reports](../../../ci/testing/code_quality.md).
 1. You verify your changes with [Unit test reports](../../../ci/testing/unit_test_reports.md) in GitLab CI/CD.
 1. You avoid using dependencies whose license is not compatible with your project with [License Compliance reports](../../compliance/license_compliance/index.md).
 1. You request the [approval](approvals/index.md) from your manager.
diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md
index a5fff4a38be..04b62c5d8fe 100644
--- a/doc/user/project/merge_requests/load_performance_testing.md
+++ b/doc/user/project/merge_requests/load_performance_testing.md
@@ -1,201 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Insights
-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
+redirect_to: '../../../ci/testing/load_performance_testing.md'
+remove_date: '2022-08-31'
 ---
 
-# Load Performance Testing **(PREMIUM)**
+This document was moved to [another location](../../../ci/testing/load_performance_testing.md).
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10683) in GitLab 13.2.
-
-With Load Performance Testing, you can test the impact of any pending code changes
-to your application's backend in [GitLab CI/CD](../../../ci/index.md).
-
-GitLab uses [k6](https://k6.io/), a free and open source
-tool, for measuring the system performance of applications under
-load.
-
-Unlike [Browser Performance Testing](browser_performance_testing.md), which is
-used to measure how web sites perform in client browsers, Load Performance Testing
-can be used to perform various types of [load tests](https://k6.io/docs/#use-cases)
-against application endpoints such as APIs, Web Controllers, and so on.
-This can be used to test how the backend or the server performs at scale.
-
-For example, you can use Load Performance Testing to perform many concurrent
-GET calls to a popular API endpoint in your application to see how it performs.
-
-## How Load Performance Testing works
-
-First, define a job in your `.gitlab-ci.yml` file that generates the
-[Load Performance report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportsload_performance).
-GitLab checks this report, compares key load performance metrics
-between the source and target branches, and then shows the information in a merge request widget:
-
-![Load Performance Widget](img/load_performance_testing.png)
-
-Next, you need to configure the test environment and write the k6 test.
-
-The key performance metrics that the merge request widget shows after the test completes are:
-
-- Checks: The percentage pass rate of the [checks](https://k6.io/docs/using-k6/checks) configured in the k6 test.
-- TTFB P90: The 90th percentile of how long it took to start receiving responses, aka the [Time to First Byte](https://en.wikipedia.org/wiki/Time_to_first_byte) (TTFB).
-- TTFB P95: The 95th percentile for TTFB.
-- RPS: The average requests per second (RPS) rate the test was able to achieve.
-
-NOTE:
-If the Load Performance report has no data to compare, such as when you add the
-Load Performance job in your `.gitlab-ci.yml` for the very first time,
-the Load Performance report widget doesn't display. It must have run at least
-once on the target branch (`main`, for example), before it displays in a
-merge request targeting that branch.
-
-## Configure the Load Performance Testing job
-
-Configuring your Load Performance Testing job can be broken down into several distinct parts:
-
-- Determine the test parameters such as throughput, and so on.
-- Set up the target test environment for load performance testing.
-- Design and write the k6 test.
-
-### Determine the test parameters
-
-The first thing you need to do is determine the [type of load test](https://k6.io/docs/test-types/introduction)
-you want to run, and how it will run (for example, the number of users, throughput, and so on).
-
-Refer to the [k6 docs](https://k6.io/docs/), especially the [k6 testing guides](https://k6.io/docs/testing-guides),
-for guidance on the above and more.
-
-### Test Environment setup
-
-A large part of the effort around load performance testing is to prepare the target test environment
-for high loads. You should ensure it's able to handle the
-[throughput](https://k6.io/blog/monthly-visits-concurrent-users) it will be tested with.
-
-It's also typically required to have representative test data in the target environment
-for the load performance test to use.
-
-We strongly recommend [not running these tests against a production environment](https://k6.io/our-beliefs#load-test-in-a-pre-production-environment).
-
-### Write the load performance test
-
-After the environment is prepared, you can write the k6 test itself. k6 is a flexible
-tool and can be used to run [many kinds of performance tests](https://k6.io/docs/test-types/introduction).
-Refer to the [k6 documentation](https://k6.io/docs/) for detailed information on how to write tests.
-
-### Configure the test in GitLab CI/CD
-
-When your k6 test is ready, the next step is to configure the load performance
-testing job in GitLab CI/CD. The easiest way to do this is to use the
-[`Verify/Load-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Verify/Load-Performance-Testing.gitlab-ci.yml)
-template that is included with GitLab.
-
-NOTE:
-For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
-test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
-for spec details. The [default shared GitLab.com runners](../../../ci/runners/saas/linux_saas_runner.md)
-likely have insufficient specs to handle most large k6 tests.
-
-This template runs the
-[k6 Docker container](https://hub.docker.com/r/loadimpact/k6/) in the job and provides several ways to customize the
-job.
-
-An example configuration workflow:
-
-1. Set up GitLab Runner to run Docker containers, like the
-   [Docker-in-Docker workflow](../../../ci/docker/using_docker_build.md#use-docker-in-docker).
-1. Configure the default Load Performance Testing CI/CD job in your `.gitlab-ci.yml` file.
-   You need to include the template and configure it with CI/CD variables:
-
-   ```yaml
-   include:
-     template: Verify/Load-Performance-Testing.gitlab-ci.yml
-
-   load_performance:
-     variables:
-       K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
-   ```
-
-The above example creates a `load_performance` job in your CI/CD pipeline that runs
-the k6 test.
-
-NOTE:
-For Kubernetes setups a different template should be used: [`Jobs/Load-Performance-Testing.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Load-Performance-Testing.gitlab-ci.yml).
-
-k6 has [various options](https://k6.io/docs/using-k6/options) to configure how it will run tests, such as what throughput (RPS) to run with,
-how long the test should run, and so on. Almost all options can be configured in the test itself, but as
-you can also pass command line options via the `K6_OPTIONS` variable.
-
-For example, you can override the duration of the test with a CLI option:
-
-```yaml
-  include:
-    template: Verify/Load-Performance-Testing.gitlab-ci.yml
-
-  load_performance:
-    variables:
-      K6_TEST_FILE: <PATH TO K6 TEST FILE IN PROJECT>
-      K6_OPTIONS: '--duration 30s'
-```
-
-GitLab only displays the key performance metrics in the MR widget if k6's results are saved
-via [summary export](https://k6.io/docs/results-visualization/json#summary-export)
-as a [Load Performance report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportsload_performance).
-The latest Load Performance artifact available is always used, using the
-summary values from the test.
-
-If [GitLab Pages](../pages/index.md) is enabled, you can view the report directly in your browser.
-
-### Load Performance testing in Review Apps
-
-The CI/CD YAML configuration example above works for testing against static environments,
-but it can be extended to work with [review apps](../../../ci/review_apps) or
-[dynamic environments](../../../ci/environments) with a few extra steps.
-
-The best approach is to capture the dynamic URL in a [`.env` file](https://docs.docker.com/compose/env-file/)
-as a job artifact to be shared, then use a custom CI/CD variable we've provided named `K6_DOCKER_OPTIONS`
-to configure the k6 Docker container to use the file. With this, k6 can then use any
-environment variables from the `.env` file in scripts using standard JavaScript,
-such as: ``http.get(`${__ENV.ENVIRONMENT_URL}`)``.
-
-For example:
-
-1. In the `review` job:
-   1. Capture the dynamic URL and save it into a `.env` file, for example, `echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env`.
-   1. Set the `.env` file to be a [job artifact](../../../ci/pipelines/job_artifacts.md#job-artifacts).
-1. In the `load_performance` job:
-   1. Set it to depend on the review job, so it inherits the environment file.
-   1. Set the `K6_DOCKER_OPTIONS` variable with the [Docker CLI option for environment files](https://docs.docker.com/engine/reference/commandline/run/#set-environment-variables--e---env---env-file), for example `--env-file review.env`.
-1. Configure the k6 test script to use the environment variable in it's steps.
-
-Your `.gitlab-ci.yml` file might be similar to:
-
-```yaml
-stages:
-  - deploy
-  - performance
-
-include:
-  template: Verify/Load-Performance-Testing.gitlab-ci.yml
-
-review:
-  stage: deploy
-  environment:
-    name: review/$CI_COMMIT_REF_SLUG
-    url: http://$CI_ENVIRONMENT_SLUG.example.com
-  script:
-    - run_deploy_script
-    - echo "ENVIRONMENT_URL=$CI_ENVIRONMENT_URL" >> review.env
-  artifacts:
-    paths:
-      - review.env
-  rules:
-    - if: $CI_COMMIT_BRANCH  # Modify to match your pipeline rules, or use `only/except` if needed.
-
-load_performance:
-  dependencies:
-    - review
-  variables:
-    K6_DOCKER_OPTIONS: '--env-file review.env'
-  rules:
-    - if: $CI_COMMIT_BRANCH  # Modify to match your pipeline rules, or use `only/except` if needed.
-```
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/merge_requests/methods/index.md b/doc/user/project/merge_requests/methods/index.md
index d3221162cfd..63b464e5ff4 100644
--- a/doc/user/project/merge_requests/methods/index.md
+++ b/doc/user/project/merge_requests/methods/index.md
@@ -23,7 +23,26 @@ merge requests are merged into an existing branch.
 This setting is the default. It always creates a separate merge commit,
 even when using [squash](../squash_and_merge.md). An example commit graph generated using this merge method:
 
-![Commit graph for merge commits](../img/merge_method_merge_commit_v15_0.png)
+```mermaid
+gitGraph
+  commit id: "Init"
+  branch mr-branch-1
+  commit
+  checkout main
+  commit
+  branch mr-branch-2
+  commit
+  checkout mr-branch-1
+  commit
+  checkout main
+  branch squash-mr
+  commit id: "Squashed commits"
+  checkout main
+  merge squash-mr
+  merge mr-branch-1
+  commit
+  merge mr-branch-2
+```
 
 - For regular merges, it is equivalent to the command `git merge --no-ff <source-branch>`.
 - For squash merges, it squashes all commits in the source branch before merging it normally. It performs actions similar to:
@@ -42,7 +61,25 @@ A merge commit is created for every merge, but the branch is only merged if
 a fast-forward merge is possible. This ensures that if the merge request build
 succeeded, the target branch build also succeeds after the merge. An example commit graph generated using this merge method:
 
-![Commit graph for merge commit with semi-linear history](../img/merge_method_merge_commit_with_semi_linear_history_v15_0.png)
+```mermaid
+gitGraph
+  commit id: "Init"
+  branch mr-branch-1
+  commit
+  commit
+  checkout main
+  merge mr-branch-1
+  branch mr-branch-2
+  commit
+  commit
+  checkout main
+  merge mr-branch-2
+  commit
+  branch squash-mr
+  commit id: "Squashed commits"
+  checkout main
+  merge squash-mr
+```
 
 When you visit the merge request page with `Merge commit with semi-linear history`
 method selected, you can accept it **only if a fast-forward merge is possible**.
@@ -63,7 +100,14 @@ fast-forward merge requests, you can retain a linear Git history and a way
 to accept merge requests without creating merge commits. An example commit graph
 generated using this merge method:
 
-![Commit graph for fast-forward merge](../img/merge_method_ff_v15_0.png)
+```mermaid
+gitGraph
+  commit id: "Init"
+  commit id: "Merge mr-branch-1"
+  commit id: "Merge mr-branch-2"
+  commit id: "Commit on main"
+  commit id: "Merge squash-mr"
+```
 
 This method is equivalent to `git merge --ff <source-branch>` for regular merges, and to
 `git merge -squash <source-branch>` for squash merges.
diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md
index 8f77ce90436..a8f43dd9c02 100644
--- a/doc/user/project/merge_requests/reviews/index.md
+++ b/doc/user/project/merge_requests/reviews/index.md
@@ -112,13 +112,7 @@ This example shows reviewers and approval rules in a merge request sidebar:
 
 ### Request a new review
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/293933) in GitLab 13.9.
-> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/357271) in GitLab 14.10.
-
-WARNING:
-This feature is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/357271)
-in GitLab 14.10, and is planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/357271) in GitLab 15.0.
-Use [attention requests](../index.md#request-attention-to-a-merge-request) instead.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/293933) in GitLab 13.9.
 
 After a reviewer completes their [merge request reviews](../../../discussions/index.md),
 the author of the merge request can request a new review from the reviewer:
diff --git a/doc/user/project/merge_requests/reviews/suggestions.md b/doc/user/project/merge_requests/reviews/suggestions.md
index 7360b57103b..2ff65571c8b 100644
--- a/doc/user/project/merge_requests/reviews/suggestions.md
+++ b/doc/user/project/merge_requests/reviews/suggestions.md
@@ -77,7 +77,7 @@ in four backticks instead of three:
 
 ## Configure the commit message for applied suggestions
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13086) in GitLab 12.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13086) in GitLab 12.7.
 
 GitLab uses a default commit message
 when applying suggestions: `Apply %{suggestions_count} suggestion(s) to %{files_count} file(s)`
diff --git a/doc/user/project/merge_requests/status_checks.md b/doc/user/project/merge_requests/status_checks.md
index 76a67487881..423179325d3 100644
--- a/doc/user/project/merge_requests/status_checks.md
+++ b/doc/user/project/merge_requests/status_checks.md
@@ -138,7 +138,7 @@ the status check and it **will not** be recoverable.
 
 ## Status checks widget
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327634) in GitLab 14.1.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327634) in GitLab 14.1.
 
 The status checks widget displays in merge requests and shows the status of external
 status checks:
diff --git a/doc/user/project/merge_requests/test_coverage_visualization.md b/doc/user/project/merge_requests/test_coverage_visualization.md
index fcbd732f8ee..53d45e6940d 100644
--- a/doc/user/project/merge_requests/test_coverage_visualization.md
+++ b/doc/user/project/merge_requests/test_coverage_visualization.md
@@ -1,441 +1,11 @@
 ---
-stage: Verify
-group: Pipeline Insights
-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
+redirect_to: '../../../ci/testing/test_coverage_visualization.md'
+remove_date: '2022-08-31'
 ---
 
-# Test coverage visualization **(FREE)**
+This document was moved to [another location](../../../ci/testing/test_coverage_visualization.md).
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3708) in GitLab 12.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/249811) in GitLab 13.5.
-
-With the help of [GitLab CI/CD](../../../ci/index.md), you can collect the test
-coverage information of your favorite testing or coverage-analysis tool, and visualize
-this information inside the file diff view of your merge requests (MRs). This will allow you
-to see which lines are covered by tests, and which lines still require coverage, before the
-MR is merged.
-
-![Test Coverage Visualization Diff View](img/test_coverage_visualization_v12_9.png)
-
-## How test coverage visualization works
-
-Collecting the coverage information is done via GitLab CI/CD's
-[artifacts reports feature](../../../ci/yaml/index.md#artifactsreports).
-You can specify one or more coverage reports to collect, including wildcard paths.
-GitLab then takes the coverage information in all the files and combines it
-together. Coverage files are parsed in a background job so there can be a delay
-between pipeline completion and the visualization loading on the page.
-
-For the coverage analysis to work, you have to provide a properly formatted
-[Cobertura XML](https://cobertura.github.io/cobertura/) report to
-[`artifacts:reports:coverage_report`](../../../ci/yaml/artifacts_reports.md#artifactsreportscoverage_report).
-This format was originally developed for Java, but most coverage analysis frameworks
-for other languages have plugins to add support for it, like:
-
-- [simplecov-cobertura](https://rubygems.org/gems/simplecov-cobertura) (Ruby)
-- [gocover-cobertura](https://github.com/boumenot/gocover-cobertura) (Golang)
-
-Other coverage analysis frameworks support the format out of the box, for example:
-
-- [Istanbul](https://istanbul.js.org/docs/advanced/alternative-reporters/#cobertura) (JavaScript)
-- [Coverage.py](https://coverage.readthedocs.io/en/coverage-5.0.4/cmd.html#xml-reporting) (Python)
-- [PHPUnit](https://github.com/sebastianbergmann/phpunit-documentation-english/blob/master/src/textui.rst#command-line-options) (PHP)
-
-Once configured, if you create a merge request that triggers a pipeline which collects
-coverage reports, the coverage is shown in the diff view. This includes reports
-from any job in any stage in the pipeline. The coverage displays for each line:
-
-- `covered` (green): lines which have been checked at least once by tests
-- `no test coverage` (orange): lines which are loaded but never executed
-- no coverage information: lines which are non-instrumented or not loaded
-
-Hovering over the coverage bar provides further information, such as the number
-of times the line was checked by tests.
-
-Uploading a test coverage report does not enable:
-
-- [Test coverage results in merge requests](../../../ci/pipelines/settings.md#merge-request-test-coverage-results).
-- [Code coverage history](../../../ci/pipelines/settings.md#view-code-coverage-history).
-
-You must configure these separately.
-
-### Limits
-
-A limit of 100 `<source>` nodes for Cobertura format XML files applies. If your Cobertura report exceeds
-100 nodes, there can be mismatches or no matches in the merge request diff view.
-
-A single Cobertura XML file can be no more than 10MiB. For large projects, split the Cobertura XML into
-smaller files. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/328772) for more details.
-When submitting many files, it can take a few minutes for coverage to show on a merge request.
-
-The visualization only displays after the pipeline is complete. If the pipeline has
-a [blocking manual job](../../../ci/jobs/job_control.md#types-of-manual-jobs), the
-pipeline waits for the manual job before continuing and is not considered complete.
-The visualization cannot be displayed if the blocking manual job did not run.
-
-### Artifact expiration
-
-By default, the [pipeline artifact](../../../ci/pipelines/pipeline_artifacts.md#storage) used
-to draw the visualization on the merge request expires **one week** after creation.
-
-### Coverage report from child pipeline
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/363301) in GitLab 15.1 [with a flag](../../../administration/feature_flags.md). Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `ci_child_pipeline_coverage_reports`.
-On GitLab.com, this feature is not available.
-The feature is not ready for production use.
-
-If the test coverage is created in jobs that are in a child pipeline, the parent pipeline must use
-`strategy: depend`.
-
-```yaml
-child_test_pipeline:
-  trigger:
-    include:
-      - local: path/to/child_pipeline.yml
-      - template: Security/SAST.gitlab-ci.yml
-    strategy: depend
-```
-
-### Automatic class path correction
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217664) in GitLab 13.8.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/284822) in GitLab 13.9.
-
-The coverage report properly matches changed files only if the `filename` of a `class` element
-contains the full path relative to the project root. However, in some coverage analysis frameworks,
-the generated Cobertura XML has the `filename` path relative to the class package directory instead.
-
-To make an intelligent guess on the project root relative `class` path, the Cobertura XML parser
-attempts to build the full path by:
-
-- Extracting a portion of the `source` paths from the `sources` element and combining them with the
-  class `filename` path.
-- Checking if the candidate path exists in the project.
-- Using the first candidate that matches as the class full path.
-
-#### Path correction example
-
-As an example, a project with:
-
-- A full path of `test-org/test-project`.
-- The following files relative to the project root:
-
-  ```shell
-  Auth/User.cs
-  Lib/Utils/User.cs
-  src/main/java
-  ```
-
-In the:
-
-- Cobertura XML, the `filename` attribute in the `class` element assumes the value is a relative
-  path to the project's root:
-
-  ```xml
-  <class name="packet.name" filename="src/main/java" line-rate="0.0" branch-rate="0.0" complexity="5">
-  ```
-
-- `sources` from Cobertura XML, the following paths in the format
-  `<CI_BUILDS_DIR>/<PROJECT_FULL_PATH>/...`:
-
-  ```xml
-  <sources>
-    <source>/builds/test-org/test-project/Auth</source>
-    <source>/builds/test-org/test-project/Lib/Utils</source>
-  </sources>
-  ```
-
-The parser:
-
-- Extracts `Auth` and `Lib/Utils` from the `sources` and uses these to determine the `class` path
-  relative to the project root.
-- Combines these extracted `sources` and the class filename. For example, if there is a `class`
-  element with the `filename` value of `User.cs`, the parser takes the first candidate path that
-  matches, which is `Auth/User.cs`.
-- For each `class` element, attempts to look for a match for each extracted `source` path up to
-  100 iterations. If it reaches this limit without finding a matching path in the file tree, the
-  class is not included in the final coverage report.
-
-NOTE:
-Automatic class path correction only works on `source` paths in the format `<CI_BUILDS_DIR>/<PROJECT_FULL_PATH>/...`.
-The `source` is ignored if the path does not follow this pattern. The parser assumes that the
-`filename` of a `class` element contains the full path relative to the project root.
-
-## Example test coverage configurations
-
-This section provides test coverage configuration examples for different programming languages. You can also see a working example in
-the [`coverage-report`](https://gitlab.com/gitlab-org/ci-sample-projects/coverage-report/) demonstration project.
-
-### JavaScript example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example uses [Mocha](https://mochajs.org/)
-JavaScript testing and [nyc](https://github.com/istanbuljs/nyc) coverage-tooling to
-generate the coverage artifact:
-
-```yaml
-test:
-  script:
-    - npm install
-    - npx nyc --reporter cobertura mocha
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: coverage/cobertura-coverage.xml
-```
-
-### Java and Kotlin examples
-
-#### Maven example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Maven](https://maven.apache.org/)
-to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to
-generate the coverage artifact.
-You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
-
-GitLab expects the artifact in the Cobertura format, so you have to execute a few
-scripts before uploading it. The `test-jdk11` job tests the code and generates an
-XML artifact. The `coverage-jdk-11` job converts the artifact into a Cobertura report:
-
-```yaml
-test-jdk11:
-  stage: test
-  image: maven:3.6.3-jdk-11
-  script:
-    - mvn $MAVEN_CLI_OPTS clean org.jacoco:jacoco-maven-plugin:prepare-agent test jacoco:report
-  artifacts:
-    paths:
-      - target/site/jacoco/jacoco.xml
-
-coverage-jdk11:
-  # Must be in a stage later than test-jdk11's stage.
-  # The `visualize` stage does not exist by default.
-  # Please define it first, or choose an existing stage like `deploy`.
-  stage: visualize
-  image: registry.gitlab.com/haynes/jacoco2cobertura:1.0.7
-  script:
-    # convert report from jacoco to cobertura, using relative project path
-    - python /opt/cover2cover.py target/site/jacoco/jacoco.xml $CI_PROJECT_DIR/src/main/java/ > target/site/cobertura.xml
-  needs: ["test-jdk11"]
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: target/site/cobertura.xml
-```
-
-#### Gradle example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Java or Kotlin uses [Gradle](https://gradle.org/)
-to build the project and [JaCoCo](https://www.eclemma.org/jacoco/) coverage-tooling to
-generate the coverage artifact.
-You can check the [Docker image configuration and scripts](https://gitlab.com/haynes/jacoco2cobertura) if you want to build your own image.
-
-GitLab expects the artifact in the Cobertura format, so you have to execute a few
-scripts before uploading it. The `test-jdk11` job tests the code and generates an
-XML artifact. The `coverage-jdk-11` job converts the artifact into a Cobertura report:
-
-```yaml
-test-jdk11:
-  stage: test
-  image: gradle:6.6.1-jdk11
-  script:
-    - 'gradle test jacocoTestReport' # jacoco must be configured to create an xml report
-  artifacts:
-    paths:
-      - build/jacoco/jacoco.xml
-
-coverage-jdk11:
-  # Must be in a stage later than test-jdk11's stage.
-  # The `visualize` stage does not exist by default.
-  # Please define it first, or chose an existing stage like `deploy`.
-  stage: visualize
-  image: registry.gitlab.com/haynes/jacoco2cobertura:1.0.7
-  script:
-    # convert report from jacoco to cobertura, using relative project path
-    - python /opt/cover2cover.py build/jacoco/jacoco.xml $CI_PROJECT_DIR/src/main/java/ > build/cobertura.xml
-  needs: ["test-jdk11"]
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: build/cobertura.xml
-```
-
-### Python example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Python uses [pytest-cov](https://pytest-cov.readthedocs.io/) to collect test coverage data and [coverage.py](https://coverage.readthedocs.io/) to convert the report to use full relative paths.
-The information isn't displayed without the conversion.
-
-This example assumes that the code for your package is in `src/` and your tests are in `tests.py`:
-
-```yaml
-run tests:
-  stage: test
-  image: python:3
-  script:
-    - pip install pytest pytest-cov
-    - coverage run -m pytest
-    - coverage report
-    - coverage xml
-  coverage: '/(?i)total.*? (100(?:\.0+)?\%|[1-9]?\d(?:\.\d+)?\%)$/'
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: coverage.xml
-```
-
-### PHP example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for PHP uses [PHPUnit](https://phpunit.readthedocs.io/)
-to collect test coverage data and generate the report.
-
-With a minimal [`phpunit.xml`](https://phpunit.readthedocs.io/en/9.5/configuration.html) file (you may reference
-[this example repository](https://gitlab.com/yookoala/code-coverage-visualization-with-php/)), you can run the test and
-generate the `coverage.xml`:
-
-```yaml
-run tests:
-  stage: test
-  image: php:latest
-  variables:
-    XDEBUG_MODE: coverage
-  before_script:
-    - apt-get update && apt-get -yq install git unzip zip libzip-dev zlib1g-dev
-    - docker-php-ext-install zip
-    - pecl install xdebug && docker-php-ext-enable xdebug
-    - php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
-    - php composer-setup.php --install-dir=/usr/local/bin --filename=composer
-    - composer install
-    - composer require --dev phpunit/phpunit phpunit/php-code-coverage
-  script:
-    - php ./vendor/bin/phpunit --coverage-text --coverage-cobertura=coverage.cobertura.xml
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: coverage.cobertura.xml
-```
-
-[Codeception](https://codeception.com/), through PHPUnit, also supports generating Cobertura report with
-[`run`](https://codeception.com/docs/reference/Commands#run). The path for the generated file
-depends on the `--coverage-cobertura` option and [`paths`](https://codeception.com/docs/reference/Configuration#paths)
-configuration for the [unit test suite](https://codeception.com/docs/05-UnitTests). Configure `.gitlab-ci.yml`
-to find Cobertura in the appropriate path.
-
-### C/C++ example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for C/C++ with
-`gcc` or `g++` as the compiler uses [`gcovr`](https://gcovr.com/en/stable/) to generate the coverage
-output file in Cobertura XML format.
-
-This example assumes:
-
-- That the `Makefile` is created by `cmake` in the `build` directory,
-  within another job in a previous stage.
-  (If you use `automake` to generate the `Makefile`,
-  then you need to call `make check` instead of `make test`.)
-- `cmake` (or `automake`) has set the compiler option `--coverage`.
-
-```yaml
-run tests:
-  stage: test
-  script:
-    - cd build
-    - make test
-    - gcovr --xml-pretty --exclude-unreachable-branches --print-summary -o coverage.xml --root ${CI_PROJECT_DIR}
-  coverage: /^\s*lines:\s*\d+.\d+\%/
-  artifacts:
-    name: ${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}-${CI_COMMIT_SHA}
-    expire_in: 2 days
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: build/coverage.xml
-```
-
-### Go example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Go uses:
-
-- [`go test`](https://go.dev/doc/tutorial/add-a-test) to run tests.
-- [`gocover-cobertura`](https://github.com/boumenot/gocover-cobertura) to convert Go's coverage profile into the Cobertura XML format.
-
-This example assumes that [Go modules](https://go.dev/ref/mod)
-are being used. Please note that the `-covermode count` option does not work with the `-race` flag.
-If you want to generate code coverage while also using the `-race` flag, you must switch to
-`-covermode atomic` which is slower than `-covermode count`. See [this blog post](https://go.dev/blog/cover)
-for more details.
-
-```yaml
-run tests:
-  stage: test
-  image: golang:1.17
-  script:
-    - go install
-    - go test ./... -coverprofile=coverage.txt -covermode count
-    - go get github.com/boumenot/gocover-cobertura
-    - go run github.com/boumenot/gocover-cobertura < coverage.txt > coverage.xml
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: coverage.xml
-```
-
-### Ruby example
-
-The following [`.gitlab-ci.yml`](../../../ci/yaml/index.md) example for Ruby uses
-
-- [`rspec`](https://rspec.info/) to run tests.
-- [`simplecov`](https://github.com/simplecov-ruby/simplecov) and [`simplecov-cobertura`](https://github.com/dashingrocket/simplecov-cobertura)
-  to record the coverage profile and create a report in the Cobertura XML format.
-
-This example assumes:
-
-- That [`bundler`](https://bundler.io/) is being used for dependency management.
-  The `rspec`, `simplecov` and `simplecov-cobertura` gems have been added to your `Gemfile`.
-- The `CoberturaFormatter` has been added to your `SimpleCov.formatters`
-  configuration within the `spec_helper.rb` file.
-
-```yaml
-run tests:
-  stage: test
-  image: ruby:3.1
-  script:
-    - bundle install
-    - bundle exec rspec
-  artifacts:
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: coverage/coverage.xml
-```
-
-## Troubleshooting
-
-### Test coverage visualization not displayed
-
-If the test coverage visualization is not displayed in the diff view, you can check
-the coverage report itself and verify that:
-
-- The file you are viewing in the diff view is mentioned in the coverage report.
-- The `source` and `filename` nodes in the report follows the [expected structure](#automatic-class-path-correction)
-  to match the files in your repository.
-
-Report artifacts are not downloadable by default. If you want the report to be downloadable
-from the job details page, add your coverage report to the artifact `paths`:
-
-```yaml
-artifacts:
-  paths:
-    - coverage/cobertura-coverage.xml
-  reports:
-    coverage_report:
-      coverage_format: cobertura
-      path: coverage/cobertura-coverage.xml
-```
+<!-- This redirect file can be deleted after <2022-09-22>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/project/milestones/burndown_and_burnup_charts.md b/doc/user/project/milestones/burndown_and_burnup_charts.md
index d6fcd9fbb16..0f36747a547 100644
--- a/doc/user/project/milestones/burndown_and_burnup_charts.md
+++ b/doc/user/project/milestones/burndown_and_burnup_charts.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 [Burndown](#burndown-charts) and [burnup](#burnup-charts) charts show the progress of completing a milestone.
 
-![burndown and burnup chart](img/burndown_and_burnup_charts_v15_1.png)
+![burndown and burnup chart](img/burndown_and_burnup_charts_v15_3.png)
 
 ## Burndown charts
 
@@ -19,7 +19,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Burndown charts show the number of issues over the course of a milestone.
 
-![burndown chart](img/burndown_chart_v15_1.png)
+![burndown chart](img/burndown_chart_v15_3.png)
 
 At a glance, you see the current state for the completion a given milestone.
 Without them, you would have to organize the data from the milestone and plot it
@@ -66,7 +66,7 @@ A burndown chart is available for every project or group milestone that has been
 date** and a **due date**.
 
 NOTE:
-You're able to [promote project](index.md#promoting-project-milestones-to-group-milestones) to group milestones and still see the **burndown chart** for them, respecting license limitations.
+You're able to [promote project](index.md#promote-a-project-milestone-to-a-group-milestone) to group milestones and still see the **burndown chart** for them, respecting license limitations.
 
 The chart indicates the project's progress throughout that milestone (for issues assigned to it).
 
@@ -106,7 +106,7 @@ Reopened issues are considered as having been opened on the day after they were
 
 Burnup charts show the assigned and completed work for a milestone.
 
-![burnup chart](img/burnup_chart_v15_1.png)
+![burnup chart](img/burnup_chart_v15_3.png)
 
 To view a project's burnup chart:
 
diff --git a/doc/user/project/milestones/img/burndown_and_burnup_charts_v15_1.png b/doc/user/project/milestones/img/burndown_and_burnup_charts_v15_1.png
deleted file mode 100644
index 58c0ddf892f..00000000000
--- a/doc/user/project/milestones/img/burndown_and_burnup_charts_v15_1.png
+++ /dev/null
diff --git a/doc/user/project/milestones/img/burndown_and_burnup_charts_v15_3.png b/doc/user/project/milestones/img/burndown_and_burnup_charts_v15_3.png
new file mode 100644
index 00000000000..1420123500c
--- /dev/null
+++ b/doc/user/project/milestones/img/burndown_and_burnup_charts_v15_3.png
diff --git a/doc/user/project/milestones/img/burndown_chart_v15_1.png b/doc/user/project/milestones/img/burndown_chart_v15_1.png
deleted file mode 100644
index 2953380292d..00000000000
--- a/doc/user/project/milestones/img/burndown_chart_v15_1.png
+++ /dev/null
diff --git a/doc/user/project/milestones/img/burndown_chart_v15_3.png b/doc/user/project/milestones/img/burndown_chart_v15_3.png
new file mode 100644
index 00000000000..9e1c7ccd4dd
--- /dev/null
+++ b/doc/user/project/milestones/img/burndown_chart_v15_3.png
diff --git a/doc/user/project/milestones/img/burnup_chart_v15_1.png b/doc/user/project/milestones/img/burnup_chart_v15_1.png
deleted file mode 100644
index e89b76344ed..00000000000
--- a/doc/user/project/milestones/img/burnup_chart_v15_1.png
+++ /dev/null
diff --git a/doc/user/project/milestones/img/burnup_chart_v15_3.png b/doc/user/project/milestones/img/burnup_chart_v15_3.png
new file mode 100644
index 00000000000..2e85c0abe87
--- /dev/null
+++ b/doc/user/project/milestones/img/burnup_chart_v15_3.png
diff --git a/doc/user/project/milestones/img/milestones_promote_milestone.png b/doc/user/project/milestones/img/milestones_promote_milestone.png
deleted file mode 100644
index 2ef85c5951d..00000000000
--- a/doc/user/project/milestones/img/milestones_promote_milestone.png
+++ /dev/null
diff --git a/doc/user/project/milestones/index.md b/doc/user/project/milestones/index.md
index b0f3179961d..ba48876d4fd 100644
--- a/doc/user/project/milestones/index.md
+++ b/doc/user/project/milestones/index.md
@@ -23,87 +23,127 @@ Additionally, you can integrate milestones with the [Releases feature](../releas
 
 ## Project milestones and group milestones
 
-You can assign **project milestones** to issues or merge requests in that project only.
-To view the project milestone list, in a project, go to **{issues}** **Issues > Milestones**.
+A milestone can belong to [project](../index.md) or [group](../../group/index.md).
 
+You can assign **project milestones** to issues or merge requests in that project only.
 You can assign **group milestones** to any issue or merge request of any project in that group.
-To view the group milestone list, in a group, go to **{issues}** **Issues > Milestones**.
-
-You can also view all milestones you have access to in the dashboard milestones list.
-To view both project milestones and group milestones you have access to, select **Menu > Milestones**
-on the top bar.
 
 For information about project and group milestones API, see:
 
 - [Project Milestones API](../../../api/milestones.md)
 - [Group Milestones API](../../../api/group_milestones.md)
 
-NOTE:
-If you're in a group and select **Issues > Milestones**, GitLab displays group milestones
-and the milestones of projects in this group.
-If you're in a project and select **Issues > Milestones**, GitLab displays only this project's milestones.
+### View project or group milestones
+
+To view the milestone list:
+
+1. On the top bar, select **Menu > Projects** and find your project or
+   **Menu > Groups** and find your group.
+1. Select **Issues > Milestones**.
+
+In a project, GitLab displays milestones that belong to the project.
+In a group, GitLab displays milestones that belong to the group and all projects in the group.
+
+### View all milestones
 
-## Creating milestones
+You can view all the milestones you have access to in the entire GitLab namespace.
+You might not see some milestones because they're in projects or groups you're not a member of.
+
+To do so, on the top bar select **Menu > Milestones**.
+
+## Create a milestone
 
 > [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
 
-Milestones can be created either at project or group level.
+You can create a milestone either in a project or a group.
 
 Prerequisites:
 
-- You must have at least the Reporter role for a group.
+- You must have at least the Reporter role for the project or group the milestone belongs to.
 
 To create a milestone:
 
 1. On the top bar, select **Menu > Projects** and find your project or **Menu > Groups** and find your group.
 1. On the left sidebar, select **Issues > Milestones**.
 1. Select **New milestone**.
-1. Enter the title, an optional description, an optional start date, and an optional due date.
+1. Enter the title.
+1. Optional. Enter description, start date, and due date.
 1. Select **New milestone**.
 
 ![New milestone](img/milestones_new_project_milestone.png)
 
-## Editing milestones
+## Edit a milestone
 
 > [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
 
-Users with at least the Reporter role can edit milestones.
-
 Prerequisites:
 
-- You must have at least the Reporter role for a group.
+- You must have at least the Reporter role for the project or group the milestone belongs to.
 
 To edit a milestone:
 
-1. In a project or group, go to **{issues}** **Issues > Milestones**.
+1. On the top bar, select **Menu > Projects** and find your project or **Menu > Groups** and find your group.
 1. Select a milestone's title.
 1. Select **Edit**.
+1. Edit the title, start date, due date, or description.
+1. Select **Save changes**.
+
+## Delete a milestone
+
+> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/343889) the minimum user role from Developer to Reporter in GitLab 15.0.
 
-You can delete a milestone by selecting the **Delete** button.
+Prerequisites:
+
+- You must have at least the Reporter role for the project or group the milestone belongs to.
+
+To edit a milestone:
+
+1. On the top bar, select **Menu > Projects** and find your project or **Menu > Groups** and find your group.
+1. Select a milestone's title.
+1. Select **Delete**.
+1. Select **Delete milestone**.
 
-### Promoting project milestones to group milestones
+## Promote a project milestone to a group milestone
 
 If you are expanding the number of projects in a group, you might want to share the same milestones
-among this group's projects. You can also promote project milestones to group milestones in order to
+among this group's projects. You can also promote project milestones to group milestones to
 make them available to other projects in the same group.
 
-From the project milestone list page, you can promote a project milestone to a group milestone.
-This merges all project milestones across all projects in this group with the same name into a single
-group milestones. All issues and merge requests that were previously assigned to one of these project
-milestones is assigned the new group milestones. This action cannot be reversed and the changes are
-permanent.
+Promoting a milestone merges all project milestones across all projects in this group with the same
+name into a single group milestone.
+All issues and merge requests that were previously assigned to one of these project
+milestones become assigned to the new group milestone.
 
 WARNING:
-From GitLab 12.4 and earlier, some information is lost when you promote a project milestone to a
-group milestone. Not all features on the project milestone view are available on the group milestone
-view. If you promote a project milestone to a group milestone, you lose these features. Visit
-[Milestone view](#milestone-view) to learn which features are missing from the group milestone view.
+This action cannot be reversed and the changes are permanent.
+
+Prerequisites:
+
+- You must have at least the Reporter role for the group.
+
+To promote a project milestone:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. Either:
+   - Select **Promote to Group Milestone** (**{level-up}**).
+   - Select the milestone title, and then select **Promote**.
+1. Select **Promote Milestone**.
+
+## Assign a milestone to an issue or merge request
+
+Every issue and merge request can be assigned one milestone.
+The milestones are visible on every issue and merge request page, on the right sidebar.
+They are also visible in the issue board.
 
-![Promote milestone](img/milestones_promote_milestone.png)
+To assign or unassign a milestone:
 
-## Assigning milestones from the sidebar
+1. View an issue or a merge request.
+1. On the right sidebar, next to **Milestones**, select **Edit**.
+1. In the **Assign milestone** list, search for a milestone by typing its name.
+   You can select from both project and group milestones.
+1. Select the milestone you want to assign.
 
-Every issue and merge request can be assigned a milestone. The milestones are visible on every issue and merge request page, in the sidebar. They are also visible in the issue board. From the sidebar, you can assign or unassign a milestones to the object. You can also perform this as a [quick action](../quick_actions.md) in a comment. [As mentioned](#project-milestones-and-group-milestones), for a given issue or merge request, both project milestones and group milestones can be selected and assigned to the object.
+You can also use the `/assign` [quick action](../quick_actions.md) in a comment.
 
 ## Filtering issues and merge requests by milestone
 
@@ -156,7 +196,7 @@ There are also tabs below these that show the following:
 The milestone view contains a [burndown and burnup chart](burndown_and_burnup_charts.md),
 showing the progress of completing a milestone.
 
-![burndown chart](img/burndown_and_burnup_charts_v15_1.png)
+![burndown chart](img/burndown_and_burnup_charts_v15_3.png)
 
 ### Milestone sidebar
 
diff --git a/doc/user/project/pages/redirects.md b/doc/user/project/pages/redirects.md
index 791b6a1550a..5d03db4bf00 100644
--- a/doc/user/project/pages/redirects.md
+++ b/doc/user/project/pages/redirects.md
@@ -45,8 +45,9 @@ Note that:
 
 - All paths must start with a forward slash `/`.
 - A default status code of `301` is applied if no [status code](#http-status-codes) is provided.
-- The `_redirects` file has a file size limit of 64KB and a maximum of 1,000 rules per project.
-  Only the first 1,000 rules are processed.
+- The `_redirects` file has a file size limit and a maximum number of rules per project,
+  configured at the instance level. Only the first matching rules within the configured maximum are processed.
+  The default file size limit is 64KB, and the default maximum number of rules is 1,000.
 - If your GitLab Pages site uses the default domain name (such as
   `namespace.gitlab.io/projectname`) you must prefix every rule with the project name:
 
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index d5a7058d3d2..96e51b061ee 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -55,7 +55,6 @@ threads. Some quick actions might not be available to all subscription tiers.
 | `/assign me`                                                                                     | **{check-circle}** Yes | **{check-circle}** Yes | **{dotted-circle}** No | Assign yourself.                                                                                                                                                                                                                                                                                                                                                                                                                                          |
 | `/assign_reviewer @user1 @user2` or `/reviewer @user1 @user2` or `/request_review @user1 @user2` | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Assign one or more users as reviewers.                                                                                                                                                                                                                                                                                                                                                                                                                    |
 | `/assign_reviewer me` or `/reviewer me` or `/request_review me`                                  | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Assign yourself as a reviewer.                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| `/attention @user1`                                                                                 | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | [Request attention](merge_requests/index.md#request-attention-to-a-merge-request) to a merge request from a user. |
 | `/award :emoji:`                                                                                 | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Toggle emoji award.                                                                                                                                                                                                                                                                                                                                                                                                                                       |
 | `/child_epic <epic>`                                                                             | **{dotted-circle}** No | **{dotted-circle}** No | **{check-circle}** Yes | Add child epic to `<epic>`. The `<epic>` value should be in the format of `&epic`, `group&epic`, or a URL to an epic ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7330) in GitLab 12.0).                                                                                                                                                                                                                                                   |
 | `/clear_health_status`                                                                           | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Clear [health status](issues/managing_issues.md#health-status) ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213814) in GitLab 14.7).                                                                                                                                                                                                                                                                                                       |
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index d5ddc0468e1..1d448ca5c94 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -210,7 +210,7 @@ In the second workflow, the `release` job runs in multiple pipelines. To prevent
 ```yaml
 release_job:
   rules:
-    - if: $CI_COMMIT_TAG  
+    - if: $CI_COMMIT_TAG
       when: never                                  # Do not run this job in a tag pipeline
     - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Run this job when commits are pushed or merged to the default branch
   script:
@@ -317,6 +317,25 @@ You can edit the release title, notes, associated milestones, and asset links.
 To change the release date use the
 [Releases API](../../../api/releases/index.md#update-a-release).
 
+## Delete a release
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213862) in GitLab 15.2
+
+When you delete a release, its assets are also deleted. However, the associated
+Git tag is not deleted.
+
+Prerequisites:
+
+- You must have at least the Developer role. Read more about [Release permissions](#release-permissions).
+
+To delete a release in the UI:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Deployments > Releases**.
+1. In the top-right corner of the release you want to delete, select **Edit this release** (**{pencil}**).
+1. On the **Edit Release** page, select **Delete**.
+1. Select **Delete release**.
+
 ## Associate milestones with a release
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/29020) in GitLab 12.5.
diff --git a/doc/user/project/repository/branches/default.md b/doc/user/project/repository/branches/default.md
index e087ed6c439..747da817195 100644
--- a/doc/user/project/repository/branches/default.md
+++ b/doc/user/project/repository/branches/default.md
@@ -76,7 +76,7 @@ overrides it.
 
 ### Group-level custom initial branch name
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221014) in GitLab 13.6.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221014) in GitLab 13.6.
 
 Users with at least the Owner role of groups and subgroups can configure the default branch name for a group:
 
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index 0e6c98457c7..85bea80f777 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -68,4 +68,4 @@ changes are added to the repository and branch you're merging into.
 
 ## Removing a fork relationship
 
-You can unlink your fork from its upstream project in the [advanced settings](../settings/index.md#removing-a-fork-relationship).
+You can unlink your fork from its upstream project in the [advanced settings](../settings/index.md#remove-a-fork-relationship).
diff --git a/doc/user/project/repository/img/repository_languages_v12_2.gif b/doc/user/project/repository/img/repository_languages_v12_2.gif
deleted file mode 100644
index d0a0e57c919..00000000000
--- a/doc/user/project/repository/img/repository_languages_v12_2.gif
+++ /dev/null
diff --git a/doc/user/project/repository/img/repository_languages_v15_2.png b/doc/user/project/repository/img/repository_languages_v15_2.png
new file mode 100644
index 00000000000..94cfa1cc161
--- /dev/null
+++ b/doc/user/project/repository/img/repository_languages_v15_2.png
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index 02b5639cae8..a8937d4f705 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -116,7 +116,7 @@ You can download the source code that's stored in a repository.
 For the default branch of each repository, GitLab determines which programming languages
 are used. This information is displayed on the **Project information** page.
 
-![Repository Languages bar](img/repository_languages_v12_2.gif)
+![Repository Languages bar](img/repository_languages_v15_2.png)
 
 When new files are added, this information can take up to five minutes to update.
 
@@ -232,7 +232,7 @@ When a repository path changes, GitLab handles the transition from the
 old location to the new one with a redirect.
 
 When you [rename a user](../../profile/index.md#change-your-username),
-[change a group path](../../group/index.md#change-a-groups-path), or [rename a repository](../settings/index.md#renaming-a-repository):
+[change a group path](../../group/index.md#change-a-groups-path), or [rename a repository](../settings/index.md#rename-a-repository):
 
 - URLs for the namespace and everything under it, like projects, are
   redirected to the new URLs.
diff --git a/doc/user/project/repository/managing_large_repositories.md b/doc/user/project/repository/managing_large_repositories.md
index 76f66f41297..93b94ac0641 100644
--- a/doc/user/project/repository/managing_large_repositories.md
+++ b/doc/user/project/repository/managing_large_repositories.md
@@ -16,7 +16,7 @@ On this page we detail several best practices to improve performance with these
 
 It's *strongly* recommended in any Git system that binary or blob files (for example, packages, audio, video, graphics, etc.) are stored as Large File Storage (LFS) objects. In such setup, the Objects are stored elsewhere, such as in Object Storage, and this can reduce the repository size significantly, thus improving performance.
 
-Refer to the [Git LFS docs for more information](../../../topics/git/lfs/index.md).
+Refer to the [Git LFS documentation for more information](../../../topics/git/lfs/index.md).
 
 ## Gitaly Pack Objects Cache
 
@@ -34,7 +34,7 @@ In these types of setups it's recommended that the GitLab environment used match
 
 Gitaly Cluster can notably improve large repository performance as it holds multiple replicas of the repository across several nodes. As a result, Gitaly Cluster can load balance read requests against those repositories and is also fault tolerant.
 
-It's recommended for large repositories, however, Gitaly Cluster is a large solution with additional complexity of setup and management. Refer to the [Gitaly Cluster docs for more information](../../../administration/gitaly/index.md), specifically the [Before deploying Gitaly Cluster](../../../administration/gitaly/index.md#before-deploying-gitaly-cluster) section.
+It's recommended for large repositories, however, Gitaly Cluster is a large solution with additional complexity of setup, and management. Refer to the [Gitaly Cluster documentation for more information](../../../administration/gitaly/index.md), specifically the [Before deploying Gitaly Cluster](../../../administration/gitaly/index.md#before-deploying-gitaly-cluster) section.
 
 ## Keep GitLab up to date
 
@@ -46,6 +46,6 @@ Large repositories tend to be monorepos. This in turn typically means that these
 
 CI/CD loads tend to be concurrent as pipelines are scheduled during set times. As a result, the Git requests against the repositories can spike notably during these times and lead to reduced performance for both CI and users alike.
 
-When designing CI/CD pipelines, it's advisable to reduce their concurrency by staggering them to run at different times, for example, a set running at one time and then another set running several minutes later.
+When designing CI/CD pipelines, it's advisable to reduce their concurrency by staggering them to run at different times, for example, a set running at one time, and another set running several minutes later.
 
-There's several other actions that can be explored to improve CI/CD performance with large repositories. Refer to the [Runner docs for more information](../../../ci/large_repositories/index.md).
+There's several other actions that can be explored to improve CI/CD performance with large repositories. Refer to the [Runner documentation for more information](../../../ci/large_repositories/index.md).
diff --git a/doc/user/project/repository/mirror/index.md b/doc/user/project/repository/mirror/index.md
index fe1c9653cfe..4537f8520cd 100644
--- a/doc/user/project/repository/mirror/index.md
+++ b/doc/user/project/repository/mirror/index.md
@@ -8,7 +8,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/repository_mirroring.htm
 # Repository mirroring **(FREE)**
 
 You can _mirror_ a repository to and from external sources. You can select which repository
-serves as the source. Branches, tags, and commits can be mirrored.
+serves as the source. Branches, tags, and commits are synced automatically.
 
 NOTE:
 SCP-style URLs are **not** supported. However, the work for implementing SCP-style URLs is tracked
@@ -302,3 +302,12 @@ fail nor succeed. They also do not leave a clear log. To check for this problem:
 1. After you run the command, the [background jobs page](../../../admin_area/index.md#background-jobs)
    should show new mirroring jobs being scheduled, especially when
    [triggered manually](#update-a-mirror).
+
+### Invalid URL
+
+If you receive this error while setting up mirroring over [SSH](#ssh-authentication), make sure the URL is in a valid format.
+
+Mirroring does not support the short version of SSH clone URLs (`git@gitlab.com:gitlab-org/gitlab.git`)
+and requires the full version including the protocol (`ssh://git@gitlab.com/gitlab-org/gitlab.git`).
+
+Make sure that host and project path are separated using `/` instead of `:`.
diff --git a/doc/user/project/repository/mirror/pull.md b/doc/user/project/repository/mirror/pull.md
index 3599faf4de6..88104e34eb4 100644
--- a/doc/user/project/repository/mirror/pull.md
+++ b/doc/user/project/repository/mirror/pull.md
@@ -97,7 +97,7 @@ assigned when you set up pull mirroring.
 
 Pull mirroring uses polling to detect new branches and commits added upstream,
 often minutes afterwards. You can notify GitLab using an
-[API call](../../../../api/projects.md#start-the-pull-mirroring-process-for-a-project), 
+[API call](../../../../api/projects.md#start-the-pull-mirroring-process-for-a-project),
 but the [minimum interval for pull mirroring limits](index.md#force-an-update) is still enforced.
 
 For more information, read
diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md
index 83fafd409e8..b0ae1b7d1e0 100644
--- a/doc/user/project/repository/reducing_the_repo_size_using_git.md
+++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md
@@ -1,8 +1,7 @@
 ---
-stage: Create
+stage: Systems
 group: Gitaly
 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
-type: howto
 ---
 
 # Reduce repository size **(FREE)**
@@ -20,7 +19,7 @@ over [`git filter-branch`](https://git-scm.com/docs/git-filter-branch) and
 
 WARNING:
 Rewriting repository history is a destructive operation. Make sure to back up your repository before
-you begin. The best way back up a repository is to
+you begin. The best way to back up a repository is to
 [export the project](../settings/import_export.md#export-a-project-and-its-data).
 
 ## Purge files from repository history
@@ -36,6 +35,11 @@ other internal references (refs) that are automatically created by GitLab. These
 
 These refs are not automatically downloaded and hidden refs are not advertised, but we can remove these refs using a project export.
 
+WARNING:
+This process is not suitable for removing sensitive data like password or keys from your repository.
+Information about commits, including file content, is cached in the database, and remain
+visible even after they have been removed from the repository.
+
 To purge files from a GitLab repository:
 
 1. Install either [`git filter-repo`](https://github.com/newren/git-filter-repo/blob/main/INSTALL.md) or
@@ -248,11 +252,6 @@ increased, your only option is to:
 1. Prune all the unneeded stuff locally.
 1. Create a new project on GitLab and start using that instead.
 
-WARNING:
-This process is not suitable for removing sensitive data like password or keys from your repository.
-Information about commits, including file content, is cached in the database, and remain
-visible even after they have been removed from the repository.
-
 ## Troubleshooting
 
 ### Incorrect repository statistics shown in the GUI
diff --git a/doc/user/project/repository/web_editor.md b/doc/user/project/repository/web_editor.md
index 370a349b982..4ca341f0535 100644
--- a/doc/user/project/repository/web_editor.md
+++ b/doc/user/project/repository/web_editor.md
@@ -137,7 +137,7 @@ The **Create merge request** button doesn't display if:
 - Your project has an active fork relationship.
 
 To make this button appear, one possible workaround is to
-[remove your project's fork relationship](../settings/index.md#removing-a-fork-relationship).
+[remove your project's fork relationship](../settings/index.md#remove-a-fork-relationship).
 After removal, the fork relationship cannot be restored. This project can no longer
 be able to receive or send merge requests to the source project, or other forks.
 
diff --git a/doc/user/project/settings/img/cve_id_request_toggle.png b/doc/user/project/settings/img/cve_id_request_toggle.png
deleted file mode 100644
index 53ec804922c..00000000000
--- a/doc/user/project/settings/img/cve_id_request_toggle.png
+++ /dev/null
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 46a6c1a049e..7d1bfcaab59 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -278,24 +278,34 @@ When you disable a feature, the following additional features are also disabled:
 - Metrics dashboard access requires reading project environments and deployments.
   Users with access to the metrics dashboard can also access environments and deployments.
 
-## Disabling the CVE ID request button **(FREE SAAS)**
+## Disable CVE identifier request in issues **(FREE SAAS)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/41203) in GitLab 13.4, only for public projects on GitLab.com.
 
-In applicable environments, a [**Create CVE ID Request** button](../../application_security/cve_id_request.md)
-is present in the issue sidebar. The button may be disabled on a per-project basis by toggling the
-setting **Enable CVE ID requests in the issue sidebar**.
+In some environments, users can submit a [CVE identifier request](../../application_security/cve_id_request.md) in an issue.
 
-![CVE ID Request toggle](img/cve_id_request_toggle.png)
+To disable the CVE identifier request option in issues in your project:
 
-## Disabling email notifications
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Visibility, project features, permissions** section.
+1. Under **Issues**, turn off the **CVE ID requests in the issue sidebar** toggle.
+1. Select **Save changes**.
+
+## Disable project email notifications
 
-Project owners can disable all [email notifications](../../profile/notifications.md)
-related to the project by selecting the **Disable email notifications** checkbox.
+Prerequisites:
+
+- You must be an Owner of the project to disable email notifications related to the project.
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Visibility, project features, permissions** section.
+1. Clear the **Disable email notifications** checkbox.
 
 ## Configure merge request settings for a project
 
-Set up your project's merge request settings:
+Configure your project's merge request settings:
 
 - Set up the [merge request method](../merge_requests/methods/index.md) (merge commit, fast-forward merge).
 - Add merge request [description templates](../description_templates.md#description-templates).
@@ -317,91 +327,74 @@ Enable [Service Desk](../service_desk.md) for your project to offer customer sup
 
 Learn how to [export a project](import_export.md#import-a-project-and-its-data) in GitLab.
 
-## Advanced settings
+## Advanced project settings
 
-Here you can run housekeeping, archive, rename, transfer,
-[remove a fork relationship](#removing-a-fork-relationship), or delete a project.
+Use the advanced settings to archive, rename, transfer,
+remove a fork relationship, or delete a project.
 
-## Archiving a project
+### Archive a project
 
-Archiving a project makes it read-only for all users and indicates that it's
-no longer actively maintained. Projects that have been archived can also be
-unarchived. Only project owners and administrators have the
-[permissions](../../permissions.md#project-members-permissions) to archive a project.
-
-When a project is archived, the repository, packages, issues, merge requests, and all
-other features are read-only. Archived projects are also hidden
-in project listings.
+When you archive a project, the repository, packages, issues, merge requests, and all
+other features are read-only. Archived projects are also hidden from project listings.
 
 To archive a project:
 
-1. Navigate to your project's **Settings > General**.
-1. Under **Advanced**, select **Expand**.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Advanced**.
 1. In the **Archive project** section, select **Archive project**.
-1. Confirm the action when asked to.
-
-## Unarchiving a project
+1. To confirm, select **OK**.
 
-Unarchiving a project removes the read-only restriction on a project, and makes it
-available in project listings. Only project owners and administrators have the
-[permissions](../../permissions.md#project-members-permissions) to unarchive a project.
+### Unarchive a project
 
-To find an archived project:
+When you unarchive a project, you remove the read-only restriction and make it
+available in project lists.
 
-1. Sign in to GitLab as the project owner or a user with administrator access.
-1. If you:
-   - Have the project's URL, open the project's page in your browser.
-   - Don't have the project's URL:
-     1. On the top bar, select **Menu > Project**.
-     1. Select **Explore projects**.
-     1. In the **Sort projects** dropdown box, select **Show archived projects**.
-     1. In the **Filter by name** field, provide the project's name.
-     1. Select the link to the project to open its **Details** page.
+Prerequisites:
 
-Next, to unarchive the project:
+- To unarchive a project, you must be an administrator or a project Owner.
 
-1. Navigate to your project's **Settings > General**.
+1. Find the archived project.
+   1. On the top bar, select **Menu > Project**.
+   1. Select **Explore projects**.
+   1. In the **Sort projects** dropdown list, select **Show archived projects**.
+   1. In the **Filter by name** field, enter the project name.
+   1. Select the project link.
+1. On the left sidebar, select **Settings > General**.
 1. Under **Advanced**, select **Expand**.
 1. In the **Unarchive project** section, select **Unarchive project**.
-1. Confirm the action when asked to.
+1. To confirm, select **OK**.
 
-## Renaming a repository
+### Rename a repository
 
-NOTE:
-Only project maintainers and administrators have the [permissions](../../permissions.md#project-members-permissions) to rename a
-repository. Not to be confused with a project's name where it can also be
-changed from the [general project settings](#edit-project-name-and-description).
-
-A project's repository name defines its URL (the one you use to access the
-project via a browser) and its place on the file disk where GitLab is installed.
+A project's repository name defines its URL and its place on the file disk
+where GitLab is installed.
 
-To rename a repository:
+Prerequisites:
 
-1. Navigate to your project's **Settings > General**.
-1. Under **Advanced**, select **Expand**.
-1. Under **Change path**, update the repository's path.
-1. Select **Change path**.
+You must be a project maintainer or administrator to rename a repository.
 
-Remember that this can have unintended side effects since everyone with the
-old URL can't push or pull. Read more about what happens with the
+NOTE:
+When you change the repository path, users may experience issues if they push to, or pull from, the old URL. For more information, see
 [redirects when renaming repositories](../repository/index.md#what-happens-when-a-repository-path-changes).
 
-## Transferring an existing project into another namespace
+To rename a repository:
 
-NOTE:
-Only project owners and administrators have the [permissions](../../permissions.md#project-members-permissions)
-to transfer a project.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand the **Advanced** section.
+1. In the **Change path** text box, edit the path.
+1. Select **Change path**.
+
+## Transfer a project to another namespace
 
-You can transfer an existing project to another [group](../../group/index.md),
-or you can transfer a [personal project](../working_with_projects.md#view-personal-projects) to a group.
+When you transfer a project to another namespace, you move the project to a different group.
 
 Prerequisites:
 
-- A group for your project. You can [view your existing groups](../../group/index.md#view-groups)
-  to find a suitable group. If you don't have a group, [create one](../../group/index.md#create-a-group).
-- You must have at least the Maintainer role in that group.
-- You must be the Owner of that project.
-- The group to which the project is being transferred to must allow creation of new projects.
+- You must have at least the Maintainer role for the [group](../../group/index.md#create-a-group) to which you are transferring.
+- You must be the Owner of the project you transfer.
+- The group must allow creation of new projects.
 - The project must not contain any [container images](../../packages/container_registry/index.md#limitations).
   - If you transfer a project to a different root namespace,
     the project must not contain any
@@ -416,19 +409,18 @@ To transfer a project:
 1. Select **Transfer project**.
 1. Enter the project's name and select **Confirm**.
 
-You are redirected to the project's new URL. Read what happens with the
-[redirects from the old URL to the new one](../repository/index.md#what-happens-when-a-repository-path-changes).
+You are redirected to the project's new page and GitLab applies a redirect. For more information about repository redirects, see [What happens when a repository path changes](../repository/index.md#what-happens-when-a-repository-path-changes).
 
 NOTE:
-GitLab administrators can use the [administration interface](../../admin_area/index.md#administering-projects)
-to move any project to any namespace if needed.
+If you are an administrator, you can also use the [administration interface](../../admin_area/index.md#administering-projects)
+to move any project to any namespace.
 
-## Transferring a GitLab.com project to a different subscription tier
+### Transferring a GitLab SaaS project to a different subscription tier
 
-When you transfer a project from a namespace that's licensed for GitLab SaaS Premium or Ultimate to Free, some data related to the paid features is deleted.
+When you transfer a project from a namespace licensed for GitLab SaaS Premium or Ultimate to GitLab Free, the following paid feature data is deleted:
 
-For example, [project access tokens](../../../user/project/settings/project_access_tokens.md) are revoked, and
-[pipeline subscriptions](../../../ci/pipelines/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt)
+- [Project access tokens](../../../user/project/settings/project_access_tokens.md) are revoked
+- [Pipeline subscriptions](../../../ci/pipelines/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt)
 and [test cases](../../../ci/test_cases/index.md) are deleted.
 
 ## Delete a project
@@ -460,7 +452,7 @@ in GitLab 12.6, and then to [immediate deletion](https://gitlab.com/gitlab-org/g
 Projects can be deleted after a delay period. Multiple settings can affect whether
 delayed project deletion is enabled for a particular project:
 
-- Self-managed instance [settings](../../admin_area/settings/visibility_and_access_controls.md#deletion-protection).
+- Self-managed instance [settings](../../admin_area/settings/visibility_and_access_controls.md#delayed-project-deletion).
   You can enable delayed project deletion as the default setting for new groups, and configure the number of days for the
   delay. For GitLab.com, see the [GitLab.com settings](../../gitlab_com/index.md#delayed-project-deletion).
 - Group [settings](../../group/index.md#enable-delayed-project-deletion) to enabled delayed project deletion for all
@@ -499,27 +491,23 @@ To restore a project marked for deletion:
 1. Navigate to your project, and select **Settings > General > Advanced**.
 1. In the Restore project section, select **Restore project**.
 
-## Removing a fork relationship
+## Remove a fork relationship
+
+Prerequisites:
 
-Forking is a great way to [contribute to a project](../repository/forking_workflow.md)
-of which you're not a member.
-If you want to use the fork for yourself and don't need to send
-[merge requests](../merge_requests/index.md) to the upstream project,
-you can safely remove the fork relationship.
+- You must be a project owner to remove a fork relationship.
 
 WARNING:
-Once removed, you can't send merge requests to the source, and if anyone has forked your project, their fork also loses the relationship.
+If you remove a fork relationship, you can't send merge requests to the source. If anyone has forked your project, their fork also loses the relationship.
 To restore the fork relationship, [use the API](../../../api/projects.md#create-a-forked-fromto-relation-between-existing-projects).
 
-To do so:
+To remove a fork relationship:
 
-1. Navigate to your project's **Settings > General > Advanced**.
-1. Under **Remove fork relationship**, select the likewise-labeled button.
-1. Confirm the action by typing the project's path as instructed.
-
-NOTE:
-Only project owners have the [permissions](../../permissions.md#project-members-permissions)
-to remove a fork relationship.
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Advanced**.
+1. In the **Remove fork relationship** section, select **Remove fork relationship**.
+1. To confirm, enter the project path and select **Confirm**.
 
 ## Monitor settings
 
diff --git a/doc/user/project/wiki/img/content_editor_v14.6.png b/doc/user/project/wiki/img/content_editor_v14.6.png
deleted file mode 100644
index 55fca0ace1e..00000000000
--- a/doc/user/project/wiki/img/content_editor_v14.6.png
+++ /dev/null
diff --git a/doc/user/project/wiki/img/use_new_editor_button_v14.6.png b/doc/user/project/wiki/img/use_new_editor_button_v14.6.png
deleted file mode 100644
index 078fed8a1e9..00000000000
--- a/doc/user/project/wiki/img/use_new_editor_button_v14.6.png
+++ /dev/null
diff --git a/doc/user/project/wiki/index.md b/doc/user/project/wiki/index.md
index 5ae0cf46d9b..6e320923496 100644
--- a/doc/user/project/wiki/index.md
+++ b/doc/user/project/wiki/index.md
@@ -329,16 +329,15 @@ to disable the wiki but toggle it on (in blue).
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345398) switching between editing experiences in GitLab 14.7 [with a flag](../../../administration/feature_flags.md) named `wiki_switch_between_content_editor_raw_markdown`. Enabled by default.
 > - Switching between editing experiences generally available in GitLab 14.10. [Feature flag `wiki_switch_between_content_editor_raw_markdown`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83760) removed.
 
-GitLab version 14.0 introduces a WYSIWYG editing experience for GitLab Flavored Markdown
-in Wikis through the [Content Editor](../../../development/fe_guide/content_editor.md).
-The Content Editor is under active development, and is not yet the default editing
-experience in the Wiki. To opt in for the new editor:
+GitLab provides a WYSIWYG editing experience for GitLab Flavored Markdown in wikis.
 
-1. Create a new wiki page, or edit an existing one.
-1. Ensure the wiki page uses the Markdown format. Other formats are not yet supported.
-1. Above the content field, select **Edit rich text**:
+Support includes:
 
-   ![Use new editor button image](img/use_new_editor_button_v14.6.png)
+- Text formatting options, including bold, italics, block quotes, headings, and inline code.
+- List formatting for unordered, numbered, and checklists.
+- Creating and editing the structure of tables.
+- Inserting and formatting code blocks with syntax highlighting.
+- Live preview of Mermaid, PlantUML, and Kroki diagrams ([Introduced]<https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86701> in GitLab 15.2).
 
 ### Use the Content Editor
 
@@ -346,9 +345,10 @@ experience in the Wiki. To opt in for the new editor:
 1. Select **Markdown** as your format.
 1. Above **Content**, select **Edit rich text**.
 1. Customize your page's content using the various formatting options available in the content editor.
-1. Select **Create page** for a new page, or **Save changes** for an existing page:
+1. Select **Create page** for a new page, or **Save changes** for an existing page.
 
-   ![Content Editor in Wikis image](img/content_editor_v14.6.png)
+The rich text editing mode remains the default until you switch back to
+[edit the raw source](#switch-back-to-the-old-editor).
 
 ### Switch back to the old editor
 
diff --git a/doc/user/project/working_with_projects.md b/doc/user/project/working_with_projects.md
index 83cab819f54..9572bc241fc 100644
--- a/doc/user/project/working_with_projects.md
+++ b/doc/user/project/working_with_projects.md
@@ -198,7 +198,7 @@ GitLab creates your project in your chosen namespace.
 You cannot use `git push` to create projects with project paths that:
 
 - Have previously been used.
-- Have been [renamed](settings/index.md#renaming-a-repository).
+- Have been [renamed](settings/index.md#rename-a-repository).
 
 Previously used project paths have a redirect. The redirect causes push attempts to redirect requests
 to the renamed project location, instead of creating a new project. To create a new project for a previously
@@ -391,7 +391,7 @@ To use a project as a Go package, use the `go get` and `godoc.org` discovery req
 Prerequisites:
 
 - Your GitLab instance must be accessible with HTTPS.
-- You must have a [personal access token](../profile/personal_access_tokens.md).
+- You must have a [personal access token](../profile/personal_access_tokens.md) with `read_api` scope.
 
 To authenticate Go requests, create a [`.netrc`](https://everything.curl.dev/usingcurl/netrc) file with the following information:
 
@@ -423,7 +423,7 @@ Configure Git to either:
 - Use SSH instead of HTTPS:
 
     ```shell
-    git config --global url."git@gitlab.example.com".insteadOf "https://gitlab.example.com"
+    git config --global url."git@gitlab.example.com:".insteadOf "https://gitlab.example.com/"
     ```
 
 ### Disable Go module fetching for private projects