Add latest changes from gitlab-org/gitlab@master

18 files changed, 153 insertions, 107 deletions

diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 73ec3ed8781..f3785078393 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -8862,6 +8862,29 @@ The edge type for [`Discussion`](#discussion).
 | <a id="discussionedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="discussionedgenode"></a>`node` | [`Discussion`](#discussion) | The item at the end of the edge. |
 
+#### `DoraPerformanceScoreCountConnection`
+
+The connection type for [`DoraPerformanceScoreCount`](#doraperformancescorecount).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="doraperformancescorecountconnectionedges"></a>`edges` | [`[DoraPerformanceScoreCountEdge]`](#doraperformancescorecountedge) | A list of edges. |
+| <a id="doraperformancescorecountconnectionnodes"></a>`nodes` | [`[DoraPerformanceScoreCount]`](#doraperformancescorecount) | A list of nodes. |
+| <a id="doraperformancescorecountconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+
+#### `DoraPerformanceScoreCountEdge`
+
+The edge type for [`DoraPerformanceScoreCount`](#doraperformancescorecount).
+
+##### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="doraperformancescorecountedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="doraperformancescorecountedgenode"></a>`node` | [`DoraPerformanceScoreCount`](#doraperformancescorecount) | The item at the end of the edge. |
+
 #### `EgressNodeConnection`
 
 The connection type for [`EgressNode`](#egressnode).
@@ -14315,6 +14338,20 @@ Returns [`[DoraMetric!]`](#dorametric).
 | <a id="dorametrictimetorestoreservice"></a>`timeToRestoreService` | [`Float`](#float) | Median time to close an incident. |
 | <a id="dorametricvalue"></a>`value` **{warning-solid}** | [`Float`](#float) | **Deprecated** in 15.10. Moved to corresponding metric field. |
 
+### `DoraPerformanceScoreCount`
+
+Aggregated DORA score counts for projects for the last complete month.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="doraperformancescorecounthighprojectscount"></a>`highProjectsCount` | [`Int`](#int) | Number of projects that score "high" on the metric. |
+| <a id="doraperformancescorecountlowprojectscount"></a>`lowProjectsCount` | [`Int`](#int) | Number of projects that score "low" on the metric. |
+| <a id="doraperformancescorecountmediumprojectscount"></a>`mediumProjectsCount` | [`Int`](#int) | Number of projects that score "medium" on the metric. |
+| <a id="doraperformancescorecountmetricname"></a>`metricName` | [`String!`](#string) | Name of the DORA metric. |
+| <a id="doraperformancescorecountnodataprojectscount"></a>`noDataProjectsCount` | [`Int`](#int) | Number of projects with no data. |
+
 ### `EgressNode`
 
 #### Fields
@@ -15405,6 +15442,7 @@ GPG signature for a signed commit.
 | <a id="groupdescription"></a>`description` | [`String`](#string) | Description of the namespace. |
 | <a id="groupdescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `description`. |
 | <a id="groupdora"></a>`dora` | [`Dora`](#dora) | Group's DORA metrics. |
+| <a id="groupdoraperformancescorecounts"></a>`doraPerformanceScoreCounts` | [`DoraPerformanceScoreCountConnection`](#doraperformancescorecountconnection) | Group's DORA scores for all projects by DORA key metric for the last complete month. (see [Connections](#connections)) |
 | <a id="groupemailsdisabled"></a>`emailsDisabled` | [`Boolean`](#boolean) | Indicates if a group has email notifications disabled. |
 | <a id="groupenforcefreeusercap"></a>`enforceFreeUserCap` | [`Boolean`](#boolean) | Indicates whether the group has limited users for a free plan. |
 | <a id="groupepicboards"></a>`epicBoards` | [`EpicBoardConnection`](#epicboardconnection) | Find epic boards. (see [Connections](#connections)) |
diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md
index 068a0a0dfd3..14f73fd3aad 100644
--- a/doc/api/merge_requests.md
+++ b/doc/api/merge_requests.md
@@ -14,7 +14,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - `with_merge_status_recheck` [changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115948) in GitLab 15.11  [with a flag](../administration/feature_flags.md) named `restrict_merge_status_recheck` to be ignored for requests from users insufficient permissions. Disabled by default.
 > - `approvals_before_merge` was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119503) in GitLab 16.0.
 
-Every API call to merge requests must be authenticated.
+Authentication is required for API calls to non-public information.
 
 ## Removals in API v5
 
diff --git a/doc/architecture/blueprints/cells/index.md b/doc/architecture/blueprints/cells/index.md
index 94ff12f2c55..ffb005ae636 100644
--- a/doc/architecture/blueprints/cells/index.md
+++ b/doc/architecture/blueprints/cells/index.md
@@ -346,6 +346,33 @@ This is the list of known affected features with the proposed solutions.
 - [Cells: GitLab Pages](cells-feature-gitlab-pages.md)
 - [Cells: Agent for Kubernetes](cells-feature-agent-for-kubernetes.md)
 
+## Frequently Asked Questions
+
+### What's the difference between Cells architecture and GitLab Dedicated?
+
+The new Cells architecture is meant to scale GitLab.com. And the way to achieve this is by moving
+organizations into cells, but different organizations can still share each other server resources, even
+if the application provides isolation from other organizations. But all of them still operate under the
+existing GitLab SaaS domain name `gitlab.com`. Also, cells still share some common data, like `users`, and
+routing information of groups and projects. For example, no two users can have the same username
+even if they belong to different organizations that exist on different cells.
+
+With the aforementioned differences, GitLab Dedicated is still offered at higher costs due to the fact
+that it's provisioned via dedicated server resources for each customer, while Cells use shared resources. Which
+makes GitLab Dedicated more suited for bigger customers, and GitLab Cells more suitable for small to mid size
+companies that are starting on GitLab.com.
+
+On the other hand, [GitLab Dedicated](https://about.gitlab.com/dedicated/) is meant to provide completely
+isolated GitLab instance for any organization. Where this instance is running on its own custom domain name, and
+totally isolated from any other GitLab instance, including GitLab SaaS. For example, users on GitLab dedicated
+don't have to have a different and unique username that was already taken on GitLab.com.
+
+### Can different cells communicate with each other?
+
+Up until iteration 3, cells communicate with each other only via a shared database that contains common
+data. In iteration 4 we are going to evaluate the option of cells calling each other via API to provide more
+isolation and reliability.
+
 ## Decision log
 
 - 2022-03-15: Google Cloud as the cloud service. For details, see [issue 396641](https://gitlab.com/gitlab-org/gitlab/-/issues/396641#note_1314932272).
diff --git a/doc/ci/pipelines/pipeline_artifacts.md b/doc/ci/pipelines/pipeline_artifacts.md
index d8db79a54dc..79435c0276d 100644
--- a/doc/ci/pipelines/pipeline_artifacts.md
+++ b/doc/ci/pipelines/pipeline_artifacts.md
@@ -2,28 +2,13 @@
 stage: Verify
 group: Pipeline Security
 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
+redirect_to: '../testing/test_coverage_visualization.md'
+remove_date: '2023-08-31'
 ---
 
-# Pipeline artifacts **(FREE)**
+This document was moved to [another location](../testing/test_coverage_visualization.md).
 
-Pipeline artifacts are files created by GitLab after a pipeline finishes. Pipeline artifacts are
-different to [job artifacts](../jobs/job_artifacts.md) because they are not explicitly managed by
-`.gitlab-ci.yml` definitions.
-
-Pipeline artifacts are used by the [test coverage visualization feature](../testing/test_coverage_visualization.md)
-to collect coverage information.
-
-## Storage
-
-Pipeline artifacts are saved to disk or object storage. They count towards a project's [storage usage quota](../../user/usage_quotas.md#storage-usage-quota).
-The **Artifacts** on the Usage Quotas page is the sum of all job artifacts and pipeline artifacts.
-
-## When pipeline artifacts are deleted
-
-Pipeline artifacts from:
-
-- The latest pipeline are kept forever.
-- Pipelines superseded by a newer pipeline are deleted seven days after their creation date.
-
-It can take up to two days for GitLab to delete pipeline artifacts from when they are due to be
-deleted.
+<!-- This redirect file can be deleted after <2023-08-31>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/ci/runners/saas/linux_saas_runner.md b/doc/ci/runners/saas/linux_saas_runner.md
index 055cf651067..f596d4da8c5 100644
--- a/doc/ci/runners/saas/linux_saas_runner.md
+++ b/doc/ci/runners/saas/linux_saas_runner.md
@@ -98,9 +98,10 @@ Below are the settings for SaaS runners on Linux.
   and [#4070](https://gitlab.com/gitlab-com/gl-infra/reliability/-/issues/4070).
 
 NOTE:
-SaaS runner instances are provisioned with a 25 GB storage volume. The underlying disk space of the storage volume
+Typical SaaS runner instances are provisioned with a 25 GB storage volume. GPU-enabled runners
+are provisioned with a 50 GB storage volume. The underlying disk space of the storage volume
 is shared by the operating system, the Docker image, and a copy of your cloned repository.
-This means that the available free disk space that your jobs can use is **less than 25 GB**.
+This means that the available free disk space that your jobs can use is **less than 25 (or 50) GB**.
 
 <!--- start_remove The following content will be removed on remove_date: '2023-08-22' -->
 
diff --git a/doc/ci/testing/test_coverage_visualization.md b/doc/ci/testing/test_coverage_visualization.md
index 31d1b7f3337..2fcd1ecfad2 100644
--- a/doc/ci/testing/test_coverage_visualization.md
+++ b/doc/ci/testing/test_coverage_visualization.md
@@ -73,10 +73,11 @@ a [blocking manual job](../jobs/job_control.md#types-of-manual-jobs), the
 pipeline waits for the manual job before continuing and is not considered complete.
 The visualization cannot be displayed if the blocking manual job did not run.
 
-### Artifact expiration
+### Data expiration
 
-By default, the [pipeline artifact](../pipelines/pipeline_artifacts.md#storage) used
-to draw the visualization on the merge request expires **one week** after creation.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321323) in GitLab 13.12, the latest data is kept regardless of expiry time.
+
+By default, the data used to draw the visualization on the merge request expires **one week** after creation.
 
 ### Coverage report from child pipeline
 
diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md
index 2cabb4bbaab..6e4effe4298 100644
--- a/doc/ci/yaml/index.md
+++ b/doc/ci/yaml/index.md
@@ -837,7 +837,6 @@ subdirectories of `binaries/`.
 > - [Made default behavior](https://gitlab.com/gitlab-org/gitlab/-/issues/229936) in GitLab 13.4.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/241026) in GitLab 13.8, keeping latest job artifacts can be disabled at the project level.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276583) in GitLab 13.9, keeping latest job artifacts can be disabled instance-wide.
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321323) in GitLab 13.12, the latest pipeline artifacts are kept regardless of expiry time.
 
 Use `expire_in` to specify how long [job artifacts](../jobs/job_artifacts.md) are stored before
 they expire and are deleted. The `expire_in` setting does not affect:
@@ -845,9 +844,6 @@ they expire and are deleted. The `expire_in` setting does not affect:
 - Artifacts from the latest job, unless keeping the latest job artifacts is disabled
   [at the project level](../jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
   or [instance-wide](../../user/admin_area/settings/continuous_integration.md#keep-the-latest-artifacts-for-all-jobs-in-the-latest-successful-pipelines).
-- [Pipeline artifacts](../pipelines/pipeline_artifacts.md). You can't specify an expiration date for
-  pipeline artifacts. See [When pipeline artifacts are deleted](../pipelines/pipeline_artifacts.md#when-pipeline-artifacts-are-deleted)
-  for more information.
 
 After their expiry, artifacts are deleted hourly by default (using a cron job), and are not
 accessible anymore.
diff --git a/doc/development/ai_features.md b/doc/development/ai_features.md
index b18345d3afa..e5d5581f704 100644
--- a/doc/development/ai_features.md
+++ b/doc/development/ai_features.md
@@ -107,7 +107,7 @@ In order to obtain a GCP service key for local development, please follow the st
 - Create a sandbox GCP environment by visiting [this page](https://about.gitlab.com/handbook/infrastructure-standards/#individual-environment) and following the instructions, or by requesting access to our existing group environment by using [this template](https://gitlab.com/gitlab-com/it/infra/issue-tracker/-/issues/new?issuable_template=gcp_group_account_iam_update_request). At this time, access to any endpoints outside of `text-bison` or `chat-bison` must be made through the group environment.
 - In the GCP console, go to `IAM & Admin` > `Service Accounts` and click on the "Create new service account" button
 - Name the service account something specific to what you're using it for. Select Create and Continue. Under `Grant this service account access to project`, select the role `Vertex AI User`. Select `Continue` then `Done`
-- Select your new service account and `Manage keys` > `Add Key` > `Create new key`. This will download the **private** JSON credentials for your service account. 
+- Select your new service account and `Manage keys` > `Add Key` > `Create new key`. This will download the **private** JSON credentials for your service account.
 - Open the Rails console. Update the settings to:
 
 ```ruby
@@ -321,7 +321,6 @@ We recommend to use [policies](policies.md) to deal with authorization for a fea
 1. Feature specific feature flag is enabled
 1. The namespace has the required license for the feature
 1. User is a member of the group/project
-1. Resource is allowed to be sent (see `send_to_ai?` method)
 1. `experiment_features_enabled` and `third_party_ai_features_enabled` flags are set on the `Namespace`
 
 For our example, we need to implement the `allowed?(:amazing_new_ai_feature)` call. As an example, you can look at the [Issue Policy for the summarize comments feature](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/policies/ee/issue_policy.rb). In our example case, we want to implement the feature for Issues as well:
@@ -335,8 +334,7 @@ module EE
     prepended do
       with_scope :subject
       condition(:ai_available) do
-        ::Feature.enabled?(:openai_experimentation) &&
-          @subject.send_to_ai?
+        ::Feature.enabled?(:openai_experimentation)
       end
 
       with_scope :subject
@@ -353,19 +351,6 @@ module EE
 end
 ```
 
-### Implement `send_to_ai?`
-
-To make sure we only send data that is allowed to be sent, we have the `send_to_ai?` method. It checks if the resource is not confidential and public data.
-Some resources already implement `send_to_ai?`. Make sure yours does as well. In our case, `Issue` is already covered with the `Issuable` concern. This is an example how it could look like:
-
-```ruby
-# ee/app/models/concerns/ee
-
-def send_to_ai?
-  !try(:confidential) && resource_parent.public?
-end
-```
-
 ### Check if feature is allowed for this resource based on namespace settings
 
 There are two settings allowed on root namespace level that restrict the use of AI features:
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 81d340a0e4e..e590eb60812 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -47,6 +47,12 @@ The **Approved** button is in the merge request widget.
 Getting your merge request **merged** also requires a maintainer. If it requires
 more than one approval, the last maintainer to review and approve merges it.
 
+Some domain areas (like `Verify`) require an approval from a domain expert, based on
+CODEOWNERS rules. Because CODEOWNERS sections are independent approval rules, we could have certain
+rules (for example `Verify`) that may be a subset of other more generic approval rules (for example `backend`).
+For a more efficient process, authors should look for domain-specific approvals before generic approvals.
+Domain-specific approvers may also be maintainers, and if so they should review the domain specifics and broader change at the same time and approve once for both roles.
+
 Read more about [author responsibilities](#the-responsibility-of-the-merge-request-author) below.
 
 ### Domain experts
diff --git a/doc/development/pipelines/internals.md b/doc/development/pipelines/internals.md
index 678297eb3e5..9e511fb88f6 100644
--- a/doc/development/pipelines/internals.md
+++ b/doc/development/pipelines/internals.md
@@ -130,7 +130,7 @@ that are scoped to a single [configuration keyword](../../ci/yaml/index.md#job-k
 | `.default-retry` | Allows a job to [retry](../../ci/yaml/index.md#retry) upon `unknown_failure`, `api_failure`, `runner_system_failure`, `job_execution_timeout`, or `stuck_or_timeout_failure`. |
 | `.default-before_script` | Allows a job to use a default `before_script` definition suitable for Ruby/Rails tasks that may need a database running (for example, tests). |
 | `.setup-test-env-cache` | Allows a job to use a default `cache` definition suitable for setting up test environment for subsequent Ruby/Rails tasks. |
-| `.rails-cache` | Allows a job to use a default `cache` definition suitable for Ruby/Rails tasks. |
+| `.ruby-cache` | Allows a job to use a default `cache` definition suitable for Ruby tasks. |
 | `.static-analysis-cache` | Allows a job to use a default `cache` definition suitable for static analysis tasks. |
 | `.coverage-cache` | Allows a job to use a default `cache` definition suitable for coverage tasks. |
 | `.qa-cache` | Allows a job to use a default `cache` definition suitable for QA tasks. |
diff --git a/doc/development/pipelines/performance.md b/doc/development/pipelines/performance.md
index b31d239eb6b..2dbed640fbb 100644
--- a/doc/development/pipelines/performance.md
+++ b/doc/development/pipelines/performance.md
@@ -38,7 +38,6 @@ This works well for the following reasons:
    with fixed keys:
    - `.setup-test-env-cache`
    - `.ruby-cache`
-   - `.rails-cache`
    - `.static-analysis-cache`
    - `.rubocop-cache`
    - `.coverage-cache`
diff --git a/doc/integration/jira/configure.md b/doc/integration/jira/configure.md
index 22c12786060..1ce91d5f88f 100644
--- a/doc/integration/jira/configure.md
+++ b/doc/integration/jira/configure.md
@@ -22,7 +22,7 @@ Prerequisites:
   - Jira personal access token (GitLab 16.0 and later).
 
 You can enable the Jira issue integration by configuring your project settings in GitLab.
-You can also configure these settings at the [group level](../../user/admin_area/settings/project_integration_management.md#manage-group-level-default-settings-for-a-project-integration) or [instance level](../../user/admin_area/settings/project_integration_management.md#manage-instance-level-default-settings-for-a-project-integration) for self-managed GitLab.
+You can configure these settings at the [group level](../../user/admin_area/settings/project_integration_management.md#manage-group-level-default-settings-for-a-project-integration) or at the [instance level](../../user/admin_area/settings/project_integration_management.md#manage-instance-level-default-settings-for-a-project-integration) for self-managed GitLab.
 
 To configure your project settings in GitLab:
 
@@ -83,7 +83,7 @@ To create a Jira Cloud API token:
 1. Select **Create API token**.
 1. In the dialog, enter a label for your token and select **Create**.
 
-To copy the API token, select **Copy** and paste the token somewhere safe.
+To copy the API token, select **Copy**.
 
 ## Migrate from Jira Server to Jira Cloud in GitLab
 
@@ -93,7 +93,7 @@ To migrate from Jira Server to Jira Cloud in GitLab and maintain your Jira integ
 1. On the left sidebar, select **Settings > Integrations**.
 1. Select **Jira**.
 1. In **Web URL**, enter the new Jira site URL (for example, `https://myjirasite.atlassian.net`).
-1. In **Email or username**, enter the email or username registered on your Jira profile.
+1. In **Email or username**, enter the email registered on your Jira profile.
 1. [Create a Jira Cloud API token](#create-a-jira-cloud-api-token), and copy the token value.
 1. In **API token or password**, paste the API token value.
 1. Optional. Select **Test settings**.
diff --git a/doc/integration/jira/connect-app.md b/doc/integration/jira/connect-app.md
index 221e41b86f3..42d6091c26f 100644
--- a/doc/integration/jira/connect-app.md
+++ b/doc/integration/jira/connect-app.md
@@ -304,14 +304,9 @@ To resolve this issue on GitLab self-managed, follow one of the solutions below,
   - In all GitLab versions:
     - Re-install the GitLab for Jira Cloud app. This method might remove all synced data from the Jira development panel.
 
-### `Failed to update GitLab version` error when setting up the GitLab for Jira Cloud app for self-managed instances
+### `Failed to update the GitLab instance` for self-managed instances
 
-When you set up the GitLab for Jira Cloud app, you might get the following message after you enter your
-self-managed instance URL:
-
-```plaintext
-Failed to update GitLab version. Please try again.
-```
+When you set up the GitLab for Jira Cloud app, you might get a `Failed to update the GitLab instance` error after you enter your self-managed instance URL.
 
 To resolve this issue, ensure all prerequisites for your installation method have been met:
 
diff --git a/doc/integration/jira/dvcs/index.md b/doc/integration/jira/dvcs/index.md
index 0406fef3f1e..80666a2d9f9 100644
--- a/doc/integration/jira/dvcs/index.md
+++ b/doc/integration/jira/dvcs/index.md
@@ -49,7 +49,8 @@ To create a GitLab application for DVCS:
 
 To configure Jira for DVCS:
 
-1. Go to your DVCS account. **For Jira Server**, select **Settings (gear) > Applications > DVCS accounts**.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Applications**.
+1. On the left sidebar, select **DVCS accounts**.
 1. To create a new integration, for **Host**, select **GitLab** or **GitLab Self-Managed**.
 1. For **Team or User Account**, enter the relative path of a top-level GitLab group that [the GitLab user](#create-a-gitlab-application-for-dvcs) can access.
 1. In the **Host URL** text box, enter the appropriate URL.
@@ -72,6 +73,10 @@ personal namespaces, repeat the previous steps with additional Jira DVCS account
 Jira imports commits and branches for GitLab projects every 60 minutes. To refresh the data manually in Jira:
 
 1. Sign in to your Jira instance as the user you configured the integration with.
-1. Go to **Settings (gear) > Applications**.
-1. Select **DVCS accounts**.
-1. In the **Last activity** column, next to the repository you want to refresh, select **Refresh** (**{retry}**).
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Applications**.
+1. On the left sidebar, select **DVCS accounts**.
+1. To refresh one or more repositories in a DVCS account:
+   - **For all repositories**, next to the account, select the ellipsis (**{ellipsis_h}**) > **Refresh repositories**.
+   - **For a single repository**:
+     1. Select the account.
+     1. Hover over the repository you want to refresh, and in the **Last activity** column, select **Click to sync repository** (**{retry}**).
diff --git a/doc/integration/jira/jira_server_configuration.md b/doc/integration/jira/jira_server_configuration.md
index c840e1ebde5..672df5d615f 100644
--- a/doc/integration/jira/jira_server_configuration.md
+++ b/doc/integration/jira/jira_server_configuration.md
@@ -4,55 +4,55 @@ group: Import and Integrate
 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
 ---
 
-# Jira Server credentials **(FREE)**
+# Tutorial: Create Jira credentials **(FREE)**
 
-To [integrate Jira with GitLab](configure.md), you should create a separate Jira user account for your Jira projects
-to access projects in GitLab. This Jira user account must have write access to your Jira projects.
-To create the credentials:
+This tutorial shows you how to create Jira credentials. You can use your new Jira credentials to
+configure the [Jira issue integration](configure.md) in GitLab for Jira Data Center or Jira Server.
 
-1. [Create a Jira Server user](#create-a-jira-server-user).
-1. [Create a Jira Server group for the user](#create-a-jira-server-group-for-the-user).
+To create Jira credentials, here's what we're going to do:
+
+1. [Create a Jira user](#create-a-jira-user).
+1. [Create a Jira group for the user](#create-a-jira-group-for-the-user).
 1. [Create a permission scheme for the group](#create-a-permission-scheme-for-the-group).
 
-Alternatively, you can use an existing Jira user account, provided the user belongs to a Jira group that
-has been granted the **Administer Projects** [permission scheme](#create-a-permission-scheme-for-the-group).
+Prerequisite:
+
+- You must have administrator access to the Jira instance.
+
+## Create a Jira user
 
-After you select a Jira user account, [configure the integration](configure.md#configure-the-integration) in GitLab to use the account.
+To create a Jira user:
 
-## Create a Jira Server user
+1. Sign in to your Jira instance as an administrator.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **User management**.
+1. [Create a new user account](https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html#Create,edit,orremoveauser-CreateusersmanuallyinJira) with write access to your Jira projects.
 
-To create a Jira Server user:
+   Alternatively, you can use an existing user account, provided the user belongs to a Jira group that has been granted
+   the **Administer Projects** [permission scheme](#create-a-permission-scheme-for-the-group).
 
-1. Sign in to your Jira instance as a Jira administrator.
-1. On the top bar, in the upper-right corner, select the gear icon, then
-   select **User Management**.
-1. [Create a new user account manually](https://confluence.atlassian.com/adminjiraserver/create-edit-or-remove-a-user-938847025.html#Create,edit,orremoveauser-CreateusersmanuallyinJira) with write access to
-   projects in Jira.
-   - **Email address**: You should use a valid email address.
-   - **Username**: Set the username to `gitlab`.
-   - **Password**: You must set a password because the Jira issue integration does not
-     support SSO such as SAML.
+   - In **Email address**, enter a valid email address.
+   - In **Username**, enter `gitlab`.
+   - In **Password**, enter a password (the Jira issue integration does not support SSO such as SAML).
 1. Select **Create user**.
 
 Now that you've created a user named `gitlab`, it's time to create a group for the user.
 
-## Create a Jira Server group for the user
+## Create a Jira group for the user
 
-To create a Jira Server group for the user:
+To create a Jira group for the user:
 
-1. Sign in to your Jira instance as a Jira administrator.
-1. On the top bar, in the upper-right corner, select the gear icon, then
-   select **User Management**.
+1. Sign in to your Jira instance as an administrator.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **User management**.
 1. On the left sidebar, select **Groups**.
-1. In the **Add group** section, enter a **Name** for the group (for example,
+1. In the **Add group** section, enter a name for the group (for example,
    `gitlab-developers`), then select **Add group**.
-1. To add the `gitlab` user to the `gitlab-developers` group, select **Edit members**.
+1. To add the `gitlab` user to the new `gitlab-developers` group, select **Edit members**.
    The `gitlab-developers` group appears as a selected group.
 <!-- vale gitlab.BadPlurals = NO -->
 1. In the **Add members to selected group(s)** section, enter `gitlab`.
+<!-- vale gitlab.BadPlurals = YES -->
 1. Select **Add selected users**.
    The `gitlab` user appears as a group member.
-<!-- vale gitlab.BadPlurals = YES -->
 
 Now that you've added the `gitlab` user to a new group named `gitlab-developers`,
 it's time to create a permission scheme for the group.
@@ -61,15 +61,18 @@ it's time to create a permission scheme for the group.
 
 To create a permission scheme for the group:
 
-1. Sign in to your Jira instance as a Jira administrator.
-1. On the top bar, in the upper-right corner, select the gear icon, then
-   select **Issues**.
-1. On the left sidebar, select **Permission Schemes**.
-1. Select **Add Permission Scheme**, enter a **Name** and (optionally) a
-   **Description**, then select **Add**.
-1. In the permissions scheme list, locate your new permissions scheme, and
-   select **Permissions**.
+1. Sign in to your Jira instance as an administrator.
+1. On the top bar, in the upper-right corner, select **Administration** (**{settings}**) > **Issues**.
+1. On the left sidebar, select **Permission schemes**.
+1. Select **Add permission scheme**.
+1. In the **Add permission scheme** dialog:
+   - Enter a name for the scheme.
+   - Optional. Enter a description for the scheme.
+1. Select **Add**.
+1. On the **Permission schemes** page, in the **Actions** column, select **Permissions** for the new scheme.
 1. Next to **Administer Projects**, select **Edit**.
+1. In the **Grant permission** dialog, for **Granted to**, select **Group**.
 1. From the **Group** dropdown list, select `gitlab-developers`, then select **Grant**.
 
-You need the new Jira username and password when you [configure the integration](configure.md#configure-the-integration) in GitLab.
+You've done it! You can now use your new Jira username and password to configure the
+[Jira issue integration](configure.md) in GitLab for Jira Data Center or Jira Server.
diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md
index 57c7a80fa3e..e51e015dddf 100644
--- a/doc/topics/offline/quick_start_guide.md
+++ b/doc/topics/offline/quick_start_guide.md
@@ -4,7 +4,7 @@ group: Distribution
 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
 ---
 
-# Getting started with an offline GitLab Installation **(FREE SELF)**
+# Install an offline self-managed GitLab instance **(FREE SELF)**
 
 This is a step-by-step guide that helps you install, configure, and use a self-managed GitLab
 instance entirely offline.
diff --git a/doc/tutorials/develop.md b/doc/tutorials/develop.md
index 08497a09830..89fa957fd08 100644
--- a/doc/tutorials/develop.md
+++ b/doc/tutorials/develop.md
@@ -13,5 +13,6 @@ enabling you to work with those services directly from GitLab.
 
 | Topic | Description | Good for beginners |
 |-------|-------------|--------------------|
-| [Integrate with Jira](https://about.gitlab.com/blog/2021/04/12/gitlab-jira-integration-selfmanaged/) | Configure the Jira integration, so you can work with Jira issues from GitLab. | |
-| [Integrate with Gitpod](https://about.gitlab.com/blog/2021/07/19/teams-gitpod-integration-gitlab-speed-up-development/)  | Integrate with Gitpod, to help speed up your development. | |
+| [Create Jira credentials](../integration/jira/jira_server_configuration.md) | Create Jira credentials to configure the Jira issue integration in GitLab. | |
+| [Integrate with Jira](https://about.gitlab.com/blog/2021/04/12/gitlab-jira-integration-selfmanaged/) | Configure the Jira issue integration to connect one or more GitLab projects to a Jira instance. | |
+| [Integrate with Gitpod](https://about.gitlab.com/blog/2021/07/19/teams-gitpod-integration-gitlab-speed-up-development/)  | Integrate with Gitpod to set up a development environment for any GitLab project. | |
diff --git a/doc/user/search/index.md b/doc/user/search/index.md
index f6733abd305..24bc31a103f 100644
--- a/doc/user/search/index.md
+++ b/doc/user/search/index.md
@@ -96,8 +96,6 @@ To filter code search results by one or more languages:
 ## Search for projects by full path
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108906) in GitLab 15.9 [with a flag](../../administration/feature_flags.md) named `full_path_project_search`. Disabled by default.
-> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/388473) on GitLab.com in GitLab 15.9.
-> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111808) on self-managed GitLab 15.10.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114932) in GitLab 15.11. Feature flag `full_path_project_search` removed.
 
 You can search for a project by entering its full path (including the namespace it belongs to) in the search box.
@@ -108,6 +106,12 @@ For example, the search query:
 - `gitlab-org/gitlab` searches for the `gitlab` project in the `gitlab-org` namespace.
 - `gitlab-org/` displays autocomplete suggestions for projects that belong to the `gitlab-org` namespace.
 
+### Search archived projects
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121981) in GitLab 16.1.
+
+By default, archived projects are excluded from the search results. To include archived projects, add the parameter `include_archived=true` to the URL.
+
 ## Search for a SHA
 
 You can search for a commit SHA.