Add latest changes from gitlab-org/gitlab@15-3-stable-eev15.3.0-rc42

83 files changed, 1101 insertions, 663 deletions

diff --git a/doc/user/project/canary_deployments.md b/doc/user/project/canary_deployments.md
index a76517a7341..f8494116655 100644
--- a/doc/user/project/canary_deployments.md
+++ b/doc/user/project/canary_deployments.md
@@ -38,9 +38,9 @@ want to make sure the performance stays the same, or improves. Developers need
 to be careful when using canaries with user-facing changes, because by default,
 requests from the same user are randomly distributed between canary and
 non-canary pods, which could result in confusion or even errors. If needed, you
-may want to consider [setting `service.spec.sessionAffinity` to `ClientIP` in
-your Kubernetes service definitions](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), but that is beyond the scope of
-this document.
+may want to consider 
+[setting `service.spec.sessionAffinity` to `ClientIP` in your Kubernetes service definitions](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies), 
+but that is beyond the scope of this document.
 
 ## Advanced traffic control with Canary Ingress
 
diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md
index 2e1c8766ae3..bfaf9aab7b7 100644
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -37,7 +37,7 @@ Prerequisites:
   set up with access.
 - Kubernetes Engine API and related services enabled. It should work immediately but may
   take up to 10 minutes after you create a project. For more information see the
-  ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/quickstart#before-you-begin).
+  ["Before you begin" section of the Kubernetes Engine docs](https://cloud.google.com/kubernetes-engine/docs/deploy-app-cluster#before-you-begin).
 
 Note the following:
 
@@ -51,8 +51,8 @@ Note the following:
   cluster's pod address IP range is set to `/16` instead of the regular `/14`. `/16` is a CIDR
   notation.
 - GitLab requires basic authentication enabled and a client certificate issued for the cluster to
-  set up an [initial service account](cluster_access.md). In [GitLab versions
-  11.10 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58208), the cluster creation process
+  set up an [initial service account](cluster_access.md). In 
+  [GitLab versions 11.10 and later](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58208), the cluster creation process
   explicitly requests GKE to create clusters with basic authentication enabled and a client
   certificate.
 
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index 95d8064b380..f1004a40a13 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -46,3 +46,27 @@ To remove the Kubernetes cluster integration:
 1. Go to your cluster details page.
 1. Select the **Advanced Settings** tab.
 1. Select either **Remove integration** or **Remove integration and resources**.
+
+### Remove clusters by using the Rails console **(FREE SELF)**
+
+[Start a Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+
+To find a cluster:
+
+``` ruby
+cluster = Clusters::Cluster.find(1)
+cluster = Clusters::Cluster.find_by(name: 'cluster_name')
+```
+
+To delete a cluster but not the associated resources:
+
+```ruby
+# Find users who have administrator access
+user = User.find_by(username: 'admin_user')
+
+# Find the cluster with the ID
+cluster = Clusters::Cluster.find(1)
+
+# Delete the cluster
+Clusters::DestroyService.new(user).execute(cluster)
+```
diff --git a/doc/user/project/clusters/deploy_to_cluster.md b/doc/user/project/clusters/deploy_to_cluster.md
index fc41533b17c..0a574b9afe2 100644
--- a/doc/user/project/clusters/deploy_to_cluster.md
+++ b/doc/user/project/clusters/deploy_to_cluster.md
@@ -131,7 +131,7 @@ However, sometimes GitLab cannot create them. In such instances, your job can fa
 This job failed because the necessary resources were not successfully created.
 ```
 
-To find the cause of this error when creating a namespace and service account, check the [logs](../../../administration/logs.md#kuberneteslog).
+To find the cause of this error when creating a namespace and service account, check the [logs](../../../administration/logs/index.md#kuberneteslog).
 
 Reasons for failure include:
 
diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md
index adea5dad7b8..fd2df96308c 100644
--- a/doc/user/project/code_owners.md
+++ b/doc/user/project/code_owners.md
@@ -8,21 +8,37 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > Moved to GitLab Premium in 13.9.
 
-Code Owners define who owns specific files or directories in a repository.
+Code Owners define who develops and maintains a feature, and own the resulting
+files or directories in a repository.
 
 - The users you define as Code Owners are displayed in the UI when you browse directories.
 - You can set your merge requests so they must be approved by Code Owners before merge.
 - You can protect a branch and allow only Code Owners to approve changes to the branch.
 
-If you don't want to use Code Owners for approvals, you can
-[configure rules](merge_requests/approvals/rules.md) instead.
+Use Code Owners and approvers together with
+[approval rules](merge_requests/approvals/rules.md) to build a flexible approval
+workflow:
 
-## Set up Code Owners
+- Use **Code Owners** to define the users who have domain expertise for specific paths in your repository.
+- Use **Approvers** and **Approval rules** to define domains of expertise (such as a security team)
+  that are not scoped to specific file paths in your repository.
+  - **Approvers** define the users.
+  - **Approval rules** define when these users can approve work, and whether or not their approval is required.
+
+For example:
+
+| Type | Name | Scope  | Comment    |
+|------|------|--------|------------|
+| Approval rule            | UX                   | All files     | A user experience (UX) team member reviews the user experience of all changes made in your project. |
+| Approval rule            | Security             | All files     | A security team member reviews all changes for vulnerabilities.                                     |
+| Code Owner approval rule | Frontend: Code Style | `*.css` files | A frontend engineer reviews CSS file changes for adherence to project style standards.              |
+| Code Owner approval rule | Backend: Code Review | `*.rb` files  | A backend engineer reviews the logic and code style of Ruby files.                                  |
 
-You can use Code Owners to specify users or [shared groups](members/share_project_with_groups.md)
-that are responsible for specific files and directories in a repository.
+## Set up Code Owners
 
-To set up Code Owners:
+Create a `CODEOWNERS` file to specify users or [shared groups](members/share_project_with_groups.md)
+that are responsible for specific files and directories in a repository. Each repository
+can have a single `CODEOWNERS` file. To create it:
 
 1. Choose the location where you want to specify Code Owners:
    - In the root directory of the repository
@@ -59,24 +75,38 @@ Next steps:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53182) in GitLab 12.1.
 > - Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in GitLab 13.0.
 
-You can use members of groups and subgroups as Code Owners for a project.
+You can use members of groups and subgroups as Code Owners for projects:
 
-For example, if you have these groups:
+```mermaid
+graph TD
+    A[Parent group X] -->|owns| B[Project A]
+    A -->|contains| C[Subgroup Y]
+    C -->|owns| D[Project B]
+    A-. inherits ownership .-> D
+```
 
-- **Group X** (`group-x`) with **Project A** in it.
-- **Subgroup Y** (`group-x/subgroup-y`), which belongs to **Group X**, with **Project B** in it.
+In this example:
 
-The eligible Code Owners:
+- **Parent group X** (`group-x`) owns **Project A**.
+- **Parent group X** also contains a subgroup, **Subgroup Y**. (`group-x/subgroup-y`)
+- **Subgroup Y** owns **Project B**.
 
-- For **Project A** are the members of **Group X** only, because **Project A** doesn't belong to **Subgroup Y**.
-- For **Project B** are the members of both **Group X** and **Subgroup Y**.
+The eligible Code Owners are:
 
-![Eligible Code Owners](img/code_owners_members_v13_4.png)
+- **Project A**: the members of **Group X** only, because **Project A** doesn't belong to **Subgroup Y**.
+- **Project B**: the members of both **Group X** and **Subgroup Y**.
 
 You can [invite](members/share_project_with_groups.md) **Subgroup Y** to **Project A**
 so that their members also become eligible Code Owners.
 
-![Invite subgroup members to become eligible Code Owners](img/code_owners_invite_members_v13_4.png)
+```mermaid
+graph LR
+    A[Parent group X] -->|owns| B[Project A]
+    A -->|also contains| C[Subgroup Y]
+    C -.->D{Invite Subgroup Y<br/>to Project A?} -.->|yes| F[Approvals can be<br/> required] -.-> B
+    D{Invite Subgroup Y<br/>to Project A?} -.->|no| I[Subgroup Y cannot be<br /> an approver] -.-> B
+    C -.->E{Add Subgroup Y<br/>as Code Owners<br/>to Project A?} -.->|yes| H[Approvals can only<br/>be optional] -.-> B
+```
 
 If you do not invite **Subgroup Y** to **Project A**, but make them Code Owners, their approval
 of the merge request becomes optional.
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index a90ffbe5796..41afbdada6b 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -116,8 +116,8 @@ To display the deploy boards for a specific [environment](../../ci/environments/
    Kubernetes.
 
    NOTE:
-   Matching based on the Kubernetes `app` label was removed in [GitLab
-   12.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14020).
+   Matching based on the Kubernetes `app` label was removed in 
+   [GitLab 12.1](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14020).
    To migrate, please apply the required annotations (see above) and
    re-deploy your application. If you are using Auto DevOps, this will
    be done automatically and no action is necessary.
diff --git a/doc/user/project/deploy_keys/index.md b/doc/user/project/deploy_keys/index.md
index c64afd95d8d..a9f19d27416 100644
--- a/doc/user/project/deploy_keys/index.md
+++ b/doc/user/project/deploy_keys/index.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Use deploy keys to access repositories that are hosted in GitLab. In most cases, you use deploy keys
 to access a repository from an external host, like a build server or Continuous Integration (CI) server.
 
-Depending on your needs, you might want to use a [deploy token](../deploy_tokens/) to access a repository instead.
+Depending on your needs, you might want to use a [deploy token](../deploy_tokens/index.md) to access a repository instead.
 
 | Attribute        |  Deploy key | Deploy token |
 |------------------|-------------|--------------|
@@ -146,8 +146,8 @@ What happens to the deploy key when it is disabled depends on the following:
 
 ### Deploy key cannot push to a protected branch
 
-There are a few scenarios where a deploy key will fail to push to a [protected
-branch](../protected_branches.md).
+There are a few scenarios where a deploy key will fail to push to a
+[protected branch](../protected_branches.md).
 
 - The owner associated to a deploy key does not have access to the protected branch.
 - The owner associated to a deploy key does not have [membership](../members/index.md) to the project of the protected branch.
diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md
index 42287ff84ce..5df3a973cca 100644
--- a/doc/user/project/description_templates.md
+++ b/doc/user/project/description_templates.md
@@ -112,7 +112,7 @@ To re-use templates [you've created](../project/description_templates.md#create-
 ![Group template settings](../group/img/group_file_template_settings.png)
 
 You might also be interested in templates for various
-[file types in groups](../group/index.md#group-file-templates).
+[file types in groups](../group/manage.md#group-file-templates).
 
 ### Set a default template for merge requests and issues
 
diff --git a/doc/user/project/git_attributes.md b/doc/user/project/git_attributes.md
index 11d1db195e1..90f64b7262c 100644
--- a/doc/user/project/git_attributes.md
+++ b/doc/user/project/git_attributes.md
@@ -23,5 +23,5 @@ ignored.
 ## Syntax Highlighting
 
 The `.gitattributes` file can be used to define which language to use when
-syntax highlighting files and diffs. See ["Syntax
-Highlighting"](highlighting.md) for more information.
+syntax highlighting files and diffs. See 
+["Syntax Highlighting"](highlighting.md) for more information.
diff --git a/doc/user/project/img/code_owners_invite_members_v13_4.png b/doc/user/project/img/code_owners_invite_members_v13_4.png
deleted file mode 100644
index 852a5f68b36..00000000000
--- a/doc/user/project/img/code_owners_invite_members_v13_4.png
+++ /dev/null
diff --git a/doc/user/project/img/code_owners_members_v13_4.png b/doc/user/project/img/code_owners_members_v13_4.png
deleted file mode 100644
index e37fe72cd6e..00000000000
--- a/doc/user/project/img/code_owners_members_v13_4.png
+++ /dev/null
diff --git a/doc/user/project/import/clearcase.md b/doc/user/project/import/clearcase.md
index 867477c83b2..d9ad0c57d79 100644
--- a/doc/user/project/import/clearcase.md
+++ b/doc/user/project/import/clearcase.md
@@ -11,8 +11,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 tools developed by IBM which also include a centralized version control system
 similar to Git.
 
-A good read of ClearCase's basic concepts is can be found in this [StackOverflow
-post](https://stackoverflow.com/a/645771/974710).
+A good read of ClearCase's basic concepts is can be found in this 
+[StackOverflow post](https://stackoverflow.com/a/645771/974710).
 
 The following table illustrates the main differences between ClearCase and Git:
 
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index a190edb179d..a3dfa3edff0 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -241,3 +241,35 @@ Feature.disable(:github_importer_lower_per_page_limit, group)
 
 For information on automating user, group, and project import API calls, see
 [Automate group and project import](index.md#automate-group-and-project-import).
+
+## Troubleshooting
+
+### Manually continue a previously failed import process
+
+In some cases, the GitHub import process can fail to import the repository. This causes GitLab to abort the project import process and requires the
+repository to be imported manually. Administrators can manually import the repository for a failed import process:
+
+1. Open a Rails console.
+1. Run the following series of commands in the console:
+
+   ```ruby
+   project_id = <PROJECT_ID> 
+   github_access_token =  <GITHUB_ACCESS_TOKEN> 
+   github_repository_path = '<GROUP>/<REPOSITORY>'
+
+   github_repository_url = "https://#{github_access_token}@github.com/#{github_repository_path}.git"
+
+   # Find project by ID
+   project = Project.find(project_id)
+   # Set import URL and credentials
+   project.import_url = github_repository_url
+   project.import_type = 'github'
+   project.import_source = github_repository_path
+   project.save!
+   # Create an import state if the project was created manually and not from a failed import
+   project.create_import_state if project.import_state.blank?
+   # Set state to start
+   project.import_state.force_start
+   # Trigger import from second step
+   Gitlab::GithubImport::Stage::ImportRepositoryWorker.perform_async(project.id)
+   ```
diff --git a/doc/user/project/insights/index.md b/doc/user/project/insights/index.md
index 0609b843e86..53547e69e00 100644
--- a/doc/user/project/insights/index.md
+++ b/doc/user/project/insights/index.md
@@ -68,12 +68,14 @@ bugsCharts:
       description: "Open bugs created per month"
       type: bar
       query:
-        issuable_type: issue
-        issuable_state: opened
-        filter_labels:
-          - bug
-        group_by: month
-        period_limit: 24
+        data_source: issuables
+        params:
+          issuable_type: issue
+          issuable_state: opened
+          filter_labels:
+            - bug
+          group_by: month
+          period_limit: 24
 ```
 
 Each chart definition is made up of a hash composed of key-value pairs.
@@ -85,12 +87,14 @@ For example, here's single chart definition:
   description: "Open bugs created per month"
   type: bar
   query:
-    issuable_type: issue
-    issuable_state: opened
-    filter_labels:
-      - bug
-    group_by: month
-    period_limit: 24
+    data_source: issuables
+    params:
+      issuable_type: issue
+      issuable_state: opened
+      filter_labels:
+        - bug
+      group_by: month
+      period_limit: 24
 ```
 
 ## Configuration parameters
@@ -104,7 +108,7 @@ The following table lists available parameters for charts:
 | [`title`](#title)                                  | The title of the chart. This displays on the Insights page. |
 | [`description`](#description)                      | A description for the individual chart. This displays above the relevant chart. |
 | [`type`](#type)                                    | The type of chart: `bar`, `line` or `stacked-bar`. |
-| [`query`](#query)                                  | A hash that defines the conditions for issues / merge requests to be part of the chart. |
+| [`query`](#query)                                  | A hash that defines the data source and filtering conditions for the chart. |
 
 ## Parameter details
 
@@ -153,10 +157,12 @@ Supported values are:
 | `line` | ![Insights example stacked bar chart](img/insights_example_line_chart.png) |
 | `stacked-bar` | ![Insights example stacked bar chart](img/insights_example_stacked_bar_chart.png) |
 
+NOTE:
+The `dora` data source only supports the `bar` chart type.
+
 ### `query`
 
-`query` allows to define the conditions for issues / merge requests to be part
-of the chart.
+`query` allows to define the data source and various filtering conditions for the chart.
 
 Example:
 
@@ -166,6 +172,29 @@ monthlyBugsCreated:
   description: "Open bugs created per month"
   type: bar
   query:
+    data_source: issuables
+    params:
+      issuable_type: issue
+      issuable_state: opened
+      filter_labels:
+        - bug
+      collection_labels:
+        - S1
+        - S2
+        - S3
+        - S4
+      group_by: week
+      period_limit: 104
+```
+
+The legacy format without the `data_source` parameter is still supported:
+
+```yaml
+monthlyBugsCreated:
+  title: "Monthly bugs created"
+  description: "Open bugs created per month"
+  type: bar
+  query:
     issuable_type: issue
     issuable_state: opened
     filter_labels:
@@ -179,7 +208,20 @@ monthlyBugsCreated:
     period_limit: 104
 ```
 
-#### `query.issuable_type`
+#### `query.data_source`
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/725) in GitLab 15.3.
+
+The `data_source` parameter was introduced to allow visualizing data from different data sources.
+
+Supported values are:
+
+- `issuables`: Exposes merge request or issue data.
+- `dora`: Exposes DORA metrics data.
+
+#### `Issuable` query parameters
+
+##### `query.params.issuable_type`
 
 Defines the type of "issuable" you want to create a chart for.
 
@@ -188,7 +230,7 @@ Supported values are:
 - `issue`: The chart displays issues' data.
 - `merge_request`: The chart displays merge requests' data.
 
-#### `query.issuable_state`
+##### `query.params.issuable_state`
 
 Filter by the current state of the queried "issuable".
 
@@ -202,7 +244,7 @@ Supported values are:
 - `merged`: Merged merge requests.
 - `all`: Issues / merge requests in all states
 
-#### `query.filter_labels`
+##### `query.params.filter_labels`
 
 Filter by labels currently applied to the queried "issuable".
 
@@ -216,14 +258,16 @@ monthlyBugsCreated:
   title: "Monthly regressions created"
   type: bar
   query:
-    issuable_type: issue
-    issuable_state: opened
-    filter_labels:
-      - bug
-      - regression
+    data_source: issuables
+    params:
+      issuable_type: issue
+      issuable_state: opened
+      filter_labels:
+        - bug
+        - regression
 ```
 
-#### `query.collection_labels`
+##### `query.params.collection_labels`
 
 Group "issuable" by the configured labels.
 
@@ -237,18 +281,20 @@ weeklyBugsBySeverity:
   title: "Weekly bugs by severity"
   type: stacked-bar
   query:
-    issuable_type: issue
-    issuable_state: opened
-    filter_labels:
-      - bug
-    collection_labels:
-      - S1
-      - S2
-      - S3
-      - S4
+    data_source: issuables
+    params:
+      issuable_type: issue
+      issuable_state: opened
+      filter_labels:
+        - bug
+      collection_labels:
+        - S1
+        - S2
+        - S3
+        - S4
 ```
 
-#### `query.group_by`
+##### `query.group_by`
 
 Define the X-axis of your chart.
 
@@ -258,7 +304,7 @@ Supported values are:
 - `week`: Group data per week.
 - `month`: Group data per month.
 
-#### `query.period_limit`
+##### `query.period_limit`
 
 Define how far "issuables" are queried in the past (using the `query.period_field`).
 
@@ -295,6 +341,68 @@ NOTE:
 Until [this bug](https://gitlab.com/gitlab-org/gitlab/-/issues/26911), is resolved,
 you may see `created_at` in place of `merged_at`. `created_at` is used instead.
 
+#### `DORA` query parameters
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367248) in GitLab 15.3.
+
+An example DORA chart definition:
+
+```yaml
+dora:
+  title: "DORA charts"
+  charts:
+    - title: "DORA deployment frequency"
+      type: bar # only bar chart is supported at the moment
+      query:
+        data_source: dora
+        params:
+          metric: deployment_frequency
+          group_by: day
+          period_limit: 10
+      projects:
+        only:
+          - 38
+    - title: "DORA lead time for changes"
+      description: "DORA lead time for changes"
+      type: bar
+      query:
+        data_source: dora
+        params:
+          metric: lead_time_for_changes
+          group_by: day
+          environment_tiers:
+            - staging
+          period_limit: 30
+```
+
+##### `query.metric`
+
+Defines which DORA metric to query. The available values are:
+
+- `deployment_frequency` (default)
+- `lead_time_for_changes`
+- `time_to_restore_service`
+- `change_failure_rate`
+
+The metrics are described on the [DORA API](../../../api/dora/metrics.md#the-value-field) page.
+
+##### `query.group_by`
+
+Define the X-axis of your chart.
+
+Supported values are:
+
+- `day` (default): Group data per day.
+- `month`: Group data per month.
+
+##### `query.period_limit`
+
+Define how far the metrics are queried in the past (default: 15). Maximum lookback period is 180 days or 6 months.
+
+##### `query.environment_tiers`
+
+An array of environments to include into the calculation (default: production). Available options: `production`, `staging`, `testing`, `development`, `other`.
+
 ### `projects`
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10904) in GitLab 12.4.
@@ -325,10 +433,12 @@ monthlyBugsCreated:
   description: "Open bugs created per month"
   type: bar
   query:
-    issuable_type: issue
-    issuable_state: opened
-    filter_labels:
-      - bug
+    data_source: issuables
+    params:
+      issuable_type: issue
+      issuable_state: opened
+      filter_labels:
+        - bug
   projects:
     only:
       - 3                         # You can use the project ID
@@ -355,41 +465,47 @@ bugsCharts:
       type: bar
       <<: *projectsOnly
       query:
-        issuable_type: issue
-        issuable_state: opened
-        filter_labels:
-          - bug
-        group_by: month
-        period_limit: 24
+        data_source: issuables
+        params:
+          issuable_type: issue
+          issuable_state: opened
+          filter_labels:
+            - bug
+          group_by: month
+          period_limit: 24
 
     - title: "Weekly bugs by severity"
       type: stacked-bar
       <<: *projectsOnly
       query:
-        issuable_type: issue
-        issuable_state: opened
-        filter_labels:
-          - bug
-        collection_labels:
-          - S1
-          - S2
-          - S3
-          - S4
-        group_by: week
-        period_limit: 104
+        data_source: issuables
+        params:
+          issuable_type: issue
+          issuable_state: opened
+          filter_labels:
+            - bug
+          collection_labels:
+            - S1
+            - S2
+            - S3
+            - S4
+          group_by: week
+          period_limit: 104
 
     - title: "Monthly bugs by team"
       type: line
       <<: *projectsOnly
       query:
-        issuable_type: merge_request
-        issuable_state: opened
-        filter_labels:
-          - bug
-        collection_labels:
-          - Manage
-          - Plan
-          - Create
-        group_by: month
-        period_limit: 24
+        data_source: issuables
+        params:
+          issuable_type: merge_request
+          issuable_state: opened
+          filter_labels:
+            - bug
+          collection_labels:
+            - Manage
+            - Plan
+            - Create
+          group_by: month
+          period_limit: 24
 ```
diff --git a/doc/user/project/integrations/harbor.md b/doc/user/project/integrations/harbor.md
index 1319c9e74cd..da35f0dc226 100644
--- a/doc/user/project/integrations/harbor.md
+++ b/doc/user/project/integrations/harbor.md
@@ -39,7 +39,7 @@ GitLab supports integrating Harbor projects at the group or project level. Compl
 
 After the Harbor integration is activated:
 
-- The global variables `$HARBOR_USERNAME`, `$HARBOR_PASSWORD`, `$HARBOR_URL`, and `$HARBOR_PROJECT` are created for CI/CD use.
+- The global variables `$HARBOR_USERNAME`, `$HARBOR_HOST`, `$HARBOR_OCI`, `$HARBOR_PASSWORD`, `$HARBOR_URL`, and `$HARBOR_PROJECT` are created for CI/CD use.
 - The project-level integration settings override the group-level integration settings.
 
 ## Secure your requests to the Harbor APIs
@@ -50,3 +50,51 @@ the `username:password` combination. The following are suggestions for safe use:
 - Use TLS on the Harbor APIs you connect to.
 - Follow the principle of least privilege (for access on Harbor) with your credentials.
 - Have a rotation policy on your credentials.
+
+## Examples of Harbor variables in CI/CD
+
+### Push a Docker image with kaniko
+
+For more information, see [Use kaniko to build Docker images](../../../ci/docker/using_kaniko.md).
+
+```yaml
+docker:
+  stage: docker
+  image:
+    name: gcr.io/kaniko-project/executor:debug
+    entrypoint: ['']
+  script:
+    - mkdir -p /kaniko/.docker
+    - echo "{\"auths\":{\"${HARBOR_HOST}\":{\"auth\":\"$(echo -n ${HARBOR_USERNAME}:${HARBOR_PASSWORD} | base64)\"}}}" > /kaniko/.docker/config.json
+    - >-
+      /kaniko/executor
+      --context "${CI_PROJECT_DIR}"
+      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
+      --destination "${HARBOR_HOST}/${HARBOR_PROJECT}/${CI_PROJECT_NAME}:${CI_COMMIT_TAG}"
+  rules:
+  - if: $CI_COMMIT_TAG
+```
+
+### Push a Helm chart with an OCI registry
+
+Helm supports OCI registries by default. OCI is supported in [Harbor 2.0](https://github.com/goharbor/harbor/releases/tag/v2.0.0) and later.
+Read more about OCI in Helm's [blog](https://helm.sh/blog/storing-charts-in-oci/) and [documentation](https://helm.sh/docs/topics/registries/#enabling-oci-support).
+
+```yaml
+helm:
+  stage: helm
+  image:
+    name: dtzar/helm-kubectl:latest
+    entrypoint: ['']
+  variables:
+    # Enable OCI support (not required since Helm v3.8.0)
+    HELM_EXPERIMENTAL_OCI: 1
+  script:
+    # Log in to the Helm registry
+    - helm registry login "${HARBOR_URL}" -u "${HARBOR_USERNAME}" -p "${HARBOR_PASSWORD}"
+    # Package your Helm chart, which is in the `test` directory
+    - helm package test
+    # Your helm chart is created with <chart name>-<chart release>.tgz
+    # You can push all building charts to your Harbor repository
+    - helm push test-*.tgz ${HARBOR_OCI}/${HARBOR_PROJECT}
+```
diff --git a/doc/user/project/integrations/index.md b/doc/user/project/integrations/index.md
index 7af2e431157..3ef40fdfe44 100644
--- a/doc/user/project/integrations/index.md
+++ b/doc/user/project/integrations/index.md
@@ -73,6 +73,7 @@ You can configure the following integrations.
 | [Pipelines emails](pipeline_status_emails.md)                               | Send the pipeline status to a list of recipients by email.            | **{dotted-circle}** No |
 | [Pivotal Tracker](pivotal_tracker.md)                                       | Add commit messages as comments to Pivotal Tracker stories.           | **{dotted-circle}** No |
 | [Prometheus](prometheus.md)                                                 | Monitor application metrics.                                          | **{dotted-circle}** No |
+| [Pumble](pumble.md)                                                         | Send event notifications to a Pumble channel.                           | **{dotted-circle}** No |
 | Pushover                                                                    | Get real-time notifications on your device.                           | **{dotted-circle}** No |
 | [Redmine](redmine.md)                                                       | Use Redmine as the issue tracker.                                     | **{dotted-circle}** No |
 | [Slack application](gitlab_slack_application.md)                            | Use Slack's official GitLab application.                              | **{dotted-circle}** No |
diff --git a/doc/user/project/integrations/pumble.md b/doc/user/project/integrations/pumble.md
new file mode 100644
index 00000000000..cd28a7c0048
--- /dev/null
+++ b/doc/user/project/integrations/pumble.md
@@ -0,0 +1,39 @@
+---
+stage: Ecosystem
+group: Integrations
+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
+---
+
+# Pumble **(FREE)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93623) in GitLab 15.3.
+
+You can configure GitLab to send notifications to a Pumble channel:
+
+1. Create a webhook for the channel.
+1. Add the webhook to GitLab.
+
+## Create a webhook for your Pumble channel
+
+1. Follow the steps in [Incoming Webhooks for Pumble](https://pumble.com/help/integrations/custom-apps/incoming-webhooks-for-pumble/) in the Pumble documentation.
+1. Copy the webhook URL.
+
+## Configure settings in GitLab
+
+After you have a webhook URL for your Pumble channel, configure GitLab to send
+notifications:
+
+1. To enable the integration for your group or project:
+   1. In your group or project, on the left sidebar, select **Settings > Integrations**.
+1. To enable the integration for your instance: 
+   1. On the top bar, select **Menu > Admin**.
+   1. On the left sidebar, select **Settings > Integrations**.
+1. Select the **Pumble** integration.
+1. Ensure that the **Active** toggle is enabled.
+1. Select the checkboxes corresponding to the GitLab events you want to receive in Pumble.
+1. Paste the **Webhook** URL for the Pumble channel.
+1. Configure the remaining options.
+1. Optional. To test the integration, select **Test settings**.
+1. Select **Save changes**.
+
+The Pumble channel begins to receive all applicable GitLab events. 
diff --git a/doc/user/project/integrations/slack.md b/doc/user/project/integrations/slack.md
index bd93fbcbcbc..dd0f57570aa 100644
--- a/doc/user/project/integrations/slack.md
+++ b/doc/user/project/integrations/slack.md
@@ -77,13 +77,13 @@ The following triggers are available for Slack notifications:
 ## Troubleshooting
 
 If your Slack integration is not working, start troubleshooting by
-searching through the [Sidekiq logs](../../../administration/logs.md#sidekiqlog)
+searching through the [Sidekiq logs](../../../administration/logs/index.md#sidekiqlog)
 for errors relating to your Slack service.
 
 ### Something went wrong on our end
 
 You might get this generic error message in the GitLab UI.
-Review [the logs](../../../administration/logs.md#productionlog) to find
+Review [the logs](../../../administration/logs/index.md#productionlog) to find
 the error message and keep troubleshooting from there.
 
 ### `certificate verify failed`
diff --git a/doc/user/project/integrations/webhook_events.md b/doc/user/project/integrations/webhook_events.md
index 32e5f949c15..51049f156b8 100644
--- a/doc/user/project/integrations/webhook_events.md
+++ b/doc/user/project/integrations/webhook_events.md
@@ -878,7 +878,9 @@ Payload example:
     "source_branch": "ms-viewport",
     "source_project_id": 14,
     "author_id": 51,
+    "assignee_ids": [6],
     "assignee_id": 6,
+    "reviewer_ids": [6],
     "title": "MS-Viewport",
     "created_at": "2013-12-03T17:23:34Z",
     "updated_at": "2013-12-03T17:23:34Z",
@@ -945,12 +947,7 @@ Payload example:
       "type": "ProjectLabel",
       "group_id": 41
     }],
-    "action": "open",
-    "assignee": {
-      "name": "User1",
-      "username": "user1",
-      "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=40\u0026d=identicon"
-    }
+    "action": "open"
   },
   "labels": [{
     "id": 206,
@@ -999,7 +996,23 @@ Payload example:
         "group_id": 41
       }]
     }
-  }
+  },
+  "assignees": [
+    {
+      "id": 6,
+      "name": "User1",
+      "username": "user1",
+      "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=40\u0026d=identicon"
+    }
+  ],
+  "reviewers": [
+    {
+      "id": 6,
+      "name": "User1",
+      "username": "user1",
+      "avatar_url": "http://www.gravatar.com/avatar/e64c7d89f26bd1972efa854d13d7dd61?s=40\u0026d=identicon"
+    }
+  ]
 }
 ```
 
@@ -1614,7 +1627,7 @@ Payload example:
 
 ### Remove a subgroup from a group
 
-This webhook is not triggered when a [subgroup is transferred to a new parent group](../../group/index.md#transfer-a-group).
+This webhook is not triggered when a [subgroup is transferred to a new parent group](../../group/manage.md#transfer-a-group).
 
 Request header:
 
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index e4ce736684b..1de7440a15d 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -137,7 +137,7 @@ For example, to test `push events`, your project should have at least one commit
 
 To test a webhook:
 
-1. In your project, on the left sidebar, select **Settings > Webhooks**.
+1. In your project or group, on the left sidebar, select **Settings > Webhooks**.
 1. Scroll down to the list of configured webhooks.
 1. From the **Test** dropdown list, select the type of event to test.
 
@@ -236,12 +236,14 @@ For more information about supported events for Webhooks, go to [Webhook events]
 
 ## Troubleshoot webhooks
 
+> **Recent events** for group webhooks [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325642) in GitLab 15.3.
+
 GitLab records the history of each webhook request.
 You can view requests made in the last 2 days in the **Recent events** table.
 
 To view the table:
 
-1. In your project, on the left sidebar, select **Settings > Webhooks**.
+1. In your project or group, on the left sidebar, select **Settings > Webhooks**.
 1. Scroll down to the webhooks.
 1. Each [failing webhook](#failing-webhooks) has a badge listing it as:
 
@@ -261,10 +263,6 @@ The table includes the following details about each request:
 
 ![Recent deliveries](img/webhook_logs.png)
 
-NOTE:
-The **Recent events** table is unavailable for group-level webhooks. For more information, read
-[issue #325642](https://gitlab.com/gitlab-org/gitlab/-/issues/325642).
-
 Each webhook event has a corresponding **Details** page. This page details the data that GitLab sent (request headers and body) and received (response headers and body).
 To view the **Details** page, select **View details** for the webhook event.
 
diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md
index c8ecb2fd2e6..787e990526d 100644
--- a/doc/user/project/issue_board.md
+++ b/doc/user/project/issue_board.md
@@ -642,3 +642,20 @@ A few things to remember:
 - For performance and visibility reasons, each list shows the first 20 issues
   by default. If you have more than 20 issues, start scrolling down and the next
   20 appear.
+
+## Troubleshooting issue boards
+
+### Use Rails console to fix issue boards not loading and timing out
+
+If you see issue board not loading and timing out in UI, use Rails console to call the Issue Rebalancing service to fix it:
+
+1. [Start a Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
+1. Run these commands:
+
+   ```ruby
+   p = Project.find_by_full_path('<username-or-group>/<project-name>')
+
+   Issues::RelativePositionRebalancingService.new(p.root_namespace.all_projects).execute
+   ```
+
+1. To exit the Rails console, type `quit`.
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index d1b27f6eab0..bf3cd13f3f0 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -276,7 +276,7 @@ It's rendered as:
 
 User activity events on designs (creation, deletion, and updates) are tracked by GitLab and
 displayed on the [user profile](../../profile/index.md#access-your-user-profile),
-[group](../../group/index.md#view-group-activity),
+[group](../../group/manage.md#view-group-activity),
 and [project](../working_with_projects.md#view-project-activity) activity pages.
 
 ## GitLab-Figma plugin
diff --git a/doc/user/project/issues/img/related_issue_block_v12_8.png b/doc/user/project/issues/img/related_issue_block_v12_8.png
deleted file mode 100644
index ce261f26ce6..00000000000
--- a/doc/user/project/issues/img/related_issue_block_v12_8.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/related_issue_block_v15_3.png b/doc/user/project/issues/img/related_issue_block_v15_3.png
new file mode 100644
index 00000000000..827ddeabf10
--- /dev/null
+++ b/doc/user/project/issues/img/related_issue_block_v15_3.png
diff --git a/doc/user/project/issues/img/related_issues_add_v12_8.png b/doc/user/project/issues/img/related_issues_add_v12_8.png
deleted file mode 100644
index 8a06d005a5f..00000000000
--- a/doc/user/project/issues/img/related_issues_add_v12_8.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/related_issues_add_v15_3.png b/doc/user/project/issues/img/related_issues_add_v15_3.png
new file mode 100644
index 00000000000..7c6edf61427
--- /dev/null
+++ b/doc/user/project/issues/img/related_issues_add_v15_3.png
diff --git a/doc/user/project/issues/img/related_issues_remove_v12_8.png b/doc/user/project/issues/img/related_issues_remove_v12_8.png
deleted file mode 100644
index a8dff4c7052..00000000000
--- a/doc/user/project/issues/img/related_issues_remove_v12_8.png
+++ /dev/null
diff --git a/doc/user/project/issues/img/related_issues_remove_v15_3.png b/doc/user/project/issues/img/related_issues_remove_v15_3.png
new file mode 100644
index 00000000000..577bbed9df3
--- /dev/null
+++ b/doc/user/project/issues/img/related_issues_remove_v15_3.png
diff --git a/doc/user/project/issues/issue_weight.md b/doc/user/project/issues/issue_weight.md
index 756fe9699f1..fcc53a239dc 100644
--- a/doc/user/project/issues/issue_weight.md
+++ b/doc/user/project/issues/issue_weight.md
@@ -17,6 +17,7 @@ You can set the weight of an issue during its creation, by changing the
 value in the dropdown menu. You can set it to a non-negative integer
 value from 0, 1, 2, and so on.
 You can remove weight from an issue as well.
+A user with a Reporter role (or above) can set the weight.
 
 This value appears on the right sidebar of an individual issue, as well as
 in the issues page next to a weight icon (**{weight}**).
diff --git a/doc/user/project/issues/managing_issues.md b/doc/user/project/issues/managing_issues.md
index 15d8da7f544..40e5a6d6a92 100644
--- a/doc/user/project/issues/managing_issues.md
+++ b/doc/user/project/issues/managing_issues.md
@@ -123,8 +123,8 @@ example, if the list is scoped to a label `Frontend`, the new issue also has thi
 
 ### By sending an email
 
-> Generated email address format changed in GitLab 11.7.
-> The older format is still supported, so existing aliases and contacts still work.
+> - Generated email address format changed in GitLab 11.7.
+> - The older format is still supported, so existing aliases and contacts still work.
 
 You can send an email to create an issue in a project on the project's
 **Issues List** page.
@@ -731,4 +731,4 @@ You can do the following **only by using quick actions**:
 - [Publish an issue](#publish-an-issue) (`/publish`).
 - Clone an issue to the same or another project (`/clone`).
 - Close an issue and mark as a duplicate of another issue (`/duplicate`).
-- Copy labels and milestone from another merge request in the project (`/copy_metadata`).
+- Copy labels and milestone from another merge request or issue in the project (`/copy_metadata`).
diff --git a/doc/user/project/issues/related_issues.md b/doc/user/project/issues/related_issues.md
index 028dd2ea473..9dc361b403f 100644
--- a/doc/user/project/issues/related_issues.md
+++ b/doc/user/project/issues/related_issues.md
@@ -37,7 +37,7 @@ To link one issue to another:
    - **[is blocked by](#blocking-issues)**
 1. Input the issue number or paste in the full URL of the issue.
 
-   ![Adding a related issue](img/related_issues_add_v12_8.png)
+   ![Adding a related issue](img/related_issues_add_v15_3.png)
 
    Issues of the same project can be specified just by the reference number.
    Issues from a different project require additional information like the
@@ -54,7 +54,7 @@ To link one issue to another:
 When you have finished adding all linked issues, you can see
 them categorized so their relationships can be better understood visually.
 
-![Related issue block](img/related_issue_block_v12_8.png)
+![Related issue block](img/related_issue_block_v15_3.png)
 
 You can also add a linked issue from a commit message or the description in another issue or MR.
 [Learn more about crosslinking issues](crosslinking_issues.md).
@@ -66,7 +66,7 @@ right-side of each issue token to remove.
 
 Due to the bi-directional relationship, the relationship no longer appears in either issue.
 
-![Removing a related issue](img/related_issues_remove_v12_8.png)
+![Removing a related issue](img/related_issues_remove_v15_3.png)
 
 Access our [permissions](../../permissions.md) page for more information.
 
diff --git a/doc/user/project/labels.md b/doc/user/project/labels.md
index 333b073ee40..62c5489d9c3 100644
--- a/doc/user/project/labels.md
+++ b/doc/user/project/labels.md
@@ -446,12 +446,13 @@ To learn what happens when you sort by priority or label priority, see
 
 ## Real-time changes to labels
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241538) in GitLab 14.10 with a [feature flag](../../administration/feature_flags.md) named `realtime_labels`, disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241538) in GitLab 14.10 with a [feature flag](../../administration/feature_flags.md) named `realtime_labels`, disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/357370#note_991987201) in GitLab 15.1.
 
 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 `realtime_labels`.
-On GitLab.com, this feature is unavailable.
+On GitLab.com, this feature is available.
 
 Changed labels are immediately visible to other users, without refreshing the page, on the following:
 
diff --git a/doc/user/project/members/index.md b/doc/user/project/members/index.md
index ff5f2ac8cb6..4a6272a0ca3 100644
--- a/doc/user/project/members/index.md
+++ b/doc/user/project/members/index.md
@@ -15,7 +15,7 @@ Project members can:
 1. Be [direct members](#add-users-to-a-project) of the project.
 1. [Inherit membership](#inherited-membership) of the project from the project's group.
 1. Be a member of a group that was [shared](share_project_with_groups.md) with the project.
-1. Be a member of a group that was [shared with the project's group](../../group/index.md#share-a-group-with-another-group).
+1. Be a member of a group that was [shared with the project's group](../../group/manage.md#share-a-group-with-another-group).
 
 ```mermaid
 flowchart RL
@@ -49,11 +49,22 @@ flowchart RL
     [Feature flag `invite_members_group_modal`](https://gitlab.com/gitlab-org/gitlab/-/issues/352526) removed.
 
 Add users to a project so they become members and have permission
-to perform actions. The Owner [role](../../permissions.md#project-members-permissions) can only be added at the group level.
+to perform actions.
+
+The maximum role (access level) you set depends on if you have the Owner or Maintainer role for the group. For example, the maximum
+role that can be set is:
+
+- Owner (`50`), if you have the Owner role for the project.
+- Maintainer (`40`), if you have the Maintainer role on the project.
+
+In GitLab 14.8 and earlier, direct members of a project have a maximum role of Maintainer.
+The Owner [role](../../permissions.md#project-members-permissions) can only be added at the group level.
 
 Prerequisite:
 
-- You must have the Maintainer or Owner role.
+- You must have the Maintainer or Owner role:
+  - To remove direct members with the Maintainer role and below, you must have the Maintainer role.
+  - To remove members with the Owner role, you must have the Owner role.
 
 To add a user to a project:
 
@@ -91,7 +102,7 @@ Each user's access is based on:
 Prerequisite:
 
 - You must have the Maintainer or Owner role.
-- Sharing the project with other groups must not be [prevented](../../group/index.md#prevent-a-project-from-being-shared-with-groups).
+- Sharing the project with other groups must not be [prevented](../../group/access_and_permissions.md#prevent-a-project-from-being-shared-with-groups).
 
 To add groups to a project:
 
@@ -107,7 +118,7 @@ The members of the group are not displayed on the **Members** tab.
 The **Members** tab shows:
 
 - Members who are directly assigned to the project.
-- If the project was created in a group [namespace](../../group/index.md#namespaces), members of that group.
+- If the project was created in a group [namespace](../../namespace/index.md), members of that group.
 
 ## Import users from another project
 
@@ -173,7 +184,7 @@ To remove a member from a project:
    user has not forked the private repository or created webhooks. Existing forks continue to receive
    changes from the upstream project, and webhooks continue to receive updates. You may also want to configure your project
    to prevent projects in a group
-   [from being forked outside their group](../../group/index.md#prevent-project-forking-outside-group).
+   [from being forked outside their group](../../group/access_and_permissions.md#prevent-project-forking-outside-group).
 1. Select **Remove member**.
 
 ## Filter and sort members
diff --git a/doc/user/project/members/share_project_with_groups.md b/doc/user/project/members/share_project_with_groups.md
index c4ae00f3c6c..3d5b855a9d3 100644
--- a/doc/user/project/members/share_project_with_groups.md
+++ b/doc/user/project/members/share_project_with_groups.md
@@ -29,7 +29,7 @@ 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.
+Administrators can share projects with any group in the instance.
 
 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
@@ -52,7 +52,7 @@ After sharing 'Project Acme' with 'Engineering':
 When you share a project, be aware of the following restrictions and outcomes:
 
 - [Maximum access level](#maximum-access-level)
-- [Sharing a public project with a private group](#share-a-public-project-with-private-group)
+- [Sharing projects with groups of a higher restrictive visibility level](#sharing-projects-with-groups-of-a-higher-restrictive-visibility-level)
 - [Sharing project with group lock](#share-project-with-group-lock)
 
 ## Maximum access level
@@ -67,18 +67,24 @@ 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 a public project with private group
+## Sharing projects with groups of a higher restrictive visibility level
 
-When you share a public project with a private group, be aware of the following outcomes:
+There are several outcomes you must be aware of when you share a project with a group that has a more restrictive [visibility level](../../public_access.md#project-and-group-visibility) than the project. For example, when you:
 
-- 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 a public project with a private group.
+- Share a public project with an internal group.
+- Share an internal project with a private group.
+
+The following outcomes occur:
+
+- The group name is visible to all users that can view the project members page.
+- Owners of the project have access to members of the group when they mention them in issues or merge requests.
+- Project members who are direct or indirect members of the group can see group members listed in addition to members of the project.
 
 ## Share project with group lock
 
-It is possible to prevent projects in a group from [sharing
-a project with another group](../members/share_project_with_groups.md).
+It is possible to prevent projects in a group from 
+[sharing a project with another group](../members/share_project_with_groups.md).
 This allows for tighter control over project access.
 
-Learn more about [Share with group lock](../../group/index.md#prevent-a-project-from-being-shared-with-groups).
+Learn more about [Share with group lock](../../group/access_and_permissions.md#prevent-a-project-from-being-shared-with-groups).
diff --git a/doc/user/project/merge_requests/approvals/img/scoped_to_protected_branch_v13_10.png b/doc/user/project/merge_requests/approvals/img/scoped_to_protected_branch_v13_10.png
deleted file mode 100644
index a6636f0bc7f..00000000000
--- a/doc/user/project/merge_requests/approvals/img/scoped_to_protected_branch_v13_10.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md
index 014936208c6..9f33ed6807b 100644
--- a/doc/user/project/merge_requests/approvals/index.md
+++ b/doc/user/project/merge_requests/approvals/index.md
@@ -23,7 +23,7 @@ flexibility:
   and require their approval before work can merge.
 
 You can configure merge request approvals on a per-project basis, and
-[on the group level](../../../group/index.md#group-merge-request-approval-settings). Administrators of
+[on the group level](../../../group/manage.md#group-merge-request-approval-settings). Administrators of
 [GitLab Premium](https://about.gitlab.com/pricing/) and
 [GitLab Ultimate](https://about.gitlab.com/pricing/) self-managed GitLab instances
 can also configure approvals
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index b79c8ee867f..c9278c19322 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -7,7 +7,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Merge request approval rules **(PREMIUM)**
 
 Approval rules define how many [approvals](index.md) a merge request must receive before it can
-be merged, and which users should do the approving. You can define approval rules:
+be merged, and which users should do the approving. They can be used in conjunction
+with [Code owners](#code-owners-as-eligible-approvers) to ensure that changes are
+reviewed both by the group maintaining the feature, and any groups responsible
+for specific areas of oversight.
+
+You can define approval rules:
 
 - [As project defaults](#add-an-approval-rule).
 - [Per merge request](#edit-or-override-merge-request-approval-rules).
@@ -127,7 +132,7 @@ users were not explicitly listed in the approval rules.
 ### Group approvers
 
 You can add a group of users as approvers, but those users count as approvers only if
-they have direct membership to the group. Group approvers are
+they have **direct membership** to the group. Inherited members do not count. Group approvers are
 restricted to only groups [with share access to the project](../../members/share_project_with_groups.md).
 
 A user's membership in an approvers group affects their individual ability to
@@ -172,15 +177,15 @@ oversight on proposed work. To enable approval permissions for these users witho
 granting them push access:
 
 1. [Create a protected branch](../../protected_branches.md)
-1. [Create a new group](../../../group/index.md#create-a-group).
-1. [Add the user to the group](../../../group/index.md#add-users-to-a-group),
+1. [Create a new group](../../../group/manage.md#create-a-group).
+1. [Add the user to the group](../../../group/manage.md#add-users-to-a-group),
    and select the Reporter role for the user.
 1. [Share the project with your group](../../members/share_project_with_groups.md#share-a-project-with-a-group-of-users),
    based on the Reporter role.
 1. Go to your project and select **Settings > General**.
 1. Expand **Merge request (MR) approvals**.
 1. Select **Add approval rule** or **Update approval rule** and target the protected branch.
-1. [Add the group](../../../group/index.md#create-a-group) to the permission list.
+1. [Add the group](../../../group/manage.md#create-a-group) to the permission list.
 
    ![Update approval rule](img/update_approval_rule_v13_10.png)
 
@@ -213,7 +218,8 @@ appreciated, but not required. To make an approval rule optional:
 
 ## Approvals for protected branches
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/460) in GitLab 12.8.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/460) in GitLab 12.8.
+> - **All protected branches** target branch option [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360930) in GitLab 15.3.
 
 Approval rules are often relevant only to specific branches, like your
 [default branch](../../repository/branches/default.md). To configure an
@@ -223,10 +229,10 @@ approval rule for certain branches:
 1. Go to your project and select **Settings**.
 1. Expand **Merge request (MR) approvals**.
 1. Select a **Target branch**:
-   - To protect all branches, select **All branches**.
-   - To select a specific branch, select it from the list:
+   - To apply the rule to all branches, select **All branches**.
+   - To apply the rule to all protected branches, select **All protected branches** (GitLab 15.3 and later).
+   - To apply the rule to a specific branch, select it from the list:
 
-     ![Scoped to protected branch](img/scoped_to_protected_branch_v13_10.png)
 1. To enable this configuration, read
    [Code Owner's approvals for protected branches](../../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 7b865a91106..3ca8ddb508a 100644
--- a/doc/user/project/merge_requests/approvals/settings.md
+++ b/doc/user/project/merge_requests/approvals/settings.md
@@ -19,7 +19,9 @@ To view or edit merge request approval settings:
 1. Go to your project and select **Settings > General**.
 1. Expand **Merge request (MR) approvals**.
 
-In this section of general settings, you can configure the following settings:
+### Approval settings
+
+These settings limit who can approve merge requests.
 
 | Setting | Description |
 | ------ | ------ |
@@ -27,7 +29,14 @@ In this section of general settings, you can configure the following settings:
 | [Prevent approvals by users who add commits](#prevent-approvals-by-users-who-add-commits) | When enabled, users who have committed to a merge request cannot approve it. |
 | [Prevent editing approval rules in merge requests](#prevent-editing-approval-rules-in-merge-requests) | When enabled, users can't override the project's approval rules on merge requests.  |
 | [Require user password to approve](#require-user-password-to-approve) | Force potential approvers to first authenticate with a password. |
-| [Remove all approvals when commits are added to the source branch](#remove-all-approvals-when-commits-are-added-to-the-source-branch) | When enabled, remove all existing approvals on a merge request when more changes are added to it. |
+
+You can further define what happens to existing approvals when commits are added to the merge request.
+
+| Setting | Description |
+| ------ | ------ |
+| Keep approvals | Do not remove approvals. |
+| [Remove all approvals](#remove-all-approvals-when-commits-are-added-to-the-source-branch) | Remove all existing approvals. |
+| [Remove approvals by Code Owners if their files changed](#remove-approvals-by-code-owners-if-their-files-changed) | If a Code Owner has approved the merge request, and the commit changes files they are the Code Owner for, their approval is removed. |
 
 ## Prevent approval by author
 
@@ -119,9 +128,27 @@ 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 removed 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.
 
+## Remove approvals by Code Owners if their files changed
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90578) in GitLab 15.3.
+
+If you only want to remove approvals by Code Owners whose files have been changed:
+
+Prerequisite:
+
+- You must have at least the Maintainer role for a project.
+
+To do this:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Merge request approvals**.
+1. Select **Remove approvals by Code Owners if their files changed**.
+1. Select **Save changes**.
+
 ## Code coverage check approvals
 
 You can require specific approvals if a merge request would result in a decline in code test
@@ -139,7 +166,7 @@ You can also enforce merge request approval settings:
 
 - At the [instance level](../../../admin_area/merge_requests_approvals.md), which apply to all groups
   on an instance and, therefore, all projects.
-- On a [top-level group](../../../group/index.md#group-merge-request-approval-settings), which apply to all subgroups
+- On a [top-level group](../../../group/manage.md#group-merge-request-approval-settings), which apply to all subgroups
   and projects.
 
 If the settings are inherited by a group or project, they cannot be changed in the group or project
diff --git a/doc/user/project/merge_requests/csv_export.md b/doc/user/project/merge_requests/csv_export.md
index 2adcc4d4575..893b2bc6811 100644
--- a/doc/user/project/merge_requests/csv_export.md
+++ b/doc/user/project/merge_requests/csv_export.md
@@ -8,13 +8,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3619) in GitLab 13.6.
 
-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.
+Export all the data collected from a project's merge requests into a comma-separated values (CSV) file.
 
-To export merge requests to CSV, navigate to your **Merge requests** from the sidebar of a project and select **Export as CSV**.
+To export merge requests to a CSV file:
+
+1. On the top bar, select **Menu > Projects** and find your project.
+1. On the left sidebar, select **Merge requests** .
+1. Add any searches or filters. This can help you keep the size of the CSV file under the 15MB limit. The limit ensures
+   the file can be emailed to a variety of email providers.
+1. Select **Export as CSV** (**{export}**).
+1. Confirm the correct number of merge requests are to be exported.
+1. Select **Export merge requests**.
 
 ## CSV Output
 
-The following table shows what attributes will be present in the CSV.
+The following table shows the attributes in the CSV file.
 
 | Column             | Description                                                  |
 |--------------------|--------------------------------------------------------------|
@@ -42,8 +50,3 @@ The following table shows what attributes will be present in the CSV.
 In GitLab 14.7 and earlier, the first two columns were `MR ID` and `URL`,
 which [caused an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/34769)
 when importing back into GitLab.
-
-## Limitations
-
-- Export merge requests to CSV is not available at the Group's merge request list.
-- As the merge request CSV file is sent as an email attachment, the size is limited to 15MB to ensure successful delivery across a range of email providers. If you need to minimize the size of the file, you can narrow the search before export. For example, you can set up exports of open and closed merge requests in separate files.
diff --git a/doc/user/project/merge_requests/img/license_compliance_widget_v15_3.png b/doc/user/project/merge_requests/img/license_compliance_widget_v15_3.png
new file mode 100644
index 00000000000..a9f73d40f82
--- /dev/null
+++ b/doc/user/project/merge_requests/img/license_compliance_widget_v15_3.png
diff --git a/doc/user/project/merge_requests/img/status_checks_widget_passed_v14_0.png b/doc/user/project/merge_requests/img/status_checks_widget_passed_v14_0.png
deleted file mode 100644
index de61ca8b553..00000000000
--- a/doc/user/project/merge_requests/img/status_checks_widget_passed_v14_0.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/status_checks_widget_pending_v14_0.png b/doc/user/project/merge_requests/img/status_checks_widget_pending_v14_0.png
deleted file mode 100644
index c4e606bd2f4..00000000000
--- a/doc/user/project/merge_requests/img/status_checks_widget_pending_v14_0.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md
index a7a669d3b75..35ec075c674 100644
--- a/doc/user/project/merge_requests/index.md
+++ b/doc/user/project/merge_requests/index.md
@@ -41,7 +41,7 @@ To view merge requests for all projects in a group:
 
 If your group contains subgroups, this view also displays merge requests from the subgroup projects.
 
-## View all merge requests assigned to you
+### View all merge requests assigned to you
 
 To view all merge requests assigned to you:
 
@@ -52,13 +52,14 @@ To view all merge requests assigned to you:
 
 <!-- vale gitlab.FirstPerson = YES -->
 
-Or:
+or:
 
 - To use a [keyboard shortcut](../../shortcuts.md), press <kbd>Shift</kbd> + <kbd>m</kbd>.
-- On the top bar, on the top right, select **{merge-request-open}** **Merge requests**.
-  Then select one of the following:
-  - [Review requests](reviews/index.md).
-  - Merge requests assigned.
+
+or:
+
+1. On the top bar, on the top right, select **{merge-request-open}** **Merge requests**.
+1. From the dropdown list, select **Assigned to you**.
 
 ## Filter the list of merge requests
 
diff --git a/doc/user/project/merge_requests/methods/index.md b/doc/user/project/merge_requests/methods/index.md
index 63b464e5ff4..c4e4b40dc48 100644
--- a/doc/user/project/merge_requests/methods/index.md
+++ b/doc/user/project/merge_requests/methods/index.md
@@ -150,12 +150,8 @@ considered equivalent to rebasing.
 
 ### Rebase without CI/CD pipeline
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118825) in GitLab 14.7 [with a flag](../../../../administration/feature_flags.md) named `rebase_without_ci_ui`. Disabled by default.
-
-FLAG:
-On GitLab.com and 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 `rebase_without_ci_ui`.
-The feature is not ready for production use.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118825) in GitLab 14.7 [with a flag](../../../../administration/feature_flags.md) named `rebase_without_ci_ui`. Disabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/350262) in GitLab 15.3. Feature flag `rebase_without_ci_ui` removed.
 
 To rebase a merge request's branch without triggering a CI/CD pipeline, select
 **Rebase without pipeline** from the merge request reports section.
diff --git a/doc/user/project/merge_requests/reviews/img/mr_review_new_comment_v13_11.png b/doc/user/project/merge_requests/reviews/img/mr_review_new_comment_v13_11.png
deleted file mode 100644
index 6b4899bf67f..00000000000
--- a/doc/user/project/merge_requests/reviews/img/mr_review_new_comment_v13_11.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/reviews/img/mr_review_new_comment_v15_3.png b/doc/user/project/merge_requests/reviews/img/mr_review_new_comment_v15_3.png
new file mode 100644
index 00000000000..b73dbb50cd2
--- /dev/null
+++ b/doc/user/project/merge_requests/reviews/img/mr_review_new_comment_v15_3.png
diff --git a/doc/user/project/merge_requests/reviews/img/mr_review_resolve.png b/doc/user/project/merge_requests/reviews/img/mr_review_resolve.png
deleted file mode 100644
index ced33682459..00000000000
--- a/doc/user/project/merge_requests/reviews/img/mr_review_resolve.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/reviews/img/mr_review_resolve2.png b/doc/user/project/merge_requests/reviews/img/mr_review_resolve2.png
deleted file mode 100644
index 2f0be3b6d06..00000000000
--- a/doc/user/project/merge_requests/reviews/img/mr_review_resolve2.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/reviews/img/mr_review_start.png b/doc/user/project/merge_requests/reviews/img/mr_review_start.png
deleted file mode 100644
index 08b4c6bb82b..00000000000
--- a/doc/user/project/merge_requests/reviews/img/mr_review_start.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/reviews/img/mr_review_unresolve.png b/doc/user/project/merge_requests/reviews/img/mr_review_unresolve.png
deleted file mode 100644
index 4bef38f7808..00000000000
--- a/doc/user/project/merge_requests/reviews/img/mr_review_unresolve.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/reviews/img/mr_summary_comment_v15_3.png b/doc/user/project/merge_requests/reviews/img/mr_summary_comment_v15_3.png
new file mode 100644
index 00000000000..38e18115803
--- /dev/null
+++ b/doc/user/project/merge_requests/reviews/img/mr_summary_comment_v15_3.png
diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md
index a8f43dd9c02..27b223c48ec 100644
--- a/doc/user/project/merge_requests/reviews/index.md
+++ b/doc/user/project/merge_requests/reviews/index.md
@@ -36,13 +36,9 @@ To start your review:
 1. Select the **{comment}** **comment** icon in the gutter to expand the diff lines
    and display a comment box. In GitLab version 13.2 and later, you can
    [select multiple lines](#comment-on-multiple-lines).
-1. Write your first comment, and select **Start a review** below your comment:
-   ![Starting a review](img/mr_review_start.png)
-1. Continue adding comments to lines of code, and select the appropriate button after
-   you write a comment:
-   - **Add to review**: Keep this comment private and add to the current review.
-     These review comments are marked **Pending** and are visible only to you.
-   - **Add comment now**: Submits the specific comment as a regular comment instead of as part of the review.
+1. In the text area, write your first comment, then select **Start a review** below your comment.
+1. Continue adding comments to lines of code. After each comment, select **Add to review**.
+   Comments made as part of a review are visible only to you until you submit your review.
 1. Optional. You can use [quick actions](../../quick_actions.md) inside review comments.
    The comment shows the actions to perform after publication, but does not perform them
    until you submit your review.
@@ -60,8 +56,12 @@ displays next to your name.
 You can submit your completed review in multiple ways:
 
 - Use the `/submit_review` [quick action](../../quick_actions.md) in the text of a non-review comment.
-- When creating a review comment, select **Submit review**.
-- Scroll to the bottom of the screen and select **Submit review**.
+- Select **Finish review** and then **Submit review** in the footer at the bottom of the screen.
+
+Selecting **Finish review** opens a modal window to add an optional comment to summarize your review.
+You can also include quick actions:
+
+![Finish review with comment](img/mr_summary_comment_v15_3.png)
 
 When you submit your review, GitLab:
 
@@ -73,25 +73,25 @@ When you submit your review, GitLab:
 ### Resolve or unresolve thread with a comment
 
 Review comments can also resolve or unresolve [resolvable threads](../../../discussions/index.md#resolve-a-thread).
-When replying to a comment, a checkbox is displayed to resolve or unresolve
-the thread after publication.
-
-![Resolve checkbox](img/mr_review_resolve.png)
+To resolve or unresolve a thread when replying to a comment:
 
-If a particular pending comment resolves or unresolves the thread, this is shown on the pending
-comment itself.
+1. In the comment text area, write your comment.
+1. Select or clear **Resolve thread**.
+1. Select **Add comment now** or **Add to review**.
 
-![Resolve status](img/mr_review_resolve2.png)
+Pending comments display information about the action to be taken when the comment is published:
 
-![Unresolve status](img/mr_review_unresolve.png)
+- **{check-circle-filled}** Thread will be resolved.
+- **{check-circle}** Thread stays unresolved.
 
 ### Add a new comment
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/8225) in GitLab 13.10.
 
-If you have a review in progress, you are presented with the option to **Add to review**:
+If you have a review in progress, you can also add a comment from the **Overview** tab by selecting
+ **Add to review**:
 
-![New thread](img/mr_review_new_comment_v13_11.png)
+![New thread](img/mr_review_new_comment_v15_3.png)
 
 ### Approval Rule information for Reviewers **(PREMIUM)**
 
diff --git a/doc/user/project/merge_requests/status_checks.md b/doc/user/project/merge_requests/status_checks.md
index 423179325d3..0d7794a3ebd 100644
--- a/doc/user/project/merge_requests/status_checks.md
+++ b/doc/user/project/merge_requests/status_checks.md
@@ -10,6 +10,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/merge_requests/statu
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab 14.0, disabled behind the `:ff_external_status_checks` feature flag.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/320783) in GitLab 14.1.
+> - `failed` status [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/329636) in GitLab 14.9.
 
 You can create a status check that sends merge request data to third-party tools.
 When users create, change, or close merge requests, GitLab sends a notification. The users or automated workflows
@@ -50,9 +51,8 @@ Merge requests return a `409 Conflict` error to any responses that do not refer
 External status checks have the following states:
 
 - `pending` - The default state. No response can been received by the merge request from the external service.
-- `response received` - A response from the external service has been received and approved by it.
-
-Support for adding a `failed` state is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338827).
+- `passed` - A response from the external service has been received and approved by it.
+- `failed` - A response from the external service has been received and denied by it.
 
 If something changes outside of GitLab, you can [set the status of an external status check](../../../api/status_checks.md#set-status-of-an-external-status-check)
 using the API. You don't need to wait for a merge request webhook payload to be sent first.
@@ -138,24 +138,18 @@ 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.
+> - UI [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91504) in GitLab 15.2.
 
-The status checks widget displays in merge requests and shows the status of external
-status checks:
+The status checks widget displays in merge requests and displays the following statuses:
 
-![Status checks widget](img/status_checks_widget_passed_v14_0.png)
+- **pending** (**{status-neutral}**), while GitLab waits for a response from an external status check.
+- **success** (**{status-success}**) or **failed** (**{status-failed}**), when GitLab receives a response from an external status check.
 
 An organization might have a policy that does not allow merging merge requests if
 external status checks do not pass. However, the details in the widget are for informational
 purposes only. GitLab does not prevent merging of merge requests that fail status checks.
-
-While GitLab waits for a response from the external status check, the widget shows
-the status checks as `pending`:
-
-![Status checks widget pending](img/status_checks_widget_pending_v14_0.png)
-
-After GitLab [receives a response](../../../api/status_checks.md#set-status-of-an-external-status-check)
-from the external status check, the widget updates accordingly.
+Support to allow merges to be blocked when external status checks fail is proposed in epic [&8516](https://gitlab.com/groups/gitlab-org/-/epics/8516).
 
 NOTE:
 GitLab cannot guarantee that the external status checks are properly processed by
diff --git a/doc/user/project/merge_requests/widgets.md b/doc/user/project/merge_requests/widgets.md
index b0464f3f972..0e179415192 100644
--- a/doc/user/project/merge_requests/widgets.md
+++ b/doc/user/project/merge_requests/widgets.md
@@ -63,6 +63,12 @@ faster to preview proposed modifications.
 
 [Read more about Review Apps](../../../ci/review_apps/index.md).
 
+## License compliance **(ULTIMATE)**
+
+If you have configured [License Compliance](../../compliance/license_compliance/index.md) for your project, then you can view a list of licenses that are detected for your project's dependencies.
+
+![Merge request pipeline](img/license_compliance_widget_v15_3.png)
+
 ## External status checks **(ULTIMATE)**
 
 If you have configured [external status checks](status_checks.md) you can
diff --git a/doc/user/project/milestones/index.md b/doc/user/project/milestones/index.md
index ba48876d4fd..ef734225fb4 100644
--- a/doc/user/project/milestones/index.md
+++ b/doc/user/project/milestones/index.md
@@ -44,6 +44,14 @@ To view the milestone list:
 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.
 
+NOTE:
+If a project has issue tracking
+[turned off](../settings/index.md#configure-project-visibility-features-and-permissions),
+you can get to the milestones page
+by going to its URL. To do so, add: `/-/milestones` to your project or group URL.
+For example `https://gitlab.com/gitlab-org/sample-data-templates/sample-gitlab-project/-/milestones`.
+This is tracked in [issue 339009](https://gitlab.com/gitlab-org/gitlab/-/issues/339009).
+
 ### View all milestones
 
 You can view all the milestones you have access to in the entire GitLab namespace.
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
index 6daf671a751..c4c30dbdab4 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
@@ -32,6 +32,7 @@ for the most popular hosting services:
 
 <!-- vale gitlab.Spelling = NO -->
 
+- [123-reg](https://www.123-reg.co.uk/support/domains/domain-name-server-dns-management-guide/)
 - [Amazon](https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html)
 - [Bluehost](https://www.bluehost.com/help/article/dns-management-add-edit-or-delete-dns-entries)
 - [Cloudflare](https://support.cloudflare.com/hc/en-us/articles/201720164-Creating-a-Cloudflare-account-and-adding-a-website)
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
index 184e4f345c1..0cc6cb808d1 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
@@ -79,8 +79,6 @@ If you get an error **Something went wrong while obtaining the Let's Encrypt cer
     1. Make sure [your domain is verified](index.md#1-add-a-custom-domain-to-pages).
     1. Go to step 1.
 
-Another possible cause of this error is the `_redirects` file because the current implementation relies on an HTTP ACME challenge. If you redirect the `.acme-challenge/` endpoint Let's Encrypt cannot validate the domain. Make sure you don't have a wildcard (`*`) redirect either as that too breaks validation. The problem with wildcard redirects is tracked in the [Wildcard redirects break Let's Encrypt integration](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/649) issue.
-
 ### Message "GitLab is obtaining a Let's Encrypt SSL certificate for this domain. This process can take some time. Please try again later." hangs for more than an hour
 
 If you've enabled Let's Encrypt integration, but a certificate is absent after an hour and you see the message, "GitLab is obtaining a Let's Encrypt SSL certificate for this domain. This process can take some time. Please try again later.", try to remove and add the domain for GitLab Pages again by following these steps:
diff --git a/doc/user/project/pages/getting_started/pages_from_scratch.md b/doc/user/project/pages/getting_started/pages_from_scratch.md
index 5fd17b5c07e..68a2a6a80ad 100644
--- a/doc/user/project/pages/getting_started/pages_from_scratch.md
+++ b/doc/user/project/pages/getting_started/pages_from_scratch.md
@@ -420,10 +420,10 @@ Now GitLab CI/CD not only builds the website, but also:
 
 For more information, see the following blog posts.
 
-- [Use GitLab CI/CD `environments` to deploy your
-  web app to staging and production](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/).
-- Learn [how to run jobs sequentially,
-  in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/).
+- Use GitLab CI/CD `environments` to 
+  [deploy your web app to staging and production](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/).
+- Learn how to run jobs
+  [sequentially, in parallel, or build a custom pipeline](https://about.gitlab.com/blog/2016/07/29/the-basics-of-gitlab-ci/).
 - Learn [how to pull specific directories from different projects](https://about.gitlab.com/blog/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/)
   to deploy this website, <https://docs.gitlab.com>.
 - Learn [how to use GitLab Pages to produce a code coverage report](https://about.gitlab.com/blog/2016/11/03/publish-code-coverage-report-with-gitlab-pages/).
diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md
index 54b843945cd..29712a82be1 100644
--- a/doc/user/project/pages/getting_started_part_one.md
+++ b/doc/user/project/pages/getting_started_part_one.md
@@ -18,7 +18,7 @@ replace the Pages wildcard domain on GitLab.com (`*.gitlab.io`) with your own.
 If you set up a GitLab Pages project on GitLab,
 it's automatically accessible under a
 subdomain of `namespace.example.io`.
-The [`namespace`](../../group/index.md#namespaces)
+The [`namespace`](../../namespace/index.md)
 is defined by your username on GitLab.com,
 or the group name you created this project under.
 For GitLab self-managed instances, replace `example.io`
diff --git a/doc/user/project/pages/img/remove_pages.png b/doc/user/project/pages/img/remove_pages.png
deleted file mode 100644
index d6c37ef30cd..00000000000
--- a/doc/user/project/pages/img/remove_pages.png
+++ /dev/null
diff --git a/doc/user/project/pages/img/remove_pages_v15_3.png b/doc/user/project/pages/img/remove_pages_v15_3.png
new file mode 100644
index 00000000000..f740daf5c0b
--- /dev/null
+++ b/doc/user/project/pages/img/remove_pages_v15_3.png
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index 1ea7500273e..3bd16a17f23 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -74,7 +74,7 @@ to your project's settings through the gear icon in the top right, and then
 navigating to **Pages**. Select the **Remove pages** button to delete your Pages
 website.
 
-![Remove pages](img/remove_pages.png)
+![Remove pages](img/remove_pages_v15_3.png)
 
 ## Subdomains of subdomains
 
@@ -297,9 +297,6 @@ A 404 can also be related to incorrect permissions. If [Pages Access Control](pa
 navigates to the Pages URL and receives a 404 response, it is possible that the user does not have permission to view the site.
 To fix this, verify that the user is a member of the project.
 
-For Geo instances, 404 errors on Pages occur after promoting a secondary to a primary.
-Find more details in the [Pages administration documentation](../../../administration/pages/index.md#404-error-after-promoting-a-geo-secondary-to-a-primary-node)
-
 ### Cannot play media content on Safari
 
 Safari requires the web server to support the [Range request header](https://developer.apple.com/library/archive/documentation/AppleApplications/Reference/SafariWebContent/CreatingVideoforSafarioniPhone/CreatingVideoforSafarioniPhone.html#//apple_ref/doc/uid/TP40006514-SW6)
diff --git a/doc/user/project/pages/pages_access_control.md b/doc/user/project/pages/pages_access_control.md
index eb897c176fa..e6446c34bf0 100644
--- a/doc/user/project/pages/pages_access_control.md
+++ b/doc/user/project/pages/pages_access_control.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Pages access control **(FREE)**
 
-> Available on GitLab.com in GitLab 12.4.
-
 You can enable Pages access control on your project
 if your administrator has [enabled the access control feature](../../../administration/pages/index.md#access-control)
 on your GitLab instance. When enabled, only authenticated
diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md
index 6ef8477b6b6..d02609cbdc7 100644
--- a/doc/user/project/push_options.md
+++ b/doc/user/project/push_options.md
@@ -95,15 +95,15 @@ git push -o merge_request.create -o merge_request.target=my-target-branch -o mer
 ## Useful Git aliases
 
 As shown above, Git push options can cause Git commands to grow very long. If
-you use the same push options frequently, it's useful to create [Git
-aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases). Git aliases
+you use the same push options frequently, it's useful to create
+[Git aliases](https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases). Git aliases
 are command line shortcuts for Git which can significantly simplify the use of
 long Git commands.
 
 ### Merge when pipeline succeeds alias
 
-To set up a Git alias for the [merge when pipeline succeeds Git push
-option](#push-options-for-merge-requests):
+To set up a Git alias for the 
+[merge when pipeline succeeds Git push option](#push-options-for-merge-requests):
 
 ```shell
 git config --global alias.mwps "push -o merge_request.create -o merge_request.target=master -o merge_request.merge_when_pipeline_succeeds"
diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md
index 96e51b061ee..216d040734d 100644
--- a/doc/user/project/quick_actions.md
+++ b/doc/user/project/quick_actions.md
@@ -56,6 +56,7 @@ threads. Some quick actions might not be available to all subscription tiers.
 | `/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.                                                                                                                                                                                                                                                                                                                                                                                                                            |
 | `/award :emoji:`                                                                                 | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Toggle emoji award.                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `/cc @user`                                                                                      | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Mention a user. In GitLab 15.0 and later, this command performs no action. You can instead type `CC @user` or only `@user`. [In GitLab 14.9 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/31200), mentioning a user at the start of a line created a specific type of to-do item notification. |
 | `/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).                                                                                                                                                                                                                                                                                                       |
 | `/clear_weight`                                                                                  | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Clear weight.                                                                                                                                                                                                                                                                                                                                                                                                                                             |
diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md
index 1d448ca5c94..d3456e086ce 100644
--- a/doc/user/project/releases/index.md
+++ b/doc/user/project/releases/index.md
@@ -32,12 +32,10 @@ When you create a release, or after, you can:
 - Add release notes.
 - Add a message for the Git tag associated with the release.
 - [Associate milestones with it](#associate-milestones-with-a-release).
-- Attach [release assets](#release-assets), like runbooks or packages.
+- Attach [release assets](release_fields.md#release-assets), like runbooks or packages.
 
 ## View releases
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36667) in GitLab 12.8.
-
 To view a list of releases:
 
 - On the left sidebar, select **Deployments > Releases**, or
@@ -81,18 +79,18 @@ To create a release in the Releases page:
 
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Deployments > Releases** and select **New release**.
-1. From the [**Tag name**](#tag-name) dropdown, either:
+1. From the [**Tag name**](release_fields.md#tag-name) dropdown, either:
    - Select an existing Git tag. Selecting an existing tag that is already associated with a release
      results in a validation error.
    - Enter a new Git tag name.
       1. From the **Create from** dropdown, select a branch or commit SHA to use when creating the
          new tag.
 1. Optional. Enter additional information about the release, including:
-   - [Title](#title).
+   - [Title](release_fields.md#title).
    - [Milestones](#associate-milestones-with-a-release).
-   - [Release notes](#release-notes-description).
+   - [Release notes](release_fields.md#release-notes-description).
    - Whether or not to include the [Tag message](../../../topics/git/tags.md).
-   - [Asset links](#links).
+   - [Asset links](release_fields.md#links).
 1. Select **Create release**.
 
 ### Create a release in the Tags page
@@ -126,99 +124,8 @@ You can create a release directly as part of the GitLab CI/CD pipeline by using
 The release is created only if the job processes without error. If the API returns an error during
 release creation, the release job fails.
 
-Methods for creating a release using a CI/CD job include:
-
-- Create a release when a Git tag is created.
-- Create a release when a commit is merged to the default branch.
-
-#### Create a release when a Git tag is created
-
-In this CI/CD example, pushing a Git tag to the repository, or creating a Git tag in the UI triggers
-the release. You can use this method if you prefer to create the Git tag manually, and create a
-release as a result.
-
-NOTE:
-Do not provide Release notes when you create the Git tag in the UI. Providing release notes
-creates a release, resulting in the pipeline failing.
-
-Key points in the following _extract_ of an example `.gitlab-ci.yml` file:
-
-- The `rules` stanza defines when the job is added to the pipeline.
-- The Git tag is used in the release's name and description.
-
-```yaml
-release_job:
-  stage: release
-  image: registry.gitlab.com/gitlab-org/release-cli:latest
-  rules:
-    - if: $CI_COMMIT_TAG                 # Run this job when a tag is created
-  script:
-    - echo "running release_job"
-  release:                               # See https://docs.gitlab.com/ee/ci/yaml/#release for available properties
-    tag_name: '$CI_COMMIT_TAG'
-    description: '$CI_COMMIT_TAG'
-```
-
-#### Create a release when a commit is merged to the default branch
-
-In this CI/CD example, merging a commit to the default branch triggers the pipeline. You can use
-this method if your release workflow does not create a tag manually.
-
-Key points in the following _extract_ of an example `.gitlab-ci.yml` file:
-
-- The Git tag, description, and reference are created automatically in the pipeline.
-- If you manually create a tag, the `release_job` job does not run.
-
-```yaml
-release_job:
-  stage: release
-  image: registry.gitlab.com/gitlab-org/release-cli:latest
-  rules:
-    - if: $CI_COMMIT_TAG
-      when: never                                  # Do not run this job when a tag is created manually
-    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Run this job when commits are pushed or merged to the default branch
-  script:
-    - echo "running release_job for $TAG"
-  release:                                         # See https://docs.gitlab.com/ee/ci/yaml/#release for available properties
-    tag_name: 'v0.$CI_PIPELINE_IID'                # The version is incremented per pipeline.
-    description: 'v0.$CI_PIPELINE_IID'
-    ref: '$CI_COMMIT_SHA'                          # The tag is created from the pipeline SHA.
-```
-
-NOTE:
-Environment variables set in `before_script` or `script` are not available for expanding
-in the same job. Read more about
-[potentially making variables available for expanding](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6400).
-
-#### Skip multiple pipelines when creating a release
-
-Creating a release using a CI/CD job could potentially trigger multiple pipelines if the associated tag does not exist already. To understand how this might happen, consider the following workflows:
-
-- Tag first, release second:
-  1. A tag is created via UI or pushed.
-  1. A tag pipeline is triggered, and runs `release` job.
-  1. A release is created.
-
-- Release first, tag second:
-  1. A pipeline is triggered when commits are pushed or merged to default branch. The pipeline runs `release` job.
-  1. A release is created.
-  1. A tag is created.
-  1. A tag pipeline is triggered. The pipeline also runs `release` job.
-
-In the second workflow, the `release` job runs in multiple pipelines. To prevent this, you can use the [`workflow:rules` keyword](../../../ci/yaml/index.md#workflowrules) to determine if a release job should run in a tag pipeline:
-
-```yaml
-release_job:
-  rules:
-    - 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:
-    - echo "Create release"
-  release:
-    name: 'My awesome release'
-    tag_name: '$CI_COMMIT_TAG'
-```
+For examples of how you can create a release of your application in the CI/CD pipeline,
+see [Release CI/CD examples](release_cicd_examples.md).
 
 ### Use a custom SSL CA certificate authority
 
@@ -250,18 +157,6 @@ The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a
 either as a `file`, which requires the path to the certificate, or as a variable,
 which requires the text representation of the certificate.
 
-### `release-cli` command line
-
-The entries under the `release` node are transformed into Bash commands and sent
-to the Docker container, which contains the [release-cli](https://gitlab.com/gitlab-org/release-cli).
-You can also call the `release-cli` directly from a `script` entry.
-
-For example, if you use the YAML described previously:
-
-```shell
-release-cli create --name "Release $CI_COMMIT_SHA" --description "Created using the release-cli $EXTRA_DESCRIPTION" --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3" --assets-link "{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
-```
-
 ### Create multiple releases in a single pipeline
 
 A pipeline can have multiple `release` jobs, for example:
@@ -298,10 +193,17 @@ release tag. When the `released_at` date and time has passed, the badge is autom
 
 ![An upcoming release](img/upcoming_release_v12_7.png)
 
-## Edit a release
+## Historical releases
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199429) in GitLab 15.2.
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26016) in GitLab 12.6.
-> - Asset link editing [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9427) in GitLab 12.10.
+You can create a release in the past using either the
+[Releases API](../../../api/releases/index.md#historical-releases) or the UI. When you set
+a past `released_at` date, an **Historical release** badge is displayed next to
+the release tag. Due to being released in the past, [release evidence](#release-evidence)
+is not available.
+
+## Edit a release
 
 Only users with at least the Developer role can edit releases.
 Read more about [Release permissions](#release-permissions).
@@ -430,277 +332,6 @@ complete overlapping period.
 
 For more information, see [Deployment safety](../../../ci/environments/deployment_safety.md).
 
-## Release fields
-
-The following fields are available when you create or edit a release.
-
-### Title
-
-The release title can be customized using the **Release title** field when
-creating or editing a release. If no title is provided, the release's tag name
-is used instead.
-
-### Tag name
-
-The release tag name should include the release version. GitLab uses [Semantic Versioning](https://semver.org/)
-for our releases, and we recommend you do too. Use `(Major).(Minor).(Patch)`, as detailed in the
-[GitLab Policy for Versioning](../../../policy/maintenance.md#versioning).
-
-For example, for GitLab version `10.5.7`:
-
-- `10` represents the major version. The major release was `10.0.0`, but often referred to as `10.0`.
-- `5` represents the minor version. The minor release was `10.5.0`, but often referred to as `10.5`.
-- `7` represents the patch number.
-
-Any part of the version number can be multiple digits, for example, `13.10.11`.
-
-### Release notes description
-
-Every release has a description. You can add any text you like, but we recommend
-including a changelog to describe the content of your release. This helps users
-quickly scan the differences between each release you publish.
-
-[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) can
-be included in Release note descriptions by selecting **Include tag message in
-the release notes**.
-
-Description supports [Markdown](../../markdown.md).
-
-### Release assets
-
-A release contains the following types of assets:
-
-- [Source code](#source-code)
-- [Link](#links)
-
-#### Source code
-
-GitLab automatically generates `zip`, `tar.gz`, `tar.bz2`, and `tar`
-archived source code from the given Git tag. These are read-only assets.
-
-#### Links
-
-A link is any URL which can point to whatever you like: documentation, built
-binaries, or other related materials. These can be both internal or external
-links from your GitLab instance.
-Each link as an asset has the following attributes:
-
-| Attribute   | Description                            | Required |
-| ----        | -----------                            | ---      |
-| `name`      | The name of the link.                  | Yes      |
-| `url`       | The URL to download a file.            | Yes      |
-| `filepath`  | The redirect link to the `url`. See [this section](#permanent-links-to-release-assets) for more information. | No       |
-| `link_type` | The content kind of what users can download via `url`. See [this section](#link-types) for more information. | No       |
-
-##### Permanent link to latest release
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16821) in GitLab 14.9.
-
-Latest release page is accessible through a permanent URL.
-GitLab will redirect to the latest release page URL when it is visited.
-
-The format of the URL is:
-
-```plaintext
-https://host/namespace/project/-/releases/permalink/latest
-```
-
-We also support, suffix path carry forward on the redirect to the latest release.
-Example if release `v14.8.0-ee` is the latest release and has a readable link `https://host/namespace/project/-/releases/v14.8.0-ee#release` then it can be addressed as `https://host/namespace/project/-/releases/permalink/latest#release`.
-
-Refer [permanent links to latest release assets](#permanent-links-to-latest-release-assets) section to understand more about the suffix path carry forward usage.
-
-###### Sorting preferences
-
-By default, GitLab fetches the release using `released_at` time. The use of the query parameter `?order_by=released_at` is optional, and support for `?order_by=semver` is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352945).
-
-##### Permanent links to release assets
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27300) in GitLab 12.9.
-
-The assets associated with a release are accessible through a permanent URL.
-GitLab always redirects this URL to the actual asset
-location, so even if the assets move to a different location, you can continue
-to use the same URL. This is defined during [link creation](../../../api/releases/links.md#create-a-link) or [updating](../../../api/releases/links.md#update-a-link) using the `filepath` API attribute.
-
-The format of the URL is:
-
-```plaintext
-https://host/namespace/project/-/releases/:release/downloads/:filepath
-```
-
-If you have an asset for the `v11.9.0-rc2` release in the `gitlab-org`
-namespace and `gitlab-runner` project on `gitlab.com`, for example:
-
-```json
-{
-  "name": "linux amd64",
-  "filepath": "/binaries/gitlab-runner-linux-amd64",
-  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64",
-  "link_type": "other"
-}
-```
-
-This asset has a direct link of:
-
-```plaintext
-https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v11.9.0-rc2/downloads/binaries/gitlab-runner-linux-amd64
-```
-
-The physical location of the asset can change at any time and the direct link remains unchanged.
-
-##### Permanent links to latest release assets
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16821) in GitLab 14.9.
-
-The `filepath` from [permanent links to release assets](#permanent-links-to-release-assets) can be used in combination with [permanent link to the latest release](#permanent-link-to-latest-release). It is useful when we want to link a permanent URL to download an asset from the *latest release*.
-
-The format of the URL is:
-
-```plaintext
-https://host/namespace/project/-/releases/permalink/latest/downloads/:filepath
-```
-
-If you have an asset with [`filepath`](../../../api/releases/links.md#create-a-link) for the `v11.9.0-rc2` latest release in the `gitlab-org`
-namespace and `gitlab-runner` project on `gitlab.com`, for example:
-
-```json
-{
-  "name": "linux amd64",
-  "filepath": "/binaries/gitlab-runner-linux-amd64",
-  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64",
-  "link_type": "other"
-}
-```
-
-This asset has a direct link of:
-
-```plaintext
-https://gitlab.com/gitlab-org/gitlab-runner/-/releases/permalink/latest/downloads/binaries/gitlab-runner-linux-amd64
-```
-
-##### Link Types
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207257) in GitLab 13.1.
-
-The four types of links are "Runbook," "Package," "Image," and "Other."
-The `link_type` parameter accepts one of the following four values:
-
-- `runbook`
-- `package`
-- `image`
-- `other` (default)
-
-This field has no effect on the URL and it's only used for visual purposes in the Releases page of your project.
-
-##### Use a generic package for attaching binaries
-
-You can use [generic packages](../../packages/generic_packages/index.md)
-to store any artifacts from a release or tag pipeline,
-that can also be used for attaching binary files to an individual release entry.
-You basically need to:
-
-1. [Push the artifacts to the Generic Package Registry](../../packages/generic_packages/index.md#publish-a-package-file).
-1. [Attach the package link to the release](#links).
-
-The following example generates release assets, publishes them
-as a generic package, and then creates a release:
-
-```yaml
-stages:
-  - build
-  - upload
-  - release
-
-variables:
-  # Package version can only contain numbers (0-9), and dots (.).
-  # Must be in the format of X.Y.Z, i.e. should match /\A\d+\.\d+\.\d+\z/ regular expresion.
-  # See https://docs.gitlab.com/ee/user/packages/generic_packages/#publish-a-package-file
-  PACKAGE_VERSION: "1.2.3"
-  DARWIN_AMD64_BINARY: "myawesomerelease-darwin-amd64-${PACKAGE_VERSION}"
-  LINUX_AMD64_BINARY: "myawesomerelease-linux-amd64-${PACKAGE_VERSION}"
-  PACKAGE_REGISTRY_URL: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/myawesomerelease/${PACKAGE_VERSION}"
-
-build:
-  stage: build
-  image: alpine:latest
-  rules:
-    - if: $CI_COMMIT_TAG
-  script:
-    - mkdir bin
-    - echo "Mock binary for ${DARWIN_AMD64_BINARY}" > bin/${DARWIN_AMD64_BINARY}
-    - echo "Mock binary for ${LINUX_AMD64_BINARY}" > bin/${LINUX_AMD64_BINARY}
-  artifacts:
-    paths:
-      - bin/
-
-upload:
-  stage: upload
-  image: curlimages/curl:latest
-  rules:
-    - if: $CI_COMMIT_TAG
-  script:
-    - |
-      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file bin/${DARWIN_AMD64_BINARY} "${PACKAGE_REGISTRY_URL}/${DARWIN_AMD64_BINARY}"
-    - |
-      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file bin/${LINUX_AMD64_BINARY} "${PACKAGE_REGISTRY_URL}/${LINUX_AMD64_BINARY}"
-
-release:
-  # Caution, as of 2021-02-02 these assets links require a login, see:
-  # https://gitlab.com/gitlab-org/gitlab/-/issues/299384
-  stage: release
-  image: registry.gitlab.com/gitlab-org/release-cli:latest
-  rules:
-    - if: $CI_COMMIT_TAG
-  script:
-    - |
-      release-cli create --name "Release $CI_COMMIT_TAG" --tag-name $CI_COMMIT_TAG \
-        --assets-link "{\"name\":\"${DARWIN_AMD64_BINARY}\",\"url\":\"${PACKAGE_REGISTRY_URL}/${DARWIN_AMD64_BINARY}\"}" \
-        --assets-link "{\"name\":\"${LINUX_AMD64_BINARY}\",\"url\":\"${PACKAGE_REGISTRY_URL}/${LINUX_AMD64_BINARY}\"}"
-```
-
-PowerShell users may need to escape the double quote `"` inside a JSON
-string with a `` ` `` (back tick) for `--assets-link` and `ConvertTo-Json`
-before passing on to the `release-cli`.
-For example:
-
-```yaml
-release:
-  script:
-    - $env:asset = "{`"name`":`"MyFooAsset`",`"url`":`"https://gitlab.com/upack/artifacts/download/$env:UPACK_GROUP/$env:UPACK_NAME/$($env:GitVersion_SemVer)?contentOnly=zip`"}"
-    - $env:assetjson = $env:asset | ConvertTo-Json
-    - release-cli create --name $CI_COMMIT_TAG --description "Release $CI_COMMIT_TAG" --ref $CI_COMMIT_TAG --tag-name $CI_COMMIT_TAG --assets-link=$env:assetjson
-```
-
-NOTE:
-Directly attaching [job artifacts](../../../ci/pipelines/job_artifacts.md)
-links to a release is not recommended, because artifacts are ephemeral and
-are used to pass data in the same pipeline. This means there's a risk that
-they could either expire or someone might manually delete them.
-
-#### Number of new and total features **(FREE SAAS)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235618) in GitLab 13.5.
-
-On [GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/releases), you can view the number of new and total features in the project.
-
-![Feature count](img/feature_count_v14_6.png "Number of features in a release")
-
-The totals are displayed on [shields](https://shields.io/) and are generated per release by
-[a Rake task in the `www-gitlab-com` repository](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/lib/tasks/update_gitlab_project_releases_page.rake).
-
-| Item    | Formula |
-| ------  | ------ |
-| `New features`   | Total count of release posts across all tiers for a single release in the project. |
-| `Total features` | Total count of release posts in reverse order for all releases in the project. |
-
-The counts are also shown by license tier.
-
-| Item    | Formula |
-| ------  | ------ |
-| `New features`   | Total count of release posts across a single tier for a single release in the project. |
-| `Total features` | Total count of release posts across a single tier in reverse order for all releases in the project. |
-
 ## Release evidence
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26019) in GitLab 12.6.
@@ -828,10 +459,11 @@ keyword. Learn more in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issue
 
 In the API:
 
-- If you specify a future `released_at` date, the release becomes an **Upcoming Release**
+- If you specify a future `released_at` date, the release becomes an **Upcoming release**
   and the evidence is collected on the date of the release. You cannot collect
   release evidence before then.
-- If you use a past `released_at` date, no evidence is collected.
+- If you specify a past `released_at` date, the release becomes an **Historical
+  release** and no evidence is collected.
 - If you do not specify a `released_at` date, release evidence is collected on the
   date the release is created.
 
@@ -848,7 +480,7 @@ In the API:
 - Users with the Guest role
   have read and download access to the project releases.
   This includes associated Git-tag-names, release description, author information of the releases.
-  However, other repository-related information, such as [source code](#source-code), [release evidence](#release-evidence) are redacted.
+  However, other repository-related information, such as [source code](release_fields.md#source-code), [release evidence](#release-evidence) are redacted.
 
 ### Create, update, and delete a release and its assets
 
@@ -862,19 +494,6 @@ users with at least the Maintainer role
 to create, update, and delete releases by protecting the tag with a wildcard (`*`),
 and set **Maintainer** in the **Allowed to create** column.
 
-## Release Command Line
-
-> [Introduced](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/6) in GitLab 12.10.
-
-The Release CLI is a command-line tool for managing GitLab Releases from the command line or from
-the GitLab CI/CD configuration file, `.gitlab-ci.yml`.
-
-With it, you can create, update, modify, and delete releases right through the
-terminal.
-
-Read the [Release CLI documentation](https://gitlab.com/gitlab-org/release-cli/-/blob/master/docs/index.md)
-for details.
-
 ## Release Metrics **(ULTIMATE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259703) in GitLab Premium 13.9.
diff --git a/doc/user/project/releases/release_cicd_examples.md b/doc/user/project/releases/release_cicd_examples.md
new file mode 100644
index 00000000000..f1d3e55a707
--- /dev/null
+++ b/doc/user/project/releases/release_cicd_examples.md
@@ -0,0 +1,100 @@
+---
+stage: Release
+group: Release
+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
+---
+
+# Release CI/CD examples
+
+GitLab release functionality is flexible, able to be configured to match your workflow. This page
+features example CI/CD release jobs. Each example demonstrates a method of creating a release in a
+CI/CD pipeline.
+
+## Create a release when a Git tag is created
+
+In this CI/CD example, pushing a Git tag to the repository, or creating a Git tag in the UI triggers
+the release. You can use this method if you prefer to create the Git tag manually, and create a
+release as a result.
+
+NOTE:
+Do not provide Release notes when you create the Git tag in the UI. Providing release notes
+creates a release, resulting in the pipeline failing.
+
+Key points in the following _extract_ of an example `.gitlab-ci.yml` file:
+
+- The `rules` stanza defines when the job is added to the pipeline.
+- The Git tag is used in the release's name and description.
+
+```yaml
+release_job:
+  stage: release
+  image: registry.gitlab.com/gitlab-org/release-cli:latest
+  rules:
+    - if: $CI_COMMIT_TAG                 # Run this job when a tag is created
+  script:
+    - echo "running release_job"
+  release:                               # See https://docs.gitlab.com/ee/ci/yaml/#release for available properties
+    tag_name: '$CI_COMMIT_TAG'
+    description: '$CI_COMMIT_TAG'
+```
+
+## Create a release when a commit is merged to the default branch
+
+In this CI/CD example, merging a commit to the default branch triggers the pipeline. You can use
+this method if your release workflow does not create a tag manually.
+
+Key points in the following _extract_ of an example `.gitlab-ci.yml` file:
+
+- The Git tag, description, and reference are created automatically in the pipeline.
+- If you manually create a tag, the `release_job` job does not run.
+
+```yaml
+release_job:
+  stage: release
+  image: registry.gitlab.com/gitlab-org/release-cli:latest
+  rules:
+    - if: $CI_COMMIT_TAG
+      when: never                                  # Do not run this job when a tag is created manually
+    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # Run this job when commits are pushed or merged to the default branch
+  script:
+    - echo "running release_job for $TAG"
+  release:                                         # See https://docs.gitlab.com/ee/ci/yaml/#release for available properties
+    tag_name: 'v0.$CI_PIPELINE_IID'                # The version is incremented per pipeline.
+    description: 'v0.$CI_PIPELINE_IID'
+    ref: '$CI_COMMIT_SHA'                          # The tag is created from the pipeline SHA.
+```
+
+NOTE:
+Environment variables set in `before_script` or `script` are not available for expanding
+in the same job. Read more about
+[potentially making variables available for expanding](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6400).
+
+## Skip multiple pipelines when creating a release
+
+Creating a release using a CI/CD job could potentially trigger multiple pipelines if the associated tag does not exist already. To understand how this might happen, consider the following workflows:
+
+- Tag first, release second:
+  1. A tag is created via UI or pushed.
+  1. A tag pipeline is triggered, and runs `release` job.
+  1. A release is created.
+
+- Release first, tag second:
+  1. A pipeline is triggered when commits are pushed or merged to default branch. The pipeline runs `release` job.
+  1. A release is created.
+  1. A tag is created.
+  1. A tag pipeline is triggered. The pipeline also runs `release` job.
+
+In the second workflow, the `release` job runs in multiple pipelines. To prevent this, you can use the [`workflow:rules` keyword](../../../ci/yaml/index.md#workflowrules) to determine if a release job should run in a tag pipeline:
+
+```yaml
+release_job:
+  rules:
+    - 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:
+    - echo "Create release"
+  release:
+    name: 'My awesome release'
+    tag_name: '$CI_COMMIT_TAG'
+```
diff --git a/doc/user/project/releases/release_cli.md b/doc/user/project/releases/release_cli.md
index b55f0b0a734..9e65ab4bc01 100644
--- a/doc/user/project/releases/release_cli.md
+++ b/doc/user/project/releases/release_cli.md
@@ -4,16 +4,38 @@ group: Release
 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
 ---
 
-# Install the `release-cli` for the Shell executor **(FREE)**
+
+# GitLab Release CLI tool
+
+The [GitLab Release CLI (`release-cli`)](https://gitlab.com/gitlab-org/release-cli) tool
+is a command-line tool for managing releases from the command line or from a CI/CD pipeline.
+You can use the release CLI to create, update, modify, and delete releases.
+
+When you [use a CI/CD job to create a release](index.md#creating-a-release-by-using-a-cicd-job),
+the `release` keyword entries are transformed into Bash commands and sent to the Docker
+container containing the `release-cli` tool. The tool then creates the release.
+
+You can also call the `release-cli` tool directly from a [`script`](../../../ci/yaml/index.md#script).
+For example:
+
+```shell
+release-cli create --name "Release $CI_COMMIT_SHA" --description \
+  "Created using the release-cli $EXTRA_DESCRIPTION" \
+  --tag-name "v${MAJOR}.${MINOR}.${REVISION}" --ref "$CI_COMMIT_SHA" \
+  --released-at "2020-07-15T08:00:00Z" --milestone "m1" --milestone "m2" --milestone "m3" \
+  --assets-link "{\"name\":\"asset1\",\"url\":\"https://example.com/assets/1\",\"link_type\":\"other\"}
+```
+
+## Install the `release-cli` for the Shell executor **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/release-cli/-/issues/21) in GitLab 13.8.
-> - [Changed](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/108) in GitLab 14.2, the `release-cli` binaries are also [available in the Package Registry](https://gitlab.com/jaime/release-cli/-/packages).
+> - [Changed](https://gitlab.com/gitlab-org/release-cli/-/merge_requests/108) in GitLab 14.2, the `release-cli` binaries are also [available in the Package Registry](https://gitlab.com/gitlab-org/release-cli/-/packages).
 
 When you use a runner with the Shell executor, you can download and install
 the `release-cli` manually for your [supported OS and architecture](https://release-cli-downloads.s3.amazonaws.com/latest/index.html).
 Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is available to use in your CI/CD jobs.
 
-## Install on Unix/Linux
+### Install on Unix/Linux
 
 1. Download the binary for your system from S3, in the following example for amd64 systems:
 
@@ -41,7 +63,7 @@ Once installed, [the `release` keyword](../../../ci/yaml/index.md#release) is av
    release-cli version 0.6.0
    ```
 
-## Install on Windows PowerShell
+### Install on Windows PowerShell
 
 1. Create a folder somewhere in your system, for example `C:\GitLab\Release-CLI\bin`
 
diff --git a/doc/user/project/releases/release_fields.md b/doc/user/project/releases/release_fields.md
new file mode 100644
index 00000000000..647cac9c38e
--- /dev/null
+++ b/doc/user/project/releases/release_fields.md
@@ -0,0 +1,274 @@
+---
+stage: Release
+group: Release
+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
+---
+
+# Release fields
+
+The following fields are available when you create or edit a release.
+
+## Title
+
+The release title can be customized using the **Release title** field when
+creating or editing a release. If no title is provided, the release's tag name
+is used instead.
+
+## Tag name
+
+The release tag name should include the release version. GitLab uses [Semantic Versioning](https://semver.org/)
+for our releases, and we recommend you do too. Use `(Major).(Minor).(Patch)`, as detailed in the
+[GitLab Policy for Versioning](../../../policy/maintenance.md#versioning).
+
+For example, for GitLab version `10.5.7`:
+
+- `10` represents the major version. The major release was `10.0.0`, but often referred to as `10.0`.
+- `5` represents the minor version. The minor release was `10.5.0`, but often referred to as `10.5`.
+- `7` represents the patch number.
+
+Any part of the version number can be multiple digits, for example, `13.10.11`.
+
+## Release notes description
+
+Every release has a description. You can add any text you like, but we recommend
+including a changelog to describe the content of your release. This helps users
+quickly scan the differences between each release you publish.
+
+[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) can
+be included in Release note descriptions by selecting **Include tag message in
+the release notes**.
+
+Description supports [Markdown](../../markdown.md).
+
+## Release assets
+
+A release contains the following types of assets:
+
+- [Source code](#source-code)
+- [Link](#links)
+
+### Source code
+
+GitLab automatically generates `zip`, `tar.gz`, `tar.bz2`, and `tar`
+archived source code from the given Git tag. These are read-only assets.
+
+### Links
+
+A link is any URL which can point to whatever you like: documentation, built
+binaries, or other related materials. These can be both internal or external
+links from your GitLab instance.
+Each link as an asset has the following attributes:
+
+| Attribute   | Description                                                                                                  | Required |
+|-------------|--------------------------------------------------------------------------------------------------------------|----------|
+| `name`      | The name of the link.                                                                                        | Yes      |
+| `url`       | The URL to download a file.                                                                                  | Yes      |
+| `filepath`  | The redirect link to the `url`. See [this section](#permanent-links-to-release-assets) for more information. | No       |
+| `link_type` | The content kind of what users can download via `url`. See [this section](#link-types) for more information. | No       |
+
+#### Permanent link to latest release
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16821) in GitLab 14.9.
+
+Latest release page is accessible through a permanent URL.
+GitLab redirects to the latest release page URL when it is visited.
+
+The format of the URL is:
+
+```plaintext
+https://host/namespace/project/-/releases/permalink/latest
+```
+
+We also support, suffix path carry forward on the redirect to the latest release.
+Example if release `v14.8.0-ee` is the latest release and has a readable link `https://host/namespace/project/-/releases/v14.8.0-ee#release` then it can be addressed as `https://host/namespace/project/-/releases/permalink/latest#release`.
+
+Refer [permanent links to latest release assets](#permanent-links-to-latest-release-assets) section to understand more about the suffix path carry forward usage.
+
+##### Sorting preferences
+
+By default, GitLab fetches the release using `released_at` time. The use of the query parameter `?order_by=released_at` is optional, and support for `?order_by=semver` is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352945).
+
+#### Permanent links to release assets
+
+The assets associated with a release are accessible through a permanent URL.
+GitLab always redirects this URL to the actual asset
+location, so even if the assets move to a different location, you can continue
+to use the same URL. This is defined during [link creation](../../../api/releases/links.md#create-a-link) or [updating](../../../api/releases/links.md#update-a-link) using the `filepath` API attribute.
+
+The format of the URL is:
+
+```plaintext
+https://host/namespace/project/-/releases/:release/downloads/:filepath
+```
+
+If you have an asset for the `v11.9.0-rc2` release in the `gitlab-org`
+namespace and `gitlab-runner` project on `gitlab.com`, for example:
+
+```json
+{
+  "name": "linux amd64",
+  "filepath": "/binaries/gitlab-runner-linux-amd64",
+  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64",
+  "link_type": "other"
+}
+```
+
+This asset has a direct link of:
+
+```plaintext
+https://gitlab.com/gitlab-org/gitlab-runner/-/releases/v11.9.0-rc2/downloads/binaries/gitlab-runner-linux-amd64
+```
+
+The physical location of the asset can change at any time and the direct link remains unchanged.
+
+#### Permanent links to latest release assets
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/16821) in GitLab 14.9.
+
+The `filepath` from [permanent links to release assets](#permanent-links-to-release-assets) can be used in combination with [permanent link to the latest release](#permanent-link-to-latest-release). It is useful when we want to link a permanent URL to download an asset from the *latest release*.
+
+The format of the URL is:
+
+```plaintext
+https://host/namespace/project/-/releases/permalink/latest/downloads/:filepath
+```
+
+If you have an asset with [`filepath`](../../../api/releases/links.md#create-a-link) for the `v11.9.0-rc2` latest release in the `gitlab-org`
+namespace and `gitlab-runner` project on `gitlab.com`, for example:
+
+```json
+{
+  "name": "linux amd64",
+  "filepath": "/binaries/gitlab-runner-linux-amd64",
+  "url": "https://gitlab-runner-downloads.s3.amazonaws.com/v11.9.0-rc2/binaries/gitlab-runner-linux-amd64",
+  "link_type": "other"
+}
+```
+
+This asset has a direct link of:
+
+```plaintext
+https://gitlab.com/gitlab-org/gitlab-runner/-/releases/permalink/latest/downloads/binaries/gitlab-runner-linux-amd64
+```
+
+#### Link Types
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/207257) in GitLab 13.1.
+
+The four types of links are "Runbook," "Package," "Image," and "Other."
+The `link_type` parameter accepts one of the following four values:
+
+- `runbook`
+- `package`
+- `image`
+- `other` (default)
+
+This field has no effect on the URL and it's only used for visual purposes in the Releases page of your project.
+
+#### Use a generic package for attaching binaries
+
+You can use [generic packages](../../packages/generic_packages/index.md)
+to store any artifacts from a release or tag pipeline,
+that can also be used for attaching binary files to an individual release entry.
+You basically need to:
+
+1. [Push the artifacts to the Generic Package Registry](../../packages/generic_packages/index.md#publish-a-package-file).
+1. [Attach the package link to the release](#links).
+
+The following example generates release assets, publishes them
+as a generic package, and then creates a release:
+
+```yaml
+stages:
+  - build
+  - upload
+  - release
+
+variables:
+  # Package version can only contain numbers (0-9), and dots (.).
+  # Must be in the format of X.Y.Z, i.e. should match /\A\d+\.\d+\.\d+\z/ regular expresion.
+  # See https://docs.gitlab.com/ee/user/packages/generic_packages/#publish-a-package-file
+  PACKAGE_VERSION: "1.2.3"
+  DARWIN_AMD64_BINARY: "myawesomerelease-darwin-amd64-${PACKAGE_VERSION}"
+  LINUX_AMD64_BINARY: "myawesomerelease-linux-amd64-${PACKAGE_VERSION}"
+  PACKAGE_REGISTRY_URL: "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/generic/myawesomerelease/${PACKAGE_VERSION}"
+
+build:
+  stage: build
+  image: alpine:latest
+  rules:
+    - if: $CI_COMMIT_TAG
+  script:
+    - mkdir bin
+    - echo "Mock binary for ${DARWIN_AMD64_BINARY}" > bin/${DARWIN_AMD64_BINARY}
+    - echo "Mock binary for ${LINUX_AMD64_BINARY}" > bin/${LINUX_AMD64_BINARY}
+  artifacts:
+    paths:
+      - bin/
+
+upload:
+  stage: upload
+  image: curlimages/curl:latest
+  rules:
+    - if: $CI_COMMIT_TAG
+  script:
+    - |
+      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file bin/${DARWIN_AMD64_BINARY} "${PACKAGE_REGISTRY_URL}/${DARWIN_AMD64_BINARY}"
+    - |
+      curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file bin/${LINUX_AMD64_BINARY} "${PACKAGE_REGISTRY_URL}/${LINUX_AMD64_BINARY}"
+
+release:
+  # Caution, as of 2021-02-02 these assets links require a login, see:
+  # https://gitlab.com/gitlab-org/gitlab/-/issues/299384
+  stage: release
+  image: registry.gitlab.com/gitlab-org/release-cli:latest
+  rules:
+    - if: $CI_COMMIT_TAG
+  script:
+    - |
+      release-cli create --name "Release $CI_COMMIT_TAG" --tag-name $CI_COMMIT_TAG \
+        --assets-link "{\"name\":\"${DARWIN_AMD64_BINARY}\",\"url\":\"${PACKAGE_REGISTRY_URL}/${DARWIN_AMD64_BINARY}\"}" \
+        --assets-link "{\"name\":\"${LINUX_AMD64_BINARY}\",\"url\":\"${PACKAGE_REGISTRY_URL}/${LINUX_AMD64_BINARY}\"}"
+```
+
+PowerShell users may need to escape the double quote `"` inside a JSON
+string with a `` ` `` (back tick) for `--assets-link` and `ConvertTo-Json`
+before passing on to the `release-cli`.
+For example:
+
+```yaml
+release:
+  script:
+    - $env:asset = "{`"name`":`"MyFooAsset`",`"url`":`"https://gitlab.com/upack/artifacts/download/$env:UPACK_GROUP/$env:UPACK_NAME/$($env:GitVersion_SemVer)?contentOnly=zip`"}"
+    - $env:assetjson = $env:asset | ConvertTo-Json
+    - release-cli create --name $CI_COMMIT_TAG --description "Release $CI_COMMIT_TAG" --ref $CI_COMMIT_TAG --tag-name $CI_COMMIT_TAG --assets-link=$env:assetjson
+```
+
+NOTE:
+Directly attaching [job artifacts](../../../ci/pipelines/job_artifacts.md)
+links to a release is not recommended, because artifacts are ephemeral and
+are used to pass data in the same pipeline. This means there's a risk that
+they could either expire or someone might manually delete them.
+
+### Number of new and total features **(FREE SAAS)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/235618) in GitLab 13.5.
+
+On [GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/releases), you can view the number of new and total features in the project.
+
+![Feature count](img/feature_count_v14_6.png "Number of features in a release")
+
+The totals are displayed on [shields](https://shields.io/) and are generated per release by
+[a Rake task in the `www-gitlab-com` repository](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/lib/tasks/update_gitlab_project_releases_page.rake).
+
+| Item             | Formula                                                                            |
+|------------------|------------------------------------------------------------------------------------|
+| `New features`   | Total count of release posts across all tiers for a single release in the project. |
+| `Total features` | Total count of release posts in reverse order for all releases in the project.     |
+
+The counts are also shown by license tier.
+
+| Item             | Formula                                                                                             |
+|------------------|-----------------------------------------------------------------------------------------------------|
+| `New features`   | Total count of release posts across a single tier for a single release in the project.              |
+| `Total features` | Total count of release posts across a single tier in reverse order for all releases in the project. |
diff --git a/doc/user/project/repository/branches/default.md b/doc/user/project/repository/branches/default.md
index 747da817195..3083ca5da3c 100644
--- a/doc/user/project/repository/branches/default.md
+++ b/doc/user/project/repository/branches/default.md
@@ -110,7 +110,7 @@ This setting applies only to each repository's default branch. To protect other
 you must either:
 
 - Configure [branch protection in the repository](../../../project/protected_branches.md).
-- Configure [branch protection for groups](../../../group/index.md#change-the-default-branch-protection-of-a-group).
+- Configure [branch protection for groups](../../../group/manage.md#change-the-default-branch-protection-of-a-group).
 
 Administrators of self-managed instances can customize the initial default branch protection for projects hosted on that instance. Individual
 groups and subgroups can override this instance-wide setting for their projects.
diff --git a/doc/user/project/repository/forking_workflow.md b/doc/user/project/repository/forking_workflow.md
index 85bea80f777..df75f19ea6c 100644
--- a/doc/user/project/repository/forking_workflow.md
+++ b/doc/user/project/repository/forking_workflow.md
@@ -26,7 +26,7 @@ To fork an existing project in GitLab:
 1. On the project's home page, in the top right, select **{fork}** **Fork**:
    ![Fork this project](img/forking_workflow_fork_button_v13_10.png)
 1. Optional. Edit the **Project name**.
-1. For **Project URL**, select the [namespace](../../group/index.md#namespaces)
+1. For **Project URL**, select the [namespace](../../namespace/index.md)
    your fork should belong to.
 1. Add a **Project slug**. This value becomes part of the URL to your fork.
    It must be unique in the namespace.
diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md
index a8937d4f705..8e1286548b9 100644
--- a/doc/user/project/repository/index.md
+++ b/doc/user/project/repository/index.md
@@ -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#rename-a-repository):
+[change a group path](../../group/manage.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 93b94ac0641..ba425ae3dc7 100644
--- a/doc/user/project/repository/managing_large_repositories.md
+++ b/doc/user/project/repository/managing_large_repositories.md
@@ -16,6 +16,8 @@ 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.
 
+To analyze if the repository has these sorts of objects, it's recommended to run [`git-sizer`](https://github.com/github/git-sizer) to get a detailed analysis. This tool shows in detail what makes up the repository as well as highlights any areas of concern.
+
 Refer to the [Git LFS documentation for more information](../../../topics/git/lfs/index.md).
 
 ## Gitaly Pack Objects Cache
@@ -32,7 +34,7 @@ In these types of setups it's recommended that the GitLab environment used match
 
 ## Gitaly Cluster
 
-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.
+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 documentation for more information](../../../administration/gitaly/index.md), specifically the [Before deploying Gitaly Cluster](../../../administration/gitaly/index.md#before-deploying-gitaly-cluster) section.
 
diff --git a/doc/user/project/repository/mirror/index.md b/doc/user/project/repository/mirror/index.md
index 4537f8520cd..b08530c34b3 100644
--- a/doc/user/project/repository/mirror/index.md
+++ b/doc/user/project/repository/mirror/index.md
@@ -17,8 +17,8 @@ Subscribe to the issue to follow its progress.
 
 Several mirroring methods exist:
 
-- [Push](push.md): for mirroring a GitLab repository to another location.
-- [Pull](pull.md): for mirroring a repository from another location to GitLab.
+- [Push](push.md): Mirror a repository from GitLab to another location.
+- [Pull](pull.md): Mirror a repository from another location to a GitLab Premium instance.
 - [Bidirectional](bidirectional.md) mirroring is also available, but can cause conflicts.
 
 Mirror a repository when:
@@ -113,6 +113,11 @@ GitLab supports these authentication methods:
 - [SSH authentication](#ssh-authentication).
 - Password.
 
+When using password authentication, ensure you specify the username.
+For a [project access token](../../settings/project_access_tokens.md) or
+[group access token](../../../group/settings/group_access_tokens.md),
+use the username (not token name) and the token as the password.
+
 ### SSH authentication
 
 SSH authentication is mutual:
@@ -226,7 +231,7 @@ This error can occur when a firewall performs a `Deep SSH Inspection` on outgoin
 ### Could not read username: terminal prompts disabled
 
 If you receive this error after creating a new project using
-[GitLab CI/CD for external repositories](../../../../ci/ci_cd_for_external_repos/):
+[GitLab CI/CD for external repositories](../../../../ci/ci_cd_for_external_repos/index.md):
 
 - In Bitbucket Cloud:
 
diff --git a/doc/user/project/repository/mirror/pull.md b/doc/user/project/repository/mirror/pull.md
index 88104e34eb4..d0f2b9a8088 100644
--- a/doc/user/project/repository/mirror/pull.md
+++ b/doc/user/project/repository/mirror/pull.md
@@ -28,6 +28,11 @@ local repository, GitLab stops updating the branch. This prevents data loss.
 Deleted branches and tags in the upstream repository are not reflected in the
 downstream repository.
 
+NOTE:
+Items deleted from the downstream pull mirror repository, but still in the upstream repository,
+are restored upon the next pull. For example: a branch deleted _only_ in the mirrored repository
+reappears after the next pull.
+
 ## How pull mirroring works
 
 After you configure a GitLab repository as a pull mirror:
diff --git a/doc/user/project/repository/push_rules.md b/doc/user/project/repository/push_rules.md
index 592aff85434..46a9585604e 100644
--- a/doc/user/project/repository/push_rules.md
+++ b/doc/user/project/repository/push_rules.md
@@ -25,7 +25,7 @@ For custom push rules use [server hooks](../../../administration/server_hooks.md
 ## Enable global push rules
 
 You can create push rules for all new projects to inherit, but they can be overridden
-at the project level or the [group level](../../group/index.md#group-push-rules).
+at the project level or the [group level](../../group/access_and_permissions.md#group-push-rules).
 All projects created after you configure global push rules inherit this
 configuration. However, each existing project must be updated manually, using the
 process described in [Override global push rules per project](#override-global-push-rules-per-project).
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 b0ae1b7d1e0..344c288b607 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
@@ -46,8 +46,8 @@ To purge files from a GitLab repository:
    [`git-sizer`](https://github.com/github/git-sizer#getting-started)
    using a supported package manager or from source.
 
-1. Generate a fresh [export from the
-   project](../settings/import_export.html#export-a-project-and-its-data) and download it.
+1. Generate a fresh 
+   [export from the project](../settings/import_export.md#export-a-project-and-its-data) and download it.
    This project export contains a backup copy of your repository *and* refs
    we can use to purge files from your repository.
 
@@ -195,8 +195,8 @@ When using repository cleanup, note:
 
 - Project statistics are cached. You may need to wait 5-10 minutes to see a reduction in storage utilization.
 - The cleanup prunes loose objects older than 30 minutes. This means objects added or referenced in the last 30 minutes
-  are not be removed immediately. If you have access to the
-  [Gitaly](../../../administration/gitaly/index.md) server, you may slip that delay and run `git gc --prune=now` to
+  are not removed immediately. If you have access to the
+  [Gitaly](../../../administration/gitaly/index.md) server, you may skip that delay and run `git gc --prune=now` to
   prune all loose objects immediately.
 - This process removes some copies of the rewritten commits from the GitLab cache and database,
   but there are still numerous gaps in coverage and some of the copies may persist indefinitely.
@@ -207,7 +207,7 @@ When using repository cleanup, note:
 
 Repository size limits:
 
-- Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md#account-and-limit-settings)
+- Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md#account-and-limit-settings).
 - Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md) on self-managed instances.
 - Are [set for GitLab.com](../../gitlab_com/index.md#account-and-limit-settings).
 
diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md
index 17e55b7aac2..f32035102bb 100644
--- a/doc/user/project/service_desk.md
+++ b/doc/user/project/service_desk.md
@@ -307,8 +307,7 @@ In these issues, you can also see our friendly neighborhood [Support Bot](#suppo
 
 ### As an end user (issue creator)
 
-> Support for additional email headers [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346600) in GitLab 14.6.
-> In earlier versions, the Service Desk email address had to be in the "To" field.
+> Support for additional email headers [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346600) in GitLab 14.6. In earlier versions, the Service Desk email address had to be in the "To" field.
 
 To create a Service Desk issue, an end user does not need to know anything about
 the GitLab instance. They just send an email to the address they are given, and
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 7d1bfcaab59..b973a0f56d1 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -253,7 +253,7 @@ Use the toggles to enable or disable features in the project.
 | **Security & Compliance**        | ✓                         | Control access to [security features](../../application_security/index.md). |
 | **Wiki**                         | ✓                         | Enables a separate system for [documentation](../wiki/). |
 | **Snippets**                     | ✓                         | Enables [sharing of code and text](../../snippets.md). |
-| **Pages**                        | ✓                         | Allows you to [publish static websites](../pages/). |
+| **Pages**                        | ✓                         | Allows you to [publish static websites](../pages/index.md). |
 | **Operations**                   | ✓                         | Control access to Operations-related features, including [Operations Dashboard](../../../operations/index.md), [Environments and Deployments](../../../ci/environments/index.md), [Feature Flags](../../../operations/feature_flags.md). |
 | **Metrics Dashboard**            | ✓                         | Control access to [metrics dashboard](../integrations/prometheus.md). |
 
@@ -392,7 +392,7 @@ When you transfer a project to another namespace, you move the project to a diff
 
 Prerequisites:
 
-- You must have at least the Maintainer role for the [group](../../group/index.md#create-a-group) to which you are transferring.
+- You must have at least the Maintainer role for the [group](../../group/manage.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).
@@ -447,15 +447,16 @@ in GitLab 12.6, and then to [immediate deletion](https://gitlab.com/gitlab-org/g
 
 ### Delayed project deletion **(PREMIUM)**
 
-> [Enabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89466) in GitLab 15.1.
+> - [Enabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89466) in GitLab 15.1.
+> - [Disabled for projects in personal namespaces](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95495) in GitLab 15.3.
 
-Projects can be deleted after a delay period. Multiple settings can affect whether
+Projects in a group (not a personal namespace) 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#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
+- Group [settings](../../group/manage.md#enable-delayed-project-deletion) to enabled delayed project deletion for all
   projects in the group.
 
 ### Delete a project immediately
diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md
index facaba45aec..5a4e300a210 100644
--- a/doc/user/project/web_ide/index.md
+++ b/doc/user/project/web_ide/index.md
@@ -16,15 +16,18 @@ Use the <kbd>.</kbd> [keyboard shortcut](../../shortcuts.md) to open the Web IDE
 You can also open the Web IDE when viewing a file, from the repository file list,
 and from merge requests:
 
-- *When viewing a file, or the repository file list* -
+### When viewing a file or the repository file list
+
   1. In the upper right corner of the page, select **Open in Web IDE** if it is visible.
   1. If **Open in Web IDE** is not visible:
      1. Select the (**{chevron-lg-down}**) next to **Edit** or **Gitpod**, depending on your configuration.
      1. Select **Open in Web IDE** from the list to display it as the editing option.
      1. Select **Open in Web IDE** to open the editor.
-- *When viewing a merge request* -
+
+### When viewing a merge request
+
   1. Go to your merge request.
-  1. In the upper right corner, select **Code**, then select **Open in Gitpod**.
+  1. In the upper right corner, select **Code > Open in Web IDE**.
 
 ## File finder
 
@@ -86,7 +89,7 @@ You can pick a theme from your [profile preferences](../../profile/preferences.m
 
 ## Highlight lines
 
-WebIDE is built with the [Web Editor](../repository/web_editor.md). This enables WebIDE to share the
+The Web IDE is built with the [Web Editor](../repository/web_editor.md). This enables the Web IDE to share the
 same core features for highlighting and linking to particular lines in the edited files
 [described for the Web Editor](../repository/web_editor.md#highlight-lines).
 
diff --git a/doc/user/project/wiki/group.md b/doc/user/project/wiki/group.md
index dc448fed970..a3ba5789d39 100644
--- a/doc/user/project/wiki/group.md
+++ b/doc/user/project/wiki/group.md
@@ -15,7 +15,7 @@ Group wikis are similar to [project wikis](index.md), with a few limitations:
 
 - [Git LFS](../../../topics/git/lfs/index.md) is not supported.
 - Group wikis are not included in [global search](../../search/advanced_search.md).
-- Changes to group wikis don't show up in the [group's activity feed](../../group/index.md#group-activity-analytics).
+- Changes to group wikis don't show up in the [group's activity feed](../../group/manage.md#group-activity-analytics).
 - Group wikis are enabled by default for GitLab Premium and higher tiers.
   You [can't turn them off from the GitLab user interface](https://gitlab.com/gitlab-org/gitlab/-/issues/208413).
 
diff --git a/doc/user/project/wiki/index.md b/doc/user/project/wiki/index.md
index 6e320923496..c7f675417bb 100644
--- a/doc/user/project/wiki/index.md
+++ b/doc/user/project/wiki/index.md
@@ -6,6 +6,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Wiki **(FREE)**
 
+> - Page loading [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/336792) to asynchronous in GitLab 14.9.
+> - Page slug encoding method [changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71753) to `ERB::Util.url_encode` in GitLab 14.9.
+
 If you don't want to keep your documentation in your repository, but you want
 to keep it in the same project as your code, you can use the wiki GitLab provides
 in each GitLab project. Every wiki is a separate Git repository, so you can create
@@ -230,7 +233,7 @@ GitLab tracks wiki creation, deletion, and update events. These events are displ
 
 - [User profile](../../profile/index.md#access-your-user-profile).
 - Activity pages, depending on the type of wiki:
-  - [Group activity](../../group/index.md#view-group-activity).
+  - [Group activity](../../group/manage.md#view-group-activity).
   - [Project activity](../working_with_projects.md#view-project-activity).
 
 Commits to wikis are not counted in [repository analytics](../../analytics/repository_analytics.md).
@@ -337,7 +340,7 @@ Support includes:
 - 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).
+- 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
 
@@ -370,3 +373,35 @@ For the status of the ongoing development for CommonMark and GitLab Flavored Mar
 - [Group repository storage moves API](../../../api/group_repository_storage_moves.md)
 - [Group wikis API](../../../api/group_wikis.md)
 - [Wiki keyboard shortcuts](../../shortcuts.md#wiki-pages)
+
+## Troubleshooting
+
+### Page slug rendering with Apache reverse proxy
+
+In GitLab 14.9 and later, page slugs are now encoded using the
+[`ERB::Util.url_encode`](https://www.rubydoc.info/stdlib/erb/ERB%2FUtil.url_encode) method.
+If you use an Apache reverse proxy, you can add a `nocanon` argument to the `ProxyPass`
+line of your Apache configuration to ensure your page slugs render correctly.
+
+### Recreate a project wiki with the Rails console **(FREE SELF)**
+
+WARNING:
+This operation deletes all data in the wiki.
+
+To clear all data from a project wiki and recreate it in a blank state:
+
+1. [Start a Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+1. Run these commands:
+
+   ```ruby
+   # Enter your project's path
+   p = Project.find_by_full_path('<username-or-group>/<project-name>')
+
+   # This command deletes the wiki project from the filesystem.
+   GitlabShellWorker.perform_in(0, :remove_repository, p.repository_storage, p.wiki.disk_path)
+
+   # Refresh the wiki repository state.
+   p.wiki.repository.expire_exists_cache
+   ```
+
+All data from the wiki has been cleared, and the wiki is ready for use.
diff --git a/doc/user/project/working_with_projects.md b/doc/user/project/working_with_projects.md
index 9572bc241fc..2501fa8b45c 100644
--- a/doc/user/project/working_with_projects.md
+++ b/doc/user/project/working_with_projects.md
@@ -233,7 +233,7 @@ To push your repository and create a project:
       ```
 
    - For `gitlab.example.com`, use the domain name of the machine that hosts your Git repository.
-   - For `namespace`, use the name of your [namespace](../group/index.md#namespaces).
+   - For `namespace`, use the name of your [namespace](../namespace/index.md).
    - For `myproject`, use the name of your project.
    - Optional. To export existing repository tags, append the `--tags` flag to your `git push` command.
 1. Optional. To configure the remote:
@@ -290,7 +290,7 @@ To view your personal projects:
 ## Delete a project
 
 After you delete a project, projects in personal namespaces are deleted immediately. To delay deletion of projects in a group
-you can [enable delayed project removal](../group/index.md#enable-delayed-project-deletion).
+you can [enable delayed project removal](../group/manage.md#enable-delayed-project-deletion).
 
 To delete a project:
 
@@ -310,7 +310,7 @@ To delete a project:
 > - [Available to all users](https://gitlab.com/gitlab-org/gitlab/-/issues/346976) in GitLab 14.8 [with a flag](../../administration/feature_flags.md) named `project_owners_list_project_pending_deletion`. Enabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/351556) in GitLab 14.9. [Feature flag `project_owners_list_project_pending_deletion`](https://gitlab.com/gitlab-org/gitlab/-/issues/351556) removed.
 
-When delayed project deletion is [enabled for a group](../group/index.md#enable-delayed-project-deletion),
+When delayed project deletion is [enabled for a group](../group/manage.md#enable-delayed-project-deletion),
 projects within that group are not deleted immediately, but only after a delay.
 
 To view a list of all projects that are pending deletion:
@@ -371,7 +371,7 @@ To leave a project:
 1. Select a project.
 1. Select **Leave project**. The **Leave project** option only displays
 on the project dashboard when a project is part of a group under a
-[group namespace](../group/index.md#namespaces).
+[group namespace](../namespace/index.md).
 
 ## Use a project as a Go package