Add latest changes from gitlab-org/gitlab@master

30 files changed, 242 insertions, 207 deletions

diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md
index 6547cb53b7c..55b033dd3e1 100644
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -174,7 +174,7 @@ In a multi-server setup you must use one of the options to
 [eliminate local disk usage for job logs](job_logs.md#prevent-local-disk-usage), or job logs could be lost.
 
 In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 
 ### Migrating to object storage
 
@@ -781,7 +781,7 @@ In both cases, you might need to add `region` to the job artifact [object storag
 
 ### Job artifact upload fails with `500 Internal Server Error (Missing file)`
 
-Bucket names that include folder paths are not supported with [consolidated object storage](object_storage.md#consolidated-object-storage-configuration).
+Bucket names that include folder paths are not supported with [consolidated object storage](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 For example, `bucket/path`. If a bucket name has a path in it, you might receive an error similar to:
 
 ```plaintext
diff --git a/doc/administration/lfs/index.md b/doc/administration/lfs/index.md
index 3a4a7cad3b2..ee5cd04f3d6 100644
--- a/doc/administration/lfs/index.md
+++ b/doc/administration/lfs/index.md
@@ -156,14 +156,14 @@ You can store LFS objects in remote object storage. This allows you
 to reduce reads and writes to the local disk, and free up disk space significantly.
 
 In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 
 ### Migrating to object storage
 
 You can migrate the LFS objects from local storage to object storage. The
 processing is done in the background and requires **no downtime**.
 
-1. [Configure the object storage](../object_storage.md#consolidated-object-storage-configuration).
+1. [Configure the object storage](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 1. Migrate the LFS objects:
 
    ::Tabs
diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md
index 85677512860..3fbcdafd886 100644
--- a/doc/administration/merge_request_diffs.md
+++ b/doc/administration/merge_request_diffs.md
@@ -105,7 +105,7 @@ be configured already.
 ### Object Storage Settings
 
 In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
 For source installations, these settings are nested under `external_diffs:` and
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 6f50f085927..848ee8de951 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -13,10 +13,10 @@ typically much more performant, reliable, and scalable.
 
 To configure the object storage, you have two options:
 
-- Recommended. [Consolidated configuration](#consolidated-object-storage-configuration):
-  A single credential is shared by all supported object types.
-- [Storage-specific configuration](#storage-specific-configuration): Every
-  object defines its own object storage connection and configuration.
+- Recommended. [Configure a single storage connection for all object types](#configure-a-single-storage-connection-for-all-object-types-consolidated-form):
+  A single credential is shared by all supported object types. This is called the consolidated form.
+- [Configure each object type to define its own storage connection](#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form):
+  Every object defines its own object storage connection and configuration. This is called the storage-specific form.
 
   If you already use the storage-specific form, see how to
   [transition to the consolidated form](#transition-to-consolidated-form).
@@ -43,34 +43,37 @@ Specifically, GitLab has been tested by vendors and customers on a number of obj
 - [MinIO](https://min.io/) (S3 compatible)
 - On-premises hardware and appliances from various storage vendors, whose list is not officially established.
 
-## Consolidated object storage configuration
+## Configure a single storage connection for all object types (consolidated form)
 
 > [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4368) in GitLab 13.2.
 
-Using the consolidated object storage configuration has a number of advantages:
+Most types of objects, such as CI artifacts, LFS files, and upload attachments
+can be saved in object storage by specifying a single credential for object
+storage with multiple buckets.
+
+Configuring the object storage using the consolidated form has a number of advantages:
 
 - It can simplify your GitLab configuration since the connection details are shared
   across object types.
 - It enables the use of [encrypted S3 buckets](#encrypted-s3-buckets).
 - It [uploads files to S3 with proper `Content-MD5` headers](https://gitlab.com/gitlab-org/gitlab-workhorse/-/issues/222).
 
-Because [direct upload mode](../development/uploads/index.md#direct-upload)
-must be enabled, only the following providers can be used:
+When the consolidated form is used,
+[direct upload](../development/uploads/index.md#direct-upload) is enabled
+automatically. Thus, only the following providers can be used:
 
 - [Amazon S3-compatible providers](#amazon-s3)
 - [Google Cloud Storage](#google-cloud-storage-gcs)
 - [Azure Blob storage](#azure-blob-storage)
 
-When consolidated object storage is used, direct upload is enabled
-automatically. For storage-specific
-configuration, [direct upload may become the default](https://gitlab.com/gitlab-org/gitlab/-/issues/27331)
-because it does not require a shared folder.
-
-Consolidated object storage configuration can't be used for backups or
-Mattermost. See the [full table for a complete list](#storage-specific-configuration).
-However, backups can be configured with [server side encryption](../raketasks/backup_gitlab.md#s3-encrypted-buckets) separately.
+The consolidated form configuration can't be used for backups or
+Mattermost. Backups can be configured with
+[server side encryption](../raketasks/backup_gitlab.md#s3-encrypted-buckets)
+separately. See the
+[table for a complete list](#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
+of supported object storage types.
 
-Enabling consolidated object storage enables object storage for all object
+Enabling the consolidated form enables object storage for all object
 types. If not all buckets are specified, you may see an error like:
 
 ```plaintext
@@ -80,24 +83,21 @@ Object storage for <object type> must have a bucket specified
 If you want to use local storage for specific object types, you can
 [disable object storage for specific features](#disable-object-storage-for-specific-features).
 
-Most types of objects, such as CI artifacts, LFS files, and upload
-attachments can be saved in object storage by specifying a single
-credential for object storage with multiple buckets.
+### Configure the common parameters
 
-When the consolidated form is:
+In the consolidated form, the `object_store` section defines a
+common set of parameters.
 
-- Used with an S3-compatible object storage, Workhorse uses its internal S3 client to
-  upload files.
-- Not used with an S3-compatible object storage, Workhorse falls back to using
-  pre-signed URLs.
-
-See the section on [ETag mismatch errors](#etag-mismatch) for more details.
-
-### Common parameters
+| Setting           | Description                       |
+|-------------------|-----------------------------------|
+| `enabled`         | Enable or disable object storage. |
+| `proxy_download`  | Set to `true` to [enable proxying all files served](#proxy-download). Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data. |
+| `connection`      | Various [connection options](#connection-settings) described below. |
+| `storage_options` | Options to use when saving new objects, such as [server side encryption](#server-side-encryption-headers). Introduced in GitLab 13.3. |
+| `objects`         | [Object-specific configuration](#configure-the-parameters-of-each-object). |
 
-In the consolidated configuration, the `object_store` section defines a
-common set of parameters. Here we use the YAML from the source
-installation because it's easier to see the inheritance:
+The following YAML is from the source
+installation, to help you see the inheritance:
 
 ```yaml
     object_store:
@@ -123,15 +123,30 @@ gitlab_rails['object_store']['connection'] = {
 }
 ```
 
-| Setting           | Description                       |
-|-------------------|-----------------------------------|
-| `enabled`         | Enable or disable object storage. |
-| `proxy_download`  | Set to `true` to [enable proxying all files served](#proxy-download). Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data. |
-| `connection`      | Various [connection options](#connection-settings) described below. |
-| `storage_options` | Options to use when saving new objects, such as [server side encryption](#server-side-encryption-headers). Introduced in GitLab 13.3. |
-| `objects`         | [Object-specific configuration](#object-specific-configuration). |
+### Configure the parameters of each object
+
+Each object type must at least define the bucket name where it will be stored.
+
+The following table lists the valid `objects` that can be used:
+
+|  Type              | Description                                                                |
+|--------------------|----------------------------------------------------------------------------|
+| `artifacts`        | [CI artifacts](job_artifacts.md)                                           |
+| `external_diffs`   | [Merge request diffs](merge_request_diffs.md)                              |
+| `uploads`          | [User uploads](uploads.md)                                                 |
+| `lfs`              | [Git Large File Storage objects](lfs/index.md)                             |
+| `packages`         | [Project packages (for example, PyPI, Maven, or NuGet)](packages/index.md) |
+| `dependency_proxy` | [Dependency Proxy](packages/dependency_proxy.md)                    |
+| `terraform_state`  | [Terraform state files](terraform_state.md)                                |
+| `pages`            | [Pages](pages/index.md)                                             |
+
+Within each object type, three parameters can be defined:
 
-### Object-specific configuration
+| Setting          | Required?              | Description                         |
+|------------------|------------------------|-------------------------------------|
+| `bucket`         | **{check-circle}** Yes\* | Bucket name for the object type. Not required if `enabled` is set to `false`. |
+| `enabled`        | **{dotted-circle}** No | Overrides the [common parameter](#configure-the-common-parameters).     |
+| `proxy_download` | **{dotted-circle}** No | Overrides the [common parameter](#configure-the-common-parameters).     |
 
 The following YAML shows how the `object_store` section defines
 object-specific configuration block and how the `enabled` and
@@ -178,27 +193,6 @@ gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = 'terrafor
 gitlab_rails['object_store']['objects']['pages']['bucket'] = 'pages'
 ```
 
-This is the list of valid `objects` that can be used:
-
-|  Type              | Description                                                                |
-|--------------------|----------------------------------------------------------------------------|
-| `artifacts`        | [CI artifacts](job_artifacts.md)                                           |
-| `external_diffs`   | [Merge request diffs](merge_request_diffs.md)                              |
-| `uploads`          | [User uploads](uploads.md)                                                 |
-| `lfs`              | [Git Large File Storage objects](lfs/index.md)                             |
-| `packages`         | [Project packages (for example, PyPI, Maven, or NuGet)](packages/index.md) |
-| `dependency_proxy` | [Dependency Proxy](packages/dependency_proxy.md)                    |
-| `terraform_state`  | [Terraform state files](terraform_state.md)                                |
-| `pages`            | [Pages](pages/index.md)                                             |
-
-Within each object type, three parameters can be defined:
-
-| Setting          | Required?              | Description                         |
-|------------------|------------------------|-------------------------------------|
-| `bucket`         | **{check-circle}** Yes | Bucket name for the object storage. |
-| `enabled`        | **{dotted-circle}** No | Overrides the common parameter.     |
-| `proxy_download` | **{dotted-circle}** No | Overrides the common parameter.     |
-
 #### Disable object storage for specific features
 
 As seen above, object storage can be disabled for specific types by
@@ -216,33 +210,41 @@ no bucket is needed if CI artifacts are disabled with this setting:
 gitlab_rails['artifacts_enabled'] = false
 ```
 
-## Storage-specific configuration
+## Configure each object type to define its own storage connection (storage-specific form)
+
+With the storage-specific form, every object defines its own object
+storage connection and configuration. If you're using GitLab 13.2 and later,
+you should [transition to the consolidated form](#transition-to-consolidated-form).
+
+The use of [encrypted S3 buckets](#encrypted-s3-buckets) with non-consolidated form is not supported.
+You may get [ETag mismatch errors](#etag-mismatch) if you use it.
+
+NOTE:
+For the storage-specific form,
+[direct upload may become the default](https://gitlab.com/gitlab-org/gitlab/-/issues/27331)
+because it does not require a shared folder.
 
 For configuring object storage in GitLab 13.1 and earlier, or for storage types not
-supported by consolidated configuration form, refer to the following guides:
+supported by consolidated form, refer to the following guides:
 
-| Object storage type | Supported by consolidated configuration? |
+| Object storage type | Supported by consolidated form? |
 |---------------------|------------------------------------------|
 | [Backups](../raketasks/backup_gitlab.md#upload-backups-to-a-remote-cloud-storage) | **{dotted-circle}** No |
+| [Container Registry](packages/container_registry.md#use-object-storage) (optional feature) | **{dotted-circle}** No |
+| [Mattermost](https://docs.mattermost.com/configure/file-storage-configuration-settings.html)| **{dotted-circle}** No |
+| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | **{dotted-circle}** No |
 | [Job artifacts](job_artifacts.md#using-object-storage) including archived job logs | **{check-circle}** Yes |
 | [LFS objects](lfs/index.md#storing-lfs-objects-in-remote-object-storage) | **{check-circle}** Yes |
 | [Uploads](uploads.md#using-object-storage) | **{check-circle}** Yes |
-| [Container Registry](packages/container_registry.md#use-object-storage) (optional feature) | **{dotted-circle}** No |
 | [Merge request diffs](merge_request_diffs.md#using-object-storage) | **{check-circle}** Yes |
-| [Mattermost](https://docs.mattermost.com/configure/file-storage-configuration-settings.html)| **{dotted-circle}** No |
 | [Packages](packages/index.md#use-object-storage) (optional feature) | **{check-circle}** Yes |
 | [Dependency Proxy](packages/dependency_proxy.md#using-object-storage) (optional feature) | **{check-circle}** Yes |
-| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | **{dotted-circle}** No |
 | [Terraform state files](terraform_state.md#using-object-storage) | **{check-circle}** Yes |
 | [Pages content](pages/index.md#using-object-storage) | **{check-circle}** Yes |
 
-WARNING:
-The use of [encrypted S3 buckets](#encrypted-s3-buckets) with non-consolidated configuration is not supported.
-You may start getting [ETag mismatch errors](#etag-mismatch) if you use it.
-
 ## Connection settings
 
-Both consolidated configuration form and storage-specific configuration form must configure a connection. The following sections describe parameters that can be used
+Both consolidated and storage-specific form must configure a connection. The following sections describe parameters that can be used
 in the `connection` setting.
 
 ### Amazon S3
@@ -348,9 +350,9 @@ Although Azure uses the word `container` to denote a collection of
 blobs, GitLab standardizes on the term `bucket`. Be sure to configure
 Azure container names in the `bucket` settings.
 
-Azure Blob storage can only be used with the [consolidated form](#consolidated-object-storage-configuration)
+Azure Blob storage can only be used with the [consolidated form](#configure-a-single-storage-connection-for-all-object-types-consolidated-form)
 because a single set of credentials are used to access multiple
-containers. The [storage-specific form](#storage-specific-configuration)
+containers. The [storage-specific form](#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 is not supported. For more details, see [how to transition to consolidated form](#transition-to-consolidated-form).
 
 The following are the valid connection parameters for Azure. For more information, see the
@@ -419,7 +421,7 @@ gitlab_rails['object_store']['connection'] = {
 The signature version must be `2`. Using v4 results in a HTTP 411 Length Required error.
 For more information, see [issue #4419](https://gitlab.com/gitlab-org/gitlab/-/issues/4419).
 
-## Full example using the consolidated object storage and Amazon S3
+## Full example using the consolidated form and Amazon S3
 
 The following example uses AWS S3 to enable object storage for all supported services:
 
@@ -747,7 +749,7 @@ additional complexity and unnecessary redundancy. Since both GitLab
 Rails and Workhorse components need access to object storage, the
 consolidated form avoids excessive duplication of credentials.
 
-The consolidated object storage configuration is used _only_ if all lines from
+The consolidated form is used _only_ if all lines from
 the original form is omitted. To move to the consolidated form, remove the
 original configuration (for example, `artifacts_object_store_enabled`, or
 `uploads_object_store_connection`)
@@ -769,10 +771,10 @@ address must be added to the `no_proxy` list.
 ### Encrypted S3 buckets
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/466) in GitLab 13.1 for instance profiles only and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34460) in GitLab 13.2 for static credentials when [consolidated object storage configuration](#consolidated-object-storage-configuration) and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) are used.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34460) in GitLab 13.2 for static credentials when the [consolidated form](#configure-a-single-storage-connection-for-all-object-types-consolidated-form) and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) is used.
 
 When configured either with an instance profile or with the consolidated
-object configuration, GitLab Workhorse properly uploads files to S3
+form, GitLab Workhorse properly uploads files to S3
 buckets that have [SSE-S3 or SSE-KMS encryption enabled by default](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html).
 Customer master keys (CMKs) and SSE-C encryption are
 [not supported since this requires sending the encryption keys in every request](https://gitlab.com/gitlab-org/gitlab/-/issues/226006).
@@ -797,7 +799,7 @@ the Workhorse S3 client is enabled. One of the following two conditions
 must be fulfilled:
 
 - `use_iam_profile` is `true` in the connection settings.
-- Consolidated object storage settings are in use.
+- Consolidated form is in use.
 
 [ETag mismatch errors](#etag-mismatch) occur if server side
 encryption headers are used without enabling the Workhorse S3 client.
@@ -990,14 +992,14 @@ If you are seeing this ETag mismatch error with Amazon Web Services S3,
 it's likely this is due to [encryption settings on your bucket](https://docs.aws.amazon.com/AmazonS3/latest/API/RESTCommonResponseHeaders.html).
 To fix this issue, you have two options:
 
-- [Use the consolidated object configuration](#consolidated-object-storage-configuration).
+- [Use the consolidated form](#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 - [Use Amazon instance profiles](#use-amazon-instance-profiles).
 
 The first option is recommended for MinIO. Otherwise, the
 [workaround for MinIO](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1564#note_244497658)
 is to use the `--compat` parameter on the server.
 
-Without consolidated object store configuration or instance profiles enabled,
+Without the consolidated form or instance profiles enabled,
 GitLab Workhorse uploads files to S3 using pre-signed URLs that do
 not have a `Content-MD5` HTTP header computed for them. To ensure data
 is not corrupted, Workhorse checks that the MD5 hash of the data sent
@@ -1005,9 +1007,14 @@ equals the ETag header returned from the S3 server. When encryption is
 enabled, this is not the case, which causes Workhorse to report an `ETag
 mismatch` error during an upload.
 
-With the consolidated object configuration and instance profile, Workhorse has
-S3 credentials so that it can compute the `Content-MD5` header. This
-eliminates the need to compare ETag headers returned from the S3 server.
+When the consolidated form is:
+
+- Used with an S3-compatible object storage or an istance profile, Workhorse
+  uses its internal S3 client which has S3 credentials so that it can compute
+  the `Content-MD5` header. This eliminates the need to compare ETag headers
+  returned from the S3 server.
+- Not used with an S3-compatible object storage, Workhorse falls back to using
+  pre-signed URLs.
 
 Encrypting buckets with the GCS [Cloud Key Management Service (KMS)](https://cloud.google.com/kms/docs) is not supported and results in ETag mismatch errors.
 
diff --git a/doc/administration/packages/dependency_proxy.md b/doc/administration/packages/dependency_proxy.md
index 78efd75bbe3..a29d6d93051 100644
--- a/doc/administration/packages/dependency_proxy.md
+++ b/doc/administration/packages/dependency_proxy.md
@@ -122,7 +122,7 @@ To change the local storage path:
 
 Instead of relying on the local storage, you can use an object storage to
 store the blobs of the Dependency Proxy. In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format. [Migration steps still apply](#migrate-local-dependency-proxy-blobs-and-manifests-to-object-storage).
 
 [Read more about using object storage with GitLab](../object_storage.md).
diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md
index 6e53d77109f..f0f238aa5ba 100644
--- a/doc/administration/packages/index.md
+++ b/doc/administration/packages/index.md
@@ -124,7 +124,7 @@ Instead of relying on the local storage, you can use an object storage to store
 packages.
 
 For more information, see how to use the
-[consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 
 ### Migrate local packages to object storage
 
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 7ce588a6cb0..b4a786c7b33 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -916,7 +916,7 @@ If you want to stop using and disconnect the NFS server, you need to
 #### S3-compatible connection settings
 
 In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
 See [the available connection settings for different providers](../object_storage.md#connection-settings).
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index 09ba9838cf8..e70d012507f 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -2198,15 +2198,15 @@ and scalable.
 
 There are two ways of specifying object storage configuration in GitLab:
 
-- [Consolidated form](../object_storage.md#consolidated-object-storage-configuration): A single credential is
+- [Consolidated form](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form): A single credential is
   shared by all supported object types.
-- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
+- [Storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form): Every object defines its
   own object storage [connection and configuration](../object_storage.md#connection-settings).
 
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index f55740bdf9d..19a79657218 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -2216,15 +2216,15 @@ and scalable.
 
 There are two ways of specifying object storage configuration in GitLab:
 
-- [Consolidated form](../object_storage.md#consolidated-object-storage-configuration): A single credential is
+- [Consolidated form](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form): A single credential is
   shared by all supported object types.
-- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
+- [Storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form): Every object defines its
   own object storage [connection and configuration](../object_storage.md#connection-settings).
 
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 893d9eff21c..f31cf6f4ab6 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -902,15 +902,15 @@ and scalable.
 
 There are two ways of specifying object storage configuration in GitLab:
 
-- [Consolidated form](../object_storage.md#consolidated-object-storage-configuration): A single credential is
+- [Consolidated form](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form): A single credential is
   shared by all supported object types.
-- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
+- [Storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form): Every object defines its
   own object storage [connection and configuration](../object_storage.md#connection-settings).
 
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 47d49ffb437..a01eaee10d3 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -2186,15 +2186,15 @@ and scalable.
 
 There are two ways of specifying object storage configuration in GitLab:
 
-- [Consolidated form](../object_storage.md#consolidated-object-storage-configuration): A single credential is
+- [Consolidated form](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form): A single credential is
   shared by all supported object types.
-- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
+- [Storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form): Every object defines its
   own object storage [connection and configuration](../object_storage.md#connection-settings).
 
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index b89effb730a..d4423ef4f9f 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -2215,15 +2215,15 @@ and scalable.
 
 There are two ways of specifying object storage configuration in GitLab:
 
-- [Consolidated form](../object_storage.md#consolidated-object-storage-configuration): A single credential is
+- [Consolidated form](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form): A single credential is
   shared by all supported object types.
-- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
+- [Storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form): Every object defines its
   own object storage [connection and configuration](../object_storage.md#connection-settings).
 
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 5d6c650fe50..627812f5647 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -2181,15 +2181,15 @@ and scalable.
 
 There are two ways of specifying object storage configuration in GitLab:
 
-- [Consolidated form](../object_storage.md#consolidated-object-storage-configuration): A single credential is
+- [Consolidated form](../object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form): A single credential is
   shared by all supported object types.
-- [Storage-specific form](../object_storage.md#storage-specific-configuration): Every object defines its
+- [Storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form): Every object defines its
   own object storage [connection and configuration](../object_storage.md#connection-settings).
 
 The consolidated form is used in the following examples when available.
 
 NOTE:
-When using the [storage-specific form](../object_storage.md#storage-specific-configuration)
+When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
 in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
 The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
 which was deprecated in 14.9, requires shared storage such as NFS.
diff --git a/doc/administration/terraform_state.md b/doc/administration/terraform_state.md
index 7ab4359638d..9a54eb86eeb 100644
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -175,7 +175,7 @@ sudo find /var/opt/gitlab/gitlab-rails/shared/terraform_state -type f | grep -v
 ### S3-compatible connection settings
 
 In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
 See [the available connection settings for different providers](object_storage.md#connection-settings).
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index c4e2c352e9b..e614f0d38e3 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -65,7 +65,7 @@ This configuration relies on valid AWS credentials to be configured already.
 ### Object Storage Settings
 
 In GitLab 13.2 and later, you should use the
-[consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
+[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
 For source installations the following settings are nested under `uploads:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `uploads_object_store_`.
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 5e81e08a961..b6a8cbae0da 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -24213,6 +24213,15 @@ State of a Geo registry.
 | <a id="registrystatestarted"></a>`STARTED` | Registry currently syncing. |
 | <a id="registrystatesynced"></a>`SYNCED` | Registry that is synced. |
 
+### `RelativePositionType`
+
+The position to which the object should be moved.
+
+| Value | Description |
+| ----- | ----------- |
+| <a id="relativepositiontypeafter"></a>`AFTER` | Object is moved after an adjacent object. |
+| <a id="relativepositiontypebefore"></a>`BEFORE` | Object is moved before an adjacent object. |
+
 ### `ReleaseAssetLinkType`
 
 Type of the link: `other`, `runbook`, `image`, `package`.
@@ -26878,8 +26887,10 @@ A time-frame defined as a closed inclusive range of two dates.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="workitemwidgethierarchyupdateinputadjacentworkitemid"></a>`adjacentWorkItemId` | [`WorkItemID`](#workitemid) | ID of the work item to be switched with. |
 | <a id="workitemwidgethierarchyupdateinputchildrenids"></a>`childrenIds` | [`[WorkItemID!]`](#workitemid) | Global IDs of children work items. |
 | <a id="workitemwidgethierarchyupdateinputparentid"></a>`parentId` | [`WorkItemID`](#workitemid) | Global ID of the parent work item. Use `null` to remove the association. |
+| <a id="workitemwidgethierarchyupdateinputrelativeposition"></a>`relativePosition` | [`RelativePositionType`](#relativepositiontype) | Type of switch. Valid values are `BEFORE` or `AFTER`. |
 
 ### `WorkItemWidgetIterationInput`
 
diff --git a/doc/architecture/blueprints/object_storage/index.md b/doc/architecture/blueprints/object_storage/index.md
index 5d83d5058a0..3f649960554 100644
--- a/doc/architecture/blueprints/object_storage/index.md
+++ b/doc/architecture/blueprints/object_storage/index.md
@@ -126,7 +126,7 @@ infrastructure. It also makes the initial installation more complex
 feature after feature.
 
 Implementing a direct upload by default, with a
-[consolidated object storage configuration](../../../administration/object_storage.md#consolidated-object-storage-configuration)
+[consolidated object storage configuration](../../../administration/object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form)
 will reduce the number of merge requests needed to ship a new feature
 from four to only one. It will also remove the need for SRE
 intervention as the bucket will always be the same.
diff --git a/doc/development/experiment_guide/index.md b/doc/development/experiment_guide/index.md
index fd5b0ea15e6..5e68921510e 100644
--- a/doc/development/experiment_guide/index.md
+++ b/doc/development/experiment_guide/index.md
@@ -29,7 +29,7 @@ the documentation on that project if you want to dig into more advanced topics o
 aware that the documentation there reflects what's in the main branch and may not be the same as
 the version being used in GitLab.
 
-## Glossary of terms
+## Glossary
 
 To ensure a shared language, you should understand these fundamental terms we use
 when communicating about experiments:
diff --git a/doc/integration/jira/configure.md b/doc/integration/jira/configure.md
index 3ef4dfac3f4..c825b584b57 100644
--- a/doc/integration/jira/configure.md
+++ b/doc/integration/jira/configure.md
@@ -72,3 +72,5 @@ To migrate from Jira Server to Jira Cloud in GitLab and maintain your Jira integ
 1. In **Password or API token**, paste the API token value.
 1. Optional. Select **Test settings** to check if the connection is working.
 1. Select **Save changes**.
+
+To update existing Jira issue references in GitLab to use the new Jira site URL, you must [invalidate the Markdown cache](../../administration/invalidate_markdown_cache.md#invalidate-the-cache).
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index 16c69a65a8c..2fdace32553 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -19,7 +19,7 @@ To set up SAML on GitLab.com, see [SAML SSO for GitLab.com groups](../user/group
 For more information on:
 
 - OmniAuth provider settings, see the [OmniAuth documentation](omniauth.md).
-- Commonly-used terms, see the [glossary of common terms](#glossary-of-common-terms).
+- Commonly-used terms, see the [glossary](#glossary).
 
 ## Configure SAML support in GitLab
 
@@ -3125,7 +3125,7 @@ such as the following:
 
 For example configurations, see the [notes on specific providers](#set-up-identity-providers).
 
-## Glossary of common terms
+## Glossary
 
 | Term                           | Description |
 |--------------------------------|-------------|
diff --git a/doc/topics/git/index.md b/doc/topics/git/index.md
index fa802952b32..91c3f1971f1 100644
--- a/doc/topics/git/index.md
+++ b/doc/topics/git/index.md
@@ -30,7 +30,7 @@ The following resources can help you get started with Git:
 - [Git Basics](https://git-scm.com/book/en/v2/Getting-Started-Git-Basics)
 - [Git on the Server - GitLab](https://git-scm.com/book/en/v2/Git-on-the-Server-GitLab)
 - [How to install Git](how_to_install_git/index.md)
-- [Git terminology](terminology.md)
+- [Git concepts](terminology.md)
 - [Start using Git on the command line](../../gitlab-basics/start-using-git.md)
 - [GitLab Git Cheat Sheet (download)](https://about.gitlab.com/images/press/git-cheat-sheet.pdf)
 - Commits:
diff --git a/doc/topics/git/terminology.md b/doc/topics/git/terminology.md
index ac097396bef..8b1db5b4416 100644
--- a/doc/topics/git/terminology.md
+++ b/doc/topics/git/terminology.md
@@ -4,9 +4,9 @@ group: Source Code
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Git terminology
+# Git concepts
 
-The following are commonly-used Git terms.
+The following are commonly-used Git concepts.
 
 ## Repository
 
diff --git a/doc/update/removals.md b/doc/update/removals.md
index 6874ab9fe2e..843604b8a18 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -247,7 +247,7 @@ If your object storage provider does not support `background_upload`, please [mi
 
 #### Encrypted S3 buckets
 
-Additionally, this also breaks the use of [encrypted S3 buckets](https://docs.gitlab.com/ee/administration/object_storage.html#encrypted-s3-buckets) with [storage-specific configuration form](https://docs.gitlab.com/ee/administration/object_storage.html#storage-specific-configuration).
+Additionally, this also breaks the use of [encrypted S3 buckets](https://docs.gitlab.com/ee/administration/object_storage.html#encrypted-s3-buckets) with [storage-specific configuration form](https://docs.gitlab.com/ee/administration/object_storage.html#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form).
 
 If your S3 buckets have [SSE-S3 or SSE-KMS encryption enabled](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html), please [migrate your configuration to use consolidated object storage form](https://docs.gitlab.com/ee/administration/object_storage.html#transition-to-consolidated-form) before upgrading to GitLab 15.0. Otherwise, you may start getting `ETag mismatch` errors during objects upload.
 
@@ -265,7 +265,7 @@ Some users found that they could specify a path prefix to the bucket. In direct
 
 If you have set a prefix, you can use a workaround to revert to background uploads:
 
-1. Continue to use [storage-specific configuration](https://docs.gitlab.com/ee/administration/object_storage.html#storage-specific-configuration).
+1. Continue to use [storage-specific configuration](https://docs.gitlab.com/ee/administration/object_storage.html#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form).
 1. In Omnibus GitLab, set the `GITLAB_LEGACY_BACKGROUND_UPLOADS` to re-enable background uploads:
 
     ```ruby
diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md
index 774063810f3..44af9dc9dea 100644
--- a/doc/user/analytics/index.md
+++ b/doc/user/analytics/index.md
@@ -59,7 +59,7 @@ You can use the following analytics features to analyze and visualize the perfor
 - [Value stream analytics for groups](../group/value_stream_analytics/index.md)
 - [Value streams dashboard](value_streams_dashboard.md)
 
-## Definitions
+## Glossary
 
 We use the following terms to describe GitLab analytics:
 
diff --git a/doc/user/application_security/terminology/index.md b/doc/user/application_security/terminology/index.md
index 772a7d17e1e..df103976901 100644
--- a/doc/user/application_security/terminology/index.md
+++ b/doc/user/application_security/terminology/index.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Secure and Govern terminology **(FREE)**
+# Secure and Govern glossary **(FREE)**
 
 The glossary of terms aims to achieve the following:
 
@@ -17,9 +17,7 @@ The glossary of terms aims to achieve the following:
 The definitions of the terms outlined in this document are in the context of the GitLab
 products. Therefore, a term may have a different meaning to users outside of GitLab.
 
-## Terms
-
-### Analyzer
+## Analyzer
 
 Software that performs a scan. The scan analyzes an attack surface for vulnerabilities and produces
 a report containing findings. Reports adhere to the [Secure report format](#secure-report-format).
@@ -31,35 +29,35 @@ manage found vulnerabilities. For more information, see [Security Scanner Integr
 Many GitLab analyzers follow a standard approach using Docker to run a wrapped scanner. For example,
 the image `semgrep` is an analyzer that wraps the scanner `Semgrep`.
 
-### Attack surface
+## Attack surface
 
 The different places in an application that are vulnerable to attack. Secure products discover and
 search the attack surface during scans. Each product defines the attack surface differently. For
 example, SAST uses files and line numbers, and DAST uses URLs.
 
-### Corpus
+## Corpus
 
 The set of meaningful test cases that are generated while the fuzzer is running. Each meaningful
 test case produces new coverage in the tested program. It's advised to re-use the corpus and pass it
 to subsequent runs.
 
-### CNA
+## CNA
 
 [CVE](#cve) Numbering Authorities (CNAs) are organizations from around the world that are authorized by
 the [Mitre Corporation](https://cve.mitre.org/) to assign [CVE](#cve)s to vulnerabilities in products or
 services within their respective scope. [GitLab is a CNA](https://about.gitlab.com/security/cve/).
 
-### CVE
+## CVE
 
 Common Vulnerabilities and Exposures (CVE®) is a list of common identifiers for publicly known
 cybersecurity vulnerabilities. The list is managed by the [Mitre Corporation](https://cve.mitre.org/).
 
-### CVSS
+## CVSS
 
 The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing
 the severity of computer system security vulnerabilities.
 
-### CWE
+## CWE
 
 Common Weakness Enumeration (CWE™) is a community-developed list of common software and hardware
 weakness types that have security ramifications. Weaknesses are flaws, faults, bugs,
@@ -68,22 +66,22 @@ architecture. If left unaddressed, weaknesses could result in systems, networks,
 vulnerable to attack. The CWE List and associated classification taxonomy serve as a language that
 you can use to identify and describe these weaknesses in terms of CWEs.
 
-### Deduplication
+## Deduplication
 
 When a category's process deems findings to be the same, or if they are similar enough that a noise reduction is
 required, only one finding is kept and the others are eliminated. Read more about the [deduplication process](../vulnerability_report/pipeline.md#deduplication-process).
 
-### Duplicate finding
+## Duplicate finding
 
 A legitimate finding that is reported multiple times. This can occur when different scanners
 discover the same finding, or when a single scan inadvertently reports the same finding more than
 once.
 
-### False positive
+## False positive
 
 A finding that doesn't exist but is incorrectly reported as existing.
 
-### Finding
+## Finding
 
 An asset that has the potential to be vulnerable, identified in a project by an analyzer. Assets
 include but are not restricted to source code, binary packages, containers, dependencies, networks,
@@ -96,32 +94,32 @@ You can interact with vulnerability findings in two ways.
 1. You can open an issue or merge request for the vulnerability finding.
 1. You can dismiss the vulnerability finding. Dismissing the finding hides it from the default views.
 
-### Grouping
+## Grouping
 
 A flexible and non-destructive way to visually organize vulnerabilities in groups when there are multiple findings
 that are likely related but do not qualify for deduplication. For example, you can include findings that should be
 evaluated together, would be fixed by the same action, or come from the same source. Grouping behavior for vulnerabilities is
 under development and tracked in issue [267588](https://gitlab.com/gitlab-org/gitlab/-/issues/267588).
 
-### Insignificant finding
+## Insignificant finding
 
 A legitimate finding that a particular customer doesn't care about.
 
-### Location fingerprint
+## Location fingerprint
 
 A finding's location fingerprint is a text value that's unique for each location on the attack
 surface. Each security product defines this according to its type of attack surface. For example, SAST
 incorporates file path and line number.
 
-### Package managers and package types
+## Package managers and package types
 
-#### Package managers
+### Package managers
 
 A package manager is a system that manages your project dependencies.
 
 The package manager provides a method to install new dependencies (also referred to as "packages"), manage where packages are stored on your file system, and offer capabilities for you to publish your own packages.
 
-#### Package types
+### Package types
 
 Each package manager, platform, type, or ecosystem has its own conventions and protocols to identify, locate, and provision software packages.
 
@@ -215,11 +213,11 @@ table.package-managers-and-types ul {
   </tbody>
 </table>
 
-### Pipeline Security tab
+## Pipeline Security tab
 
 A page that displays findings discovered in the associated CI pipeline.
 
-### Post-filter
+## Post-filter
 
 Post-filters help reduce noise in the scanner results and automate manual tasks. You can specify criteria that updates
 or modifies vulnerability data based on scanner results. For example, you can flag findings as likely False Positives
@@ -228,7 +226,7 @@ and automatically resolve vulnerabilities that are no longer detected. These are
 Support for automatically resolving findings is tracked in epic [7478](https://gitlab.com/groups/gitlab-org/-/epics/7478) and
 support for cheap scan is proposed in issue [349926](https://gitlab.com/gitlab-org/gitlab/-/issues/349926).
 
-### Pre-filter
+## Pre-filter
 
 An irreversible action that is done to filter out targets before analysis occurs. This is usually provided to allow
 the user to reduce scope and noise as well as speed up the analysis. This should not be done if a record is needed as
@@ -236,7 +234,7 @@ we currently do not store anything related to the skipped/excluded code or asset
 
 Examples: `DS_EXCLUDED_PATHS` should `Exclude files and directories from the scan based on the paths provided.`
 
-### Primary identifier
+## Primary identifier
 
 A finding's primary identifier is a value that is unique to each finding. The external type and external ID
 of the finding's [first identifier](https://gitlab.com/gitlab-org/security-products/security-report-schemas/-/blob/v2.4.0-rc1/dist/sast-report-format.json#L228)
@@ -246,13 +244,13 @@ Examples of primary identifiers include `PluginID` for OWASP Zed Attack Proxy (Z
 Trivy. The identifier must be stable. Subsequent scans must return the same value for the
 same finding, even if the location has slightly changed.
 
-### Report finding
+## Report finding
 
 A [finding](#finding) that only exists in a report produced by an analyzer, and is yet to be
 persisted to the database. The report finding becomes a [vulnerability finding](#vulnerability-finding)
 once it's imported into the database.
 
-### Scan type (report type)
+## Scan type (report type)
 
 Describes the type of scan. This must be one of the following:
 
@@ -266,12 +264,12 @@ Describes the type of scan. This must be one of the following:
 
 This list is subject to change as scanners are added.
 
-### Scanner
+## Scanner
 
 Software that can scan for vulnerabilities. The resulting scan report is typically not in the
 [Secure report format](#secure-report-format). Examples include ESLint, Trivy, and ZAP.
 
-### Secure product
+## Secure product
 
 A group of features related to a specific area of application security with first-class support by
 GitLab.
@@ -281,23 +279,23 @@ Testing (DAST), Secret Detection, Static Application Security Testing (SAST), an
 
 Each of these products typically include one or more analyzers.
 
-### Secure report format
+## Secure report format
 
 A standard report format that Secure products comply with when creating JSON reports. The format is described by a
 [JSON schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas).
 
-### Security Dashboard
+## Security Dashboard
 
 Provides an overview of all the vulnerabilities for a project, group, or GitLab instance.
 Vulnerabilities are only created from findings discovered on the project's default branch.
 
-### Seed corpus
+## Seed corpus
 
 The set of test cases given as initial input to the fuzz target. This usually speeds up the fuzz
 target substantially. This can be either manually created test cases or auto-generated with the fuzz
 target itself from previous runs.
 
-### Vendor
+## Vendor
 
 The party maintaining an analyzer. As such, a vendor is responsible for integrating a scanner into
 GitLab and keeping it compatible as they evolve. A vendor isn't necessarily the author or maintainer
@@ -305,7 +303,7 @@ of the scanner, as in the case of using an open core or OSS project as a base so
 offering. For scanners included as part of a GitLab distribution or GitLab subscription, the vendor
 is listed as GitLab.
 
-### Vulnerability
+## Vulnerability
 
 A flaw that has a negative impact on the security of its environment. Vulnerabilities describe the
 error or weakness, and don't describe where the error is located (see [finding](#finding)).
@@ -314,12 +312,12 @@ Each vulnerability maps to a unique finding.
 
 Vulnerabilities exist in the default branch. Findings (see [finding](#finding)) are all potential vulnerability items scanners identify in MRs/feature branches. Only after merging to default does a finding become a vulnerability.
 
-### Vulnerability finding
+## Vulnerability finding
 
 When a [report finding](#report-finding) is stored to the database, it becomes a vulnerability
 [finding](#finding).
 
-### Vulnerability tracking
+## Vulnerability tracking
 
 Deals with the responsibility of matching findings across scans so that a finding's life cycle can
 be understood. Engineers and security teams use this information to decide whether to merge code
@@ -327,6 +325,6 @@ changes, and to see unresolved findings and when they were introduced.
 
 Vulnerabilities are tracked by comparing the location fingerprint, primary identifier, and report type.
 
-### Vulnerability occurrence
+## Vulnerability occurrence
 
 Deprecated, see [finding](#finding).
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index fe7fff648d8..b36d92f1682 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -189,7 +189,7 @@ the default value [is the same as for self-managed instances](../admin_area/sett
 | Setting                       | GitLab.com default |
 |-------------------------------|--------------------|
 | [Repository size including LFS](../admin_area/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB |
-| [Maximum import size](../project/settings/import_export.md#maximum-import-file-size)                        | 5 GB  |
+| [Maximum import size](../project/settings/import_export.md#import-a-project-and-its-data)                   | 5 GB  |
 | Maximum attachment size       | 100 MB              |
 
 If you are near or over the repository size limit, you can either
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index d1f8722b9dc..a76eca4ffac 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -515,7 +515,7 @@ immediately. If the user:
 ## Related topics
 
 - [SAML SSO for self-managed GitLab instances](../../../integration/saml.md)
-- [Glossary of common terms](../../../integration/saml.md#glossary-of-common-terms)
+- [Glossary](../../../integration/saml.md#glossary)
 - [Authentication comparison between SaaS and self-managed](../../../administration/auth/index.md#saas-vs-self-managed-comparison)
 - [Passwords for users created through integrated authentication](../../../security/passwords_for_integrated_authentication_methods.md)
 
diff --git a/doc/user/packages/maven_repository/index.md b/doc/user/packages/maven_repository/index.md
index 29de1940b63..7a451ca283f 100644
--- a/doc/user/packages/maven_repository/index.md
+++ b/doc/user/packages/maven_repository/index.md
@@ -66,6 +66,13 @@ The three endpoints are:
 - **Group-level**: Use when you want to install packages from many different projects in the same GitLab group. GitLab does not guarantee the uniqueness of package names within the group. You can have two projects with the same package name and package version. As a result, GitLab serves whichever one is more recent.
 - **Instance-level**: Use when you have many packages in different GitLab groups or in their own namespace.
 
+For the instance-level endpoint, ensure the relevant section of your `pom.xml` in Maven looks like this:
+
+```xml
+  <groupId>group-slug.subgroup-slug</groupId>
+  <artifactId>project-slug</artifactId>
+```
+
 **Only packages that have the same path as the project** are exposed by the instance-level endpoint.
 
 | Project             | Package                          | Instance-level endpoint available |
diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md
index f0d75895e6e..5be7c49b5c2 100644
--- a/doc/user/project/import/index.md
+++ b/doc/user/project/import/index.md
@@ -167,6 +167,7 @@ GitLab from:
 
 For more information, see:
 
+- Information on paid GitLab [migration services](https://about.gitlab.com/services/migration/).
 - [Quick Start](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start).
 - [Frequently Asked Migration Questions](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md),
   including settings that need checking afterwards and other limitations.
diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md
index eeeeace6dd2..85ef3dc8405 100644
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@@ -7,22 +7,56 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 # Migrating projects using file exports **(FREE)**
 
 Existing projects on any self-managed GitLab instance or GitLab.com can be exported to a file and
-then imported into a new GitLab instance.
+then imported into another GitLab instance. You can also copy GitLab projects to another location with more automation by
+[migrating groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
 
-GitLab maps user contributions correctly when an admin access token is used to perform the import.
+## Preserving user contributions
 
-Consequently, migrating projects using file exports does not map user contributions correctly when you are importing
-projects from a self-managed instance to GitLab.com.
+Preserving user contribution depends on meeting the following requirements:
 
-Instead, all GitLab user associations (such as comment author) are changed to the user importing the project. For more
-information, see the prerequisites and important notes in these sections:
+### Migrating from GitLab self-managed to GitLab.com
 
-- [Export a project and its data](../settings/import_export.md#export-a-project-and-its-data).
-- [Import the project](../settings/import_export.md#import-a-project-and-its-data).
+When migrating projects by using file exports, an administrator's access token is required for user contributions to map correctly.
 
-To preserve contribution history, [migrate using direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
+Therefore, user contributions never map correctly when importing file exports from a self-managed instance to GitLab.com. Instead, all GitLab user associations (such as
+comment author) are changed to the user importing the project. To preserve contribution history, do one of the following:
 
-If you migrate from GitLab.com to self-managed GitLab, an administrator can create users on the self-managed GitLab instance.
+- [Migrate by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended).
+- Consider paid GitLab [migration services](https://about.gitlab.com/services/migration/).
+
+### Migrating to GitLab self-managed
+
+To ensure GitLab maps users and their contributions correctly:
+
+- The owner of the project's top-level group should export the project so that the information of all members (direct and inherited) with access to the project can be included in the exported file. Project maintainers and owners can initiate the project export. However, only direct members of a project are then exported.
+- An administrator must perform the import with an administrator access token.
+- Required users must exist on the destination GitLab instance. An administrator can create confirmed users either in bulk in a Rails console or one by one in the UI.
+- Users must [set a public email in their profiles](../../profile/index.md#set-your-public-email) on the source GitLab instance that matches their primary email
+  address on the destination GitLab instance. You can also manually add users' public emails by
+  [editing project export files](#edit-project-export-files).
+
+When the email of an existing user matches the email of an imported user, that user is added as a [direct member](../members/index.md) to the imported project.
+
+If any of the previous conditions are not met, user contributions are not mapped correctly. Instead, all GitLab user associations are changed to the user who performed the import.
+That user becomes an author of merge requests created by other users. Supplementary comments mentioning original authors are:
+
+- Added for comments, merge request approvals, linked tasks, and items.
+- Not added for the merge request or issue creator, added or removed labels, and merged-by information.
+
+## Edit project export files
+
+You can add or remove data from export files. For example, you can:
+
+- Manually add users public emails to the `project_members.ndjson` file.
+- Trim CI pipelines by removing lines from the `ci_pipelines.ndjson` file.
+
+To edit a project export file:
+
+1. Extract the exported `.tar.gz` file.
+1. Edit the appropriate file . For example, `tree/project/project_members.ndjson`.
+1. Compress the files back to a `.tar.gz` file.
+
+You can also make sure that all members were exported by checking the `project_members.ndjson` file.
 
 ## Compatibility
 
@@ -75,8 +109,6 @@ Prerequisites:
 
 - Review the list of [items that are exported](#items-that-are-exported). Not all items are exported.
 - You must have at least the Maintainer role for the project.
-- For the user mapping to work correctly, users must [set a public email](../../profile/index.md#set-your-public-email)
-  in the source GitLab instance that matches their verified primary email in the target GitLab instance.
 
 To export a project and its data, follow these steps:
 
@@ -94,15 +126,13 @@ moved to your configured `uploads_directory`. Every 24 hours, a worker deletes t
 
 ### Items that are exported
 
-The [`import_export.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/import_export/project/import_export.yml)
-file for projects lists many of the items exported and imported when migrating projects using file exports. View this file in the branch
-for your version of GitLab to see the list of items relevant to you. For example,
-[`import_export.yml` on the `14-10-stable-ee` branch](https://gitlab.com/gitlab-org/gitlab/-/blob/14-10-stable-ee/lib/gitlab/import_export/project/import_export.yml).
+Exported project items depend on the version of GitLab you use. To determine if a
+specific project item is exported:
 
-Migrating projects with file exports uses the same export and import mechanisms as creating projects from templates at the [group](../../group/custom_project_templates.md) and
-[instance](../../admin_area/custom_project_templates.md) levels. Therefore, the list of exported items is the same.
+1. Check the [`exporters` array](https://gitlab.com/gitlab-org/gitlab/blob/0a60d6dcfa7b809cf4fe0c2e239f406014d92e34/app/services/projects/import_export/export_service.rb#L25-28).
+1. Check the [`project/import_export.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/import_export/project/import_export.yml) file for projects for your GitLab version (for example, `<https://gitlab.com/gitlab-org/gitlab/-/blob/15-9-stable-ee/lib/gitlab/import_export/project/import_export.yml>` for GitLab 15.9).
 
-Items that are exported include:
+For a quick overview, items that are exported include:
 
 - Project and wiki repositories
 - Project uploads
@@ -139,22 +169,25 @@ Items that are exported include:
 Items that are **not** exported include:
 
 - [Child pipeline history](https://gitlab.com/gitlab-org/gitlab/-/issues/221088)
+- Pipeline triggers
 - Build traces and artifacts
 - Package and container registry images
 - CI/CD variables
-- Pipeline triggers
 - Webhooks
 - Any encrypted tokens
 - [Number of required approvals](https://gitlab.com/gitlab-org/gitlab/-/issues/221087)
 - Repository size limits
 - Deploy keys allowed to push to protected branches
-- Secure Files
+- Secure files
 - [Activity logs for Git-related events](https://gitlab.com/gitlab-org/gitlab/-/issues/214700) (for example, pushing and creating tags)
 - Security policies associated with your project
 
+Migrating projects with file exports uses the same export and import mechanisms as creating projects from templates at the [group](../../group/custom_project_templates.md) and
+[instance](../../admin_area/custom_project_templates.md) levels. Therefore, the list of exported items is the same.
+
 ## Import a project and its data
 
-> Default maximum import file size [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to unlimited in GitLab 13.8.
+> Default maximum import file size [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to unlimited in GitLab 13.8. Administrators of self-managed instances can [set maximum import file size](#set-maximum-import-file-size). On GitLab.com, the value is [set to 5 GB](../../gitlab_com/index.md#account-and-limit-settings).
 
 WARNING:
 Only import projects from sources you trust. If you import a project from an untrusted source, it
@@ -197,12 +230,7 @@ Deploy keys aren't imported. To use deploy keys, you must enable them in your im
 
 If you have a larger project, consider [using a Rake task](../../../administration/raketasks/project_import_export.md#import-large-projects).
 
-## Automate group and project import **(PREMIUM)**
-
-For information on automating user, group, and project import API calls, see
-[Automate group and project import](../import/index.md#automate-group-and-project-import).
-
-## Maximum import file size
+## Set maximum import file size **(FREE SELF)**
 
 Administrators can set the maximum import file size one of two ways:
 
@@ -211,25 +239,6 @@ Administrators can set the maximum import file size one of two ways:
 
 The default is `0` (unlimited).
 
-For the GitLab.com setting, see the [Account and limit settings](../../gitlab_com/index.md#account-and-limit-settings)
-section of the GitLab.com settings page.
-
-## Map users for import
-
-Imported users can be mapped by their public email addresses on self-managed instances, if an administrator (not an owner) does the import.
-
-- The project must be exported by a project or group member with the Owner role.
-- Public email addresses are not set by default. Users must [set it in their profiles](../../profile/index.md#set-your-public-email)
-  for mapping to work correctly.
-- For contributions to be mapped correctly, users must be an existing member of the namespace,
-  or they can be added as a member of the project. Otherwise, a supplementary comment is left to mention that the original
-  author and the merge requests, notes, or issues that are owned by the importer.
-- Imported users are set as [direct members](../members/index.md)
-  in the imported project.
-
-For project migration imports performed over GitLab.com groups, preserving author information is
-possible through a [professional services engagement](https://about.gitlab.com/services/migration/).
-
 ## Rate limits
 
 To help avoid abuse, by default, users are rate limited to: