Add latest changes from gitlab-org/gitlab@master

26 files changed, 270 insertions, 232 deletions

diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 938c2b812e6..bca97d3d596 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -13999,6 +13999,10 @@ Returns [`Deployment`](#deployment).
 
 Metrics dashboard schema for the environment.
 
+WARNING:
+**Deprecated** in 16.0.
+Returns no data. Underlying feature was removed in 16.0.
+
 Returns [`MetricsDashboard`](#metricsdashboard).
 
 ###### Arguments
@@ -18689,6 +18693,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
+| <a id="pipelinejobsjobkind"></a>`jobKind` | [`CiJobKind`](#cijobkind) | Filter jobs by kind. |
 | <a id="pipelinejobsretried"></a>`retried` | [`Boolean`](#boolean) | Filter jobs by retry-status. |
 | <a id="pipelinejobssecurityreporttypes"></a>`securityReportTypes` | [`[SecurityReportTypeEnum!]`](#securityreporttypeenum) | Filter jobs by the type of security report they produce. |
 | <a id="pipelinejobsstatuses"></a>`statuses` | [`[CiJobStatus!]`](#cijobstatus) | Filter jobs by status. |
diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md
index e4be851ec82..1be5f6204a1 100644
--- a/doc/api/merge_requests.md
+++ b/doc/api/merge_requests.md
@@ -12,9 +12,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - `merge_user` was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/349031) as an eventual replacement for `merged_by` in GitLab 14.7.
 > - `merge_status` was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/3169#note_1162532204) in favor of `detailed_merge_status` in GitLab 15.6.
 > - `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.
 
+## Removals in API v5
+
+The `approvals_before_merge` attribute has been deprecated, and is scheduled to be removed
+in API v5 in favor of the [Merge request approvals API](merge_request_approvals.md).
+
 ## List merge requests
 
 Get all merge requests the authenticated user has access to. By
@@ -196,20 +202,6 @@ Supported attributes:
 ]
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-[
-  {
-    "id": 1,
-    "title": "test1",
-    "approvals_before_merge": null
-    ...
-  }
-]
-```
-
 ### Merge requests list response notes
 
 - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31890) in GitLab 13.0, listing merge requests may
@@ -400,20 +392,6 @@ Supported attributes:
 ]
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-[
-  {
-    "id": 1,
-    "title": "test1",
-    "approvals_before_merge": null
-    ...
-  }
-]
-```
-
 For important notes on response data, read [Merge requests list response notes](#merge-requests-list-response-notes).
 
 ## List group merge requests
@@ -587,20 +565,6 @@ Supported attributes:
 ]
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-[
-  {
-    "id": 1,
-    "title": "test1",
-    "approvals_before_merge": null
-    ...
-  }
-]
-```
-
 For important notes on response data, read [Merge requests list response notes](#merge-requests-list-response-notes).
 
 ## Get single MR
@@ -630,7 +594,7 @@ Supported attributes:
 
 | Attribute                        | Type | Description |
 |----------------------------------|------|-------------|
-| `approvals_before_merge` | integer | **(PREMIUM)** Number of approvals required before this merge request can merge. |
+| `approvals_before_merge`| integer |  **(PREMIUM)** Number of approvals required before this merge request can merge. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/353097) in GitLab 16.0. |
 | `assignee` | object | First assignee of the merge request. |
 | `assignees` | array | Assignees of the merge request. |
 | `author` | object | User who created this merge request. |
@@ -753,7 +717,7 @@ Supported attributes:
   },
   "has_conflicts": false,
   "blocking_discussions_resolved": true,
-  "approvals_before_merge": null,
+  "approvals_before_merge": null, // deprecated, use [Merge request approvals API](merge_request_approvals.md)
   "subscribed": true,
   "changes_count": "1",
   "latest_build_started_at": "2022-05-13T09:46:50.032Z",
@@ -1280,8 +1244,8 @@ POST /projects/:id/merge_requests
 | `target_branch`            | string  | **{check-circle}** Yes      | The target branch. |
 | `title`                    | string  | **{check-circle}** Yes      | Title of MR. |
 | `allow_collaboration`      | boolean | **{dotted-circle}** No       | Allow commits from members who can merge to the target branch. |
+| `approvals_before_merge` **(PREMIUM)**                      | integer | **{dotted-circle}** No | Number of approvals required before this can be merged (see below). To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/353097) in GitLab 16.0. |
 | `allow_maintainer_to_push` | boolean | **{dotted-circle}** No       | Alias of `allow_collaboration`. |
-| `approvals_before_merge` **(PREMIUM)** | integer | **{dotted-circle}** No | Number of approvals required before this can be merged (see below). |
 | `assignee_id`              | integer | **{dotted-circle}** No       | Assignee user ID. |
 | `assignee_ids`             | integer array | **{dotted-circle}** No | The ID of the users to assign the merge request to. Set to `0` or provide an empty value to unassign all assignees. |
 | `description`              | string  | **{dotted-circle}** No       | Description of the merge request. Limited to 1,048,576 characters. |
@@ -1293,13 +1257,6 @@ POST /projects/:id/merge_requests
 | `squash_on_merge`          | boolean | no       | Indicates if the merge request will be squashed when merged. |
 | `target_project_id`        | integer | **{dotted-circle}** No       | Numeric ID of the target project. |
 
-If `approvals_before_merge` is not provided, it inherits the value from the target project. If provided, the following conditions must hold for it to take effect:
-
-- The target project's `approvals_before_merge` must be greater than zero. A
-  value of zero disables approvals for that project.
-- The provided value of `approvals_before_merge` must be greater than the
-  target project's `approvals_before_merge`.
-
 ```json
 {
   "id": 1,
@@ -1421,18 +1378,6 @@ If `approvals_before_merge` is not provided, it inherits the value from the targ
 }
 ```
 
-Users of [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 1,
-  "title": "test1",
-  "approvals_before_merge": null
-  ...
-}
-```
-
 For important notes on response data, read [Single merge request response notes](#single-merge-request-response-notes).
 
 ## Update MR
@@ -1604,18 +1549,6 @@ Must include at least one non-required attribute from above.
 }
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 1,
-  "title": "test1",
-  "approvals_before_merge": null
-  ...
-}
-```
-
 For important notes on response data, read [Single merge request response notes](#single-merge-request-response-notes).
 
 ## Delete a merge request
@@ -1793,18 +1726,6 @@ Supported attributes:
 }
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 1,
-  "title": "test1",
-  "approvals_before_merge": null
-  ...
-}
-```
-
 This API returns specific HTTP status codes on failure:
 
 | HTTP Status | Message | Reason |
@@ -2006,18 +1927,6 @@ Supported attributes:
 }
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 1,
-  "title": "test1",
-  "approvals_before_merge": null
-  ...
-}
-```
-
 For important notes on response data, read [Single merge request response notes](#single-merge-request-response-notes).
 
 ## Rebase a merge request
@@ -2318,18 +2227,6 @@ Example response:
 }
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 1,
-  "title": "test1",
-  "approvals_before_merge": null
-  ...
-}
-```
-
 For important notes on response data, read [Single merge request response notes](#single-merge-request-response-notes).
 
 ## Unsubscribe from a merge request
@@ -2489,18 +2386,6 @@ Example response:
 }
 ```
 
-Users on [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/) also see
-the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 1,
-  "title": "test1",
-  "approvals_before_merge": null
-  ...
-}
-```
-
 For important notes on response data, read [Single merge request response notes](#single-merge-request-response-notes).
 
 ## Create a to-do item
diff --git a/doc/api/projects.md b/doc/api/projects.md
index ca57ca76a81..3105da44906 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -17,6 +17,16 @@ For details, see [Project visibility](../user/public_access.md).
 
 The fields returned in responses vary based on the [permissions](../user/permissions.md) of the authenticated user.
 
+## Removals in API v5
+
+These attributes are deprecated, and are scheduled to be removed in v5 of the API:
+
+- `tag_list`: Use the `topics` attribute instead.
+- `marked_for_deletion_at`: Use the `marked_for_deletion_on` attribute instead.
+  Available only to [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/).
+- `approvals_before_merge`: Use the [Merge request approvals API](merge_request_approvals.md) instead.
+  Available only to [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/).
+
 ## Project merge method
 
 The `merge_method` can use these options:
@@ -266,29 +276,6 @@ When the user is authenticated and `simple` is not set this returns something li
 ]
 ```
 
-NOTE:
-The `tag_list` attribute has been deprecated
-and is removed in API v5 in favor of the `topics` attribute.
-
-NOTE:
-For users of [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/),
-the `marked_for_deletion_at` attribute has been deprecated, and is removed
-in API v5 in favor of the `marked_for_deletion_on` attribute.
-
-Users of [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/)
-can also see the `approvals_before_merge` parameter:
-
-```json
-[
-  {
-    "id": 4,
-    "description": null,
-    "approvals_before_merge": 0,
-    ...
-  }
-]
-```
-
 You can filter by [custom attributes](custom_attributes.md) with:
 
 ```plaintext
@@ -548,7 +535,7 @@ GET /users/:user_id/projects
     "auto_devops_enabled": true,
     "auto_devops_deploy_strategy": "continuous",
     "repository_storage": "default",
-    "approvals_before_merge": 0,
+    "approvals_before_merge": 0, // Deprecated. Use merge request approvals API instead.
     "mirror": false,
     "mirror_user_id": 45,
     "mirror_trigger_builds": false,
@@ -807,7 +794,7 @@ Example response:
     "auto_devops_enabled": true,
     "auto_devops_deploy_strategy": "continuous",
     "repository_storage": "default",
-    "approvals_before_merge": 0,
+    "approvals_before_merge": 0, // Deprecated. Use merge request approvals API instead.
     "mirror": false,
     "mirror_user_id": 45,
     "mirror_trigger_builds": false,
@@ -989,7 +976,7 @@ GET /projects/:id
   "squash_option": "default_on",
   "auto_devops_enabled": true,
   "auto_devops_deploy_strategy": "continuous",
-  "approvals_before_merge": 0,
+  "approvals_before_merge": 0, // Deprecated. Use merge request approvals API instead.
   "mirror": false,
   "mirror_user_id": 45,
   "mirror_trigger_builds": false,
@@ -1034,22 +1021,6 @@ GET /projects/:id
 }
 ```
 
-NOTE:
-The `tag_list` attribute has been deprecated
-and is removed in API v5 in favor of the `topics` attribute.
-
-Users of [GitLab Premium or Ultimate](https://about.gitlab.com/pricing/)
-can also see the `approvals_before_merge` parameter:
-
-```json
-{
-  "id": 3,
-  "description": null,
-  "approvals_before_merge": 0,
-  ...
-}
-```
-
 Users of [GitLab Ultimate](https://about.gitlab.com/pricing/)
 can also see the `only_allow_merge_if_all_status_checks_passed`
 parameters using GitLab 15.5 and later:
@@ -1275,7 +1246,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your-token>" \
 | `allow_merge_on_skipped_pipeline`                           | boolean | **{dotted-circle}** No | Set whether or not merge requests can be merged with skipped jobs. |
 | `only_allow_merge_if_all_status_checks_passed` **(ULTIMATE)** | boolean | **{dotted-circle}** No | Indicates that merges of merge requests should be blocked unless all status checks have passed. Defaults to false. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369859) in GitLab 15.5 with feature flag `only_allow_merge_if_all_status_checks_passed` disabled by default. |
 | `analytics_access_level`                                    | string  | **{dotted-circle}** No | One of `disabled`, `private` or `enabled` |
-| `approvals_before_merge` **(PREMIUM)**                      | integer | **{dotted-circle}** No | How many approvers should approve merge requests by default. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). |
+| `approvals_before_merge` **(PREMIUM)**                      | integer | **{dotted-circle}** No | How many approvers should approve merge requests by default. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/353097) in GitLab 16.0. |
 | `auto_cancel_pending_pipelines`                             | string  | **{dotted-circle}** No | Auto-cancel pending pipelines. This action toggles between an enabled state and a disabled state; it is not a boolean. |
 | `auto_devops_deploy_strategy`                               | string  | **{dotted-circle}** No | Auto Deploy strategy (`continuous`, `manual` or `timed_incremental`). |
 | `auto_devops_enabled`                                       | boolean | **{dotted-circle}** No | Enable Auto DevOps for this project. |
@@ -1361,7 +1332,7 @@ POST /projects/user/:user_id
 | `allow_merge_on_skipped_pipeline`                           | boolean | **{dotted-circle}** No | Set whether or not merge requests can be merged with skipped jobs. |
 | `only_allow_merge_if_all_status_checks_passed` **(ULTIMATE)** | boolean | **{dotted-circle}** No | Indicates that merges of merge requests should be blocked unless all status checks have passed. Defaults to false. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369859) in GitLab 15.5 with feature flag `only_allow_merge_if_all_status_checks_passed` disabled by default. |
 | `analytics_access_level`                                    | string  | **{dotted-circle}** No | One of `disabled`, `private` or `enabled` |
-| `approvals_before_merge` **(PREMIUM)**                      | integer | **{dotted-circle}** No | How many approvers should approve merge requests by default. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). |
+| `approvals_before_merge` **(PREMIUM)**                      | integer | **{dotted-circle}** No | How many approvers should approve merge requests by default. [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/353097) in GitLab 16.0. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). |
 | `auto_cancel_pending_pipelines`                             | string  | **{dotted-circle}** No | Auto-cancel pending pipelines. This action toggles between an enabled state and a disabled state; it is not a boolean. |
 | `auto_devops_deploy_strategy`                               | string  | **{dotted-circle}** No | Auto Deploy strategy (`continuous`, `manual` or `timed_incremental`). |
 | `auto_devops_enabled`                                       | boolean | **{dotted-circle}** No | Enable Auto DevOps for this project. |
@@ -1460,7 +1431,7 @@ Supported attributes:
 | `allow_pipeline_trigger_approve_deployment` **(PREMIUM)**   | boolean        | **{dotted-circle}** No | Set whether or not a pipeline triggerer is allowed to approve deployments. |
 | `only_allow_merge_if_all_status_checks_passed` **(ULTIMATE)** | boolean | **{dotted-circle}** No | Indicates that merges of merge requests should be blocked unless all status checks have passed. Defaults to false.<br/><br/>[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369859) in GitLab 15.5 with feature flag `only_allow_merge_if_all_status_checks_passed` disabled by default. The feature flag was enabled by default in GitLab 15.9. |
 | `analytics_access_level`                                    | string         | **{dotted-circle}** No | One of `disabled`, `private` or `enabled` |
-| `approvals_before_merge` **(PREMIUM)**                      | integer        | **{dotted-circle}** No | How many approvers should approve merge request by default. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). |
+| `approvals_before_merge` **(PREMIUM)**                      | integer        | **{dotted-circle}** No | How many approvers should approve merge requests by default. [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/353097) in GitLab 16.0. To configure approval rules, see [Merge request approvals API](merge_request_approvals.md). |
 | `auto_cancel_pending_pipelines`                             | string         | **{dotted-circle}** No | Auto-cancel pending pipelines. This action toggles between an enabled state and a disabled state; it is not a boolean. |
 | `auto_devops_deploy_strategy`                               | string         | **{dotted-circle}** No | Auto Deploy strategy (`continuous`, `manual`, or `timed_incremental`). |
 | `auto_devops_enabled`                                       | boolean        | **{dotted-circle}** No | Enable Auto DevOps for this project. |
@@ -2882,7 +2853,7 @@ Example response:
   "auto_devops_enabled": true,
   "auto_devops_deploy_strategy": "continuous",
   "autoclose_referenced_issues": true,
-  "approvals_before_merge": 0,
+  "approvals_before_merge": 0, // Deprecated. Use merge request approvals API instead.
   "mirror": false,
   "compliance_frameworks": []
 }
diff --git a/doc/api/runners.md b/doc/api/runners.md
index 8d0be1c3aba..a2614b95bb9 100644
--- a/doc/api/runners.md
+++ b/doc/api/runners.md
@@ -679,9 +679,11 @@ curl --request POST "https://gitlab.example.com/api/v4/runners" \
 
 Response:
 
-| Status    | Description                     |
-|-----------|---------------------------------|
-| 201       | Runner was created              |
+| Status    | Description                       |
+|-----------|-----------------------------------|
+| 201       | Runner was created                |
+| 403       | Invalid runner registration token |
+| 410       | Runner registration disabled      |
 
 Example response:
 
diff --git a/doc/api/users.md b/doc/api/users.md
index f4547c06582..a2293090209 100644
--- a/doc/api/users.md
+++ b/doc/api/users.md
@@ -875,7 +875,7 @@ Parameters:
 | :------------------------------- | :------- | :--------------------------------------------------------------------------- |
 | `view_diffs_file_by_file`        | Yes      | Flag indicating the user sees only one file diff per page.                   |
 | `show_whitespace_in_diffs`       | Yes      | Flag indicating the user sees whitespace changes in diffs.                   |
-| `pass_user_identities_to_ci_jwt` | Yes      | Flag indicating the user passes their external identities as CI information. |
+| `pass_user_identities_to_ci_jwt` | Yes      | Flag indicating the user passes their external identities as CI information. This attribute does not contain enough information to identify or authorize the user in an external system. The attribute is internal to GitLab, and must not be passed to third-party services. |
 
 ## User follow
 
diff --git a/doc/architecture/blueprints/organization/index.md b/doc/architecture/blueprints/organization/index.md
index 8f835a33a4f..bd8d085413c 100644
--- a/doc/architecture/blueprints/organization/index.md
+++ b/doc/architecture/blueprints/organization/index.md
@@ -16,34 +16,37 @@ This document is a work in progress and represents the current state of the Orga
 
 ## Glossary
 
-- Organization: An organization is the umbrella for one or multiple top-level groups. Organizations are isolated from each other by default meaning that cross-namespace features will only work for namespaces that exist in a single organization.
+- Organization: An Organization is the umbrella for one or multiple top-level groups. Organizations are isolated from each other by default meaning that cross-namespace features will only work for namespaces that exist in a single Organization.
 - Top-level group: Top-level group is the name given to the topmost group of all other groups. Groups and projects are nested underneath the top-level group.
-- Cell: A Cell is a set of infrastructure components that contains multiple organizations. The infrastructure components provided in a Cell are shared among organizations, but not shared with other Cells. This isolation of infrastructure components means that Cells are independent from each other.
+- Cell: A Cell is a set of infrastructure components that contains multiple Organizations. The infrastructure components provided in a Cell are shared among Organizations, but not shared with other Cells. This isolation of infrastructure components means that Cells are independent from each other.
+- User: An Organization has many users. Joining an Organization makes someone a user of that Organization.
+- Member: Adding a user to a group or project within an Organization makes them a member. Members are always users, but users are not necessarily members of a group or project within an Organization. For instance, a user could just have accepted the invitation to join an Organization, but not be a member of any group or project it contains.
+- Non-user: A non-user of an Organization means a user is not part of that specific Organization.
 
 ## Summary
 
 Organizations solve the following problems:
 
-1. Enables grouping of top-level groups. For example, the following top-level groups would belong to the organization `GitLab`:
+1. Enables grouping of top-level groups. For example, the following top-level groups would belong to the Organization `GitLab`:
     1. `https://gitlab.com/gitlab-org/`
     1. `https://gitlab.com/gitlab-com/`
-1. Allows different organizations to be isolated. Top-level groups of the same organization can interact with each other but not with groups in other organizations, providing clear boundaries for an organization, similar to a self-managed instance. Isolation should have a positive impact on performance and availability as things like user dashboards can be scoped to organizations.
-1. Allows integration with Cells. Isolating organizations makes it possible to allocate and distribute them across different Cells.
-1. Removes the need to define hierarchies. An organization is a container that could be filled with whatever hierarchy/entity set makes sense (organization, top-level groups, etc.)
-1. Enables centralized control of user profiles. With an organization-specific user profile, administrators can control the user's role in a company, enforce user emails, or show a graphical indicator that a user as part of the organization. An example could be adding a "GitLab employee" stamp on comments.
-1. Organizations bring an on-premise-like experience to SaaS (GitLab.com). The organization admin will have access to instance-equivalent Admin Area settings with most of the configuration controlled on organization level.
+1. Allows different Organizations to be isolated. Top-level groups of the same Organization can interact with each other but not with groups in other Organizations, providing clear boundaries for an Organization, similar to a self-managed instance. Isolation should have a positive impact on performance and availability as things like user dashboards can be scoped to Organizations.
+1. Allows integration with Cells. Isolating Organizations makes it possible to allocate and distribute them across different Cells.
+1. Removes the need to define hierarchies. An Organization is a container that could be filled with whatever hierarchy/entity set makes sense (Organization, top-level groups, etc.)
+1. Enables centralized control of user profiles. With an Organization-specific user profile, administrators can control the user's role in a company, enforce user emails, or show a graphical indicator that a user as part of the Organization. An example could be adding a "GitLab employee" stamp on comments.
+1. Organizations bring an on-premise-like experience to SaaS (GitLab.com). The Organization admin will have access to instance-equivalent Admin Area settings with most of the configuration controlled on Organization level.
 
 ## Motivation
 
 ### Goals
 
-The Organization focuses on creating a better experience for organizations to manage their GitLab experience. By introducing Organizations and [Cells](../cells/index.md) we can improve the reliability, performance and availability of our SaaS Platforms.
+The Organization focuses on creating a better experience for Organizations to manage their GitLab experience. By introducing Organizations and [Cells](../cells/index.md) we can improve the reliability, performance and availability of our SaaS Platforms.
 
 - Wider audience: Many instance-level features are admin only. We do not want to lock out users of GitLab.com in that way. We want to make administrative capabilities that previously only existed for self-managed users available to our SaaS users as well. This also means we would give users of GitLab.com more independence from GitLab.com admins in the long run. Today, there are actions that self-managed admins can perform that GitLab.com users have to request from GitLab.com admins.
-- Improved UX: Inconsistencies between the features available at the project and group levels create navigation and usability issues. Moreover, there isn't a dedicated place for organization-level features.
-- Aggregation: Data from all groups and projects in an organization can be aggregated.
-- An organization includes settings, data, and features from all groups and projects under the same owner (including personal namespaces).
-- Cascading behavior: Organization cascades behavior to all the projects and groups that are owned by the same organization. It can be decided at the organization level whether a setting can be overridden or not on the levels beneath.
+- Improved UX: Inconsistencies between the features available at the project and group levels create navigation and usability issues. Moreover, there isn't a dedicated place for Organization-level features.
+- Aggregation: Data from all groups and projects in an Organization can be aggregated.
+- An Organization includes settings, data, and features from all groups and projects under the same owner (including personal namespaces).
+- Cascading behavior: Organization cascades behavior to all the projects and groups that are owned by the same Organization. It can be decided at the Organization level whether a setting can be overridden or not on the levels beneath.
 
 ### Non-Goals
 
@@ -64,29 +67,109 @@ graph TD
   ns[Namespace] -. has many .- ns[Namespace]
 ```
 
-Self-managed instances would set a default organization.
+Self-managed instances would set a default Organization.
 
 ### Benefits
 
-- No changes to URL's for groups moving under an organization, which makes moving around top-level groups very easy.
+- No changes to URL's for groups moving under an Organization, which makes moving around top-level groups very easy.
 - Low risk rollout strategy, as there is no conversion process for existing top-level groups.
 - Organization becomes the key for identifying what is part of an Organization, which is likely on its own table for performance and clarity.
 
 ### Drawbacks
 
-- It is unclear right now how we would avoid continuing to spend effort to build instance (or not Organization) features, in particular much of the reporting. This is not an issue on SaaS as top-level groups already have this capability, however it is a challenge on self-managed. If we introduce a built-in Organization (or just none at all) for self-managed, it seems like we would need to continue to build instance/organization level reporting features as we would not get that for free along with the work to add to groups.
+- It is unclear right now how we would avoid continuing to spend effort to build instance (or not Organization) features, in particular much of the reporting. This is not an issue on SaaS as top-level groups already have this capability, however it is a challenge on self-managed. If we introduce a built-in Organization (or just none at all) for self-managed, it seems like we would need to continue to build instance/Organization level reporting features as we would not get that for free along with the work to add to groups.
 - Billing may need to be moved from top-level groups to Organization level.
 
 ## Design and Implementation Details
 
+### Organization MVC
+
+The Organization MVC will contain the following functionality:
+
+- Instance setting to allow the creation of multiple Organizations. This will be enabled by default on GitLab.com, and disabled for self-managed GitLab. 
+- Every instance will have a default organization. Initially, all users will be managed by this default Organization.
+- Organization Owner. The creation of an Organization appoints that user as the Organization Owner. Once established, the Organization Owner can appoint other Organization Owners.
+- Organization users. A user is managed by one Organization, but can be part of multiple Organizations.
+- Setup settings. Containing the Organization name, ID, description, README, and avatar. Settings are editable by the Organization Owner.
+- Setup flow. Users are able to build an Organization on top of an existing top-level group. New users are able to create an Organization from scratch and to start building top-level groups from there.
+- Visibility. Options will be `public` and `private`. A nonuser of a specific Organization will not see private Organizations in the explore section. Visibility is editable by the Organization Owner.
+- Organization settings page with the added ability to remove an Organization. Deletion of the default Organization is prevented. 
+- Groups. This includes the ability to create, edit, and delete groups, as well as a Groups overview that can be accessed by the Organization Owner.
+- Projects. This includes the ability to create, edit, and delete projects, as well as a Projects overview that can be accessed by the Organization Owner.
+
+### Organization Access
+
+#### Organization Users
+
+Organization Users can get access to groups and projects as:
+
+- A group member: this grants access to the group and all its projects, regardless of their visibility.
+- A project member: this grants access to the project, and limited access to parent groups, regardless of their visibility.
+- A non-member: this grants access to public and internal groups and projects of that Organization. To access a private group or project in an Organization, a user must become a member.
+
+Organization Users can be managed by the Organization as:
+
+- Enterprise Users, managed by the Organization. This includes control over their user account and the ability to block the user.
+- Non-Enterprise Users, managed by the User. Non-Enterprise Users can be removed from an Organization, but their user account remains in their control.
+
+Enterprise Users are only available to Organizations with a Premium or Ultimate subscription. Organizations on the free tier will only be able to host Non-Enterprise Users.
+
+#### Organization Non-Users
+
+Non-users are external to the Organization and can only access the public resources of an Organization, such as public projects.
+
 ## Iteration Plan
 
-### Iteration 0: Organization MVC
+The following iteration plan outlines how we intend to arrive at the Organization MVC. We are following the guidelines for [Experiment, Beta, and Generally Available features](../../../policy/alpha-beta-support.md).
+
+### Iteration 1: Organization Prototype (FY24Q2)
+
+In iteration 1, we introduce the concept of an Organization as a way to group top-level groups together. Support for Organizations does not require any [Cells](../cells/index.md) work, but having them will make all subsequent iterations of Cells simpler. The goal of iteration 1 will be to generate a prototype that can be used by GitLab teams to test moving functionality to the Organization. It contains everything that is necessary to move an Organization to a Cell:
 
-In the first iteration, we introduce the concept of an Organization as a way to group top-level groups together. Support for Organizations does not require any [Cells](../cells/index.md) work, but having them will make all subsequent iterations of Cells simpler.
+- The Organization can be named, has an ID and an avatar.
+- Only non-enterprise user can be part of an Organization.
+- A user can be part of multiple Organizations.
+- A single Organization Owner can be assigned.
+- Groups can be created in an Organization. Groups are listed in the Groups overview.
+- Projects can be created in a Group. Projects are listed in the Projects overview.
 
-### Iteration 1
+### Iteration 2: Organization MVC Experiment (FY24Q3)
+
+In iteration 2, an Organization MVC Experiment will be released. We will test the functionality with a select set of customers and improve the MVC based on these learnings. Users will be able to build an Organization on top of their existing top-level group.
+
+- The Organization has a description and a README.
+
+### Iteration 3: Organization MVC Beta (FY24Q4)
+
+In iteration 3, the Organization MVC Beta will be released. 
+
+- Multiple Organization Owners can be assigned. 
+- Enterprise users can be added to an Organization.
+
+### Iteration 4: Organization MVC GA (FY25Q1)
+
+### Post-MVC Iterations
+
+After the initial rollout of Organizations, the following functionality will be added to address customer needs relating to their implementation of GitLab:
+
+1. Internal visibility will be made available on Organizations that are part of GitLab.com.
+1. Move billing from top-level group to Organization.
+1. Audit events at the Organization level.
+1. Set merge request approval rules at the Organization level and cascade to all groups and projects. 
+1. Security policies at the Organization level.
+1. Vulnerability reports at the Organization level.
+1. Cascading Organization setting to enforce security scans.
+1. Scan result policies at the Organization level.
+1. Compliance frameworks.
 
 ## Alternative Solutions
 
 An alternative approach to building Organizations is to convert top-level groups into Organizations. The main advantage of this approach is that features could be built on top of the namespace framework and therewith leverage functionality that is already available at the group level. We would avoid building the same feature multiple times. However, Organizations have been identified as a critical driver of Cells. Due to the urgency of delivering Cells, we decided to opt for the quickest and most straightforward solution to deliver an Organization, which is the lightweight design described above. More details on comparing the two Organization proposals can be found [here](https://gitlab.com/gitlab-org/tenant-scale-group/group-tasks/-/issues/56).
+
+## Decision Log
+
+- 2023-05-10: [Billing is not part of the Organization MVC](https://gitlab.com/gitlab-org/gitlab/-/issues/406614#note_1384055365)
+
+## Links
+
+- [Organization epic](https://gitlab.com/groups/gitlab-org/-/epics/9265)
diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md
index 82040d5990c..95a513220a2 100644
--- a/doc/ci/components/index.md
+++ b/doc/ci/components/index.md
@@ -177,7 +177,7 @@ For example, for a component repository located at `gitlab-org/dast` on `gitlab.
 - If a tag is named the same as a commit SHA that exists, like `e3262fdd0914fa823210cdb79a8c421e2cef79d8`,
   the commit SHA takes precedence over the tag.
 
-## Components catalog
+## CI/CD Catalog
 
 The CI/CD Catalog is a list of [components repositories](#components-repository),
 each containing resources that you can add to your CI/CD pipelines.
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 3f47af11380..fe57b451146 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -716,3 +716,10 @@ services:
   - name: registry.hub.docker.com/library/docker:20.10.16-dind
     alias: docker
 ```
+
+### Error response from daemon: Get "https://registry-1.docker.io/v2/": unauthorized: incorrect username or password
+
+This error appears when you use the deprecated variable, `CI_BUILD_TOKEN`. To prevent users from receiving this error, you should:
+
+- Use [CI_JOB_TOKEN](../jobs/ci_job_token.md) instead.
+- Change from `gitlab-ci-token/CI_BUILD_TOKEN` to `$CI_REGISTRY_USER/$CI_REGISTRY_PASSWORD`.
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index 0cfaf2b3fe9..8be46da3fa8 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -126,6 +126,10 @@ vacation period when most employees are out, you can set up a [Deploy Freeze](..
 During a deploy freeze period, no deployment can be executed. This is helpful to
 ensure that deployments do not happen unexpectedly.
 
+The next configured deploy freeze is displayed at the top of the
+[environment deployments list](index.md#view-environments-and-deployments)
+page.
+
 ## Protect production secrets
 
 Production secrets are needed to deploy successfully. For example, when deploying to the cloud,
diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md
index 3cd57ff6a6a..fa045a898fa 100644
--- a/doc/ci/jobs/job_control.md
+++ b/doc/ci/jobs/job_control.md
@@ -10,11 +10,7 @@ When a new pipeline starts, GitLab checks the pipeline configuration to determin
 which jobs should run in that pipeline. You can configure jobs to run depending on
 factors like the status of variables, or the pipeline type.
 
-To configure a job to be included or excluded from certain pipelines, you can use:
-
-- [`rules`](../yaml/index.md#rules)
-- [`only`](../yaml/index.md#only--except)
-- [`except`](../yaml/index.md#only--except)
+To configure a job to be included or excluded from certain pipelines, use [`rules`](../yaml/index.md#rules).
 
 Use [`needs`](../yaml/index.md#needs) to configure a job to run as soon as the
 earlier jobs it depends on finish running.
diff --git a/doc/development/logging.md b/doc/development/logging.md
index 084bad70b90..908fa16d3f8 100644
--- a/doc/development/logging.md
+++ b/doc/development/logging.md
@@ -87,6 +87,28 @@ importer progresses. Here's what to do:
       end
       ```
 
+      Note that by default, `Gitlab::JsonLogger` will include application context metadata in the log entry. If your
+      logger is expected to be called outside of an application request (for example, in a `rake` task) or by low-level
+      code that may be involved in building the application context (for example, database connection code), you should
+      call the class method `exclude_context!` for your logger class, like so:
+
+      ```ruby
+      module Gitlab
+        module Database
+          module LoadBalancing
+            class Logger < ::Gitlab::JsonLogger
+              exclude_context!
+
+              def self.file_name_noext
+                'database_load_balancing'
+              end
+            end
+          end
+        end
+      end
+
+      ```
+
    1. In your class where you want to log, you might initialize the logger as an instance variable:
 
       ```ruby
diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md
index a5345527203..8261330223d 100644
--- a/doc/development/rake_tasks.md
+++ b/doc/development/rake_tasks.md
@@ -424,7 +424,7 @@ a file for quick reference.
 
 ## Show obsolete `ignored_columns`
 
-To see a list of all obsolete `ignored_columns` run:
+To see a list of all obsolete `ignored_columns` definitions run:
 
 ```shell
 bundle exec rake db:obsolete_ignored_columns
diff --git a/doc/install/installation.md b/doc/install/installation.md
index a8e498674a6..28aa37f0d1b 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -291,7 +291,7 @@ sudo adduser --disabled-login --gecos 'GitLab' git
 ## 7. Database
 
 NOTE:
-In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 14.0 and later, we [require PostgreSQL 12+](requirements.md#postgresql-requirements).
+In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later, we [require PostgreSQL 13+](requirements.md#postgresql-requirements).
 
 1. Install the database packages.
 
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 8d779ec978d..7fdbdfc2b24 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -89,7 +89,7 @@ the following table) as these were used for development and testing:
 | 13.0           | 11                         |
 | 14.0           | 12.7                      |
 | 15.0           | 12.10                      |
-| 16.0 (planned) | 13.6                       |
+| 16.0           | 13.6                       |
 
 You must also ensure the following extensions are loaded into every
 GitLab database. [Read more about this requirement, and troubleshooting](postgresql_extensions.md).
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 9d82bbafe88..18303a5f45c 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -665,11 +665,20 @@ You may need to reconfigure or restart GitLab for the changes to take effect.
 
 1. Clear all the tokens for pending jobs:
 
+   For GitLab 15.3 and earlier:
+
    ```sql
    -- Clear build tokens
    UPDATE ci_builds SET token = null, token_encrypted = null;
    ```
 
+   For GitLab 15.4 and later:
+
+   ```sql
+   -- Clear build tokens
+   UPDATE ci_builds SET token_encrypted = null;
+   ```
+
 A similar strategy can be employed for the remaining features. By removing the
 data that can't be decrypted, GitLab can be returned to operation, and the
 lost data can be manually replaced.
diff --git a/doc/raketasks/restore_gitlab.md b/doc/raketasks/restore_gitlab.md
index c0e62187e9b..1a8a95f8b42 100644
--- a/doc/raketasks/restore_gitlab.md
+++ b/doc/raketasks/restore_gitlab.md
@@ -97,6 +97,9 @@ sudo gitlab-ctl stop sidekiq
 sudo gitlab-ctl status
 ```
 
+Next, ensure you have completed the [restore prerequisites](#restore-prerequisites) steps and have run `gitlab-ctl reconfigure`
+after copying over the GitLab secrets file from the original installation.
+
 Next, restore the backup, specifying the timestamp of the backup you wish to
 restore:
 
@@ -123,13 +126,9 @@ WARNING:
 The restore command requires [additional parameters](backup_restore.md#back-up-and-restore-for-installations-using-pgbouncer) when
 your installation is using PgBouncer, for either performance reasons or when using it with a Patroni cluster.
 
-Next, restore `/etc/gitlab/gitlab-secrets.json` if necessary,
-[as previously mentioned](#restore-prerequisites).
-
-Reconfigure, restart and [check](../administration/raketasks/maintenance.md#check-gitlab-configuration) GitLab:
+Next, restart and [check](../administration/raketasks/maintenance.md#check-gitlab-configuration) GitLab:
 
 ```shell
-sudo gitlab-ctl reconfigure
 sudo gitlab-ctl restart
 sudo gitlab-rake gitlab:check SANITIZE=true
 ```
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 5d0985ca4a1..e92bfa96a4b 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -614,6 +614,49 @@ From GitLab 17.0 and later, the methods to register runners introduced by the ne
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### `sidekiq` delivery method for `incoming_email` and `service_desk_email` is deprecated
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/398132).
+</div>
+
+The `sidekiq` delivery method for `incoming_email` and `service_desk_email` is deprecated and is
+scheduled for removal in GitLab 17.0.
+
+GitLab uses a separate process called `mail_room` to ingest emails. Currently, GitLab administrators
+can configure their GitLab instances to use `sidekiq` or `webhook` delivery methods to deliver ingested
+emails from `mail_room` to GitLab.
+
+Using the deprecated `sidekiq` delivery method, `mail_room` writes the job data directly to the GitLab
+Redis queue. This means that there is a hard coupling between the delivery method and the Redis
+configuration. Another disadvantage is that framework optimizations such as job payload compression are missed.
+
+Using the `webhook` delivery method, `mail_room` pushes the ingested email body to the GitLab
+API. That way `mail_room` does not need to know your Redis configuration and the GitLab application
+adds the processing job. `mail_room` authenticates with a shared secret key.
+
+Reconfiguring an Omnibus installation generates this secret key file automatically,
+so no secret file configuration setting is needed.
+
+You can configure a custom secret key file (32 characters base 64 encoded) by running a command
+like below and referencing the secret file in `incoming_email_secret_file` and
+`service_desk_email_secret_file` (always specify the absolute path):
+
+```shell
+echo $( ruby -rsecurerandom -e "puts SecureRandom.base64(32)" ) > ~/.gitlab-mailroom-secret
+```
+
+If you run GitLab on more than one machine, you need to provide the secret key file for each machine.
+
+We highly encourage GitLab administrators to start using the `webhook` delivery method for
+`incoming_email_delivery_method` and `service_desk_email_delivery_method` instead of `sidekiq`.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### project.pipeline.securityReportFindings GraphQL query
 
 <div class="deprecation-notes">
diff --git a/doc/update/upgrading_from_source.md b/doc/update/upgrading_from_source.md
index 8e4b6aa62db..7e2c9bf53dd 100644
--- a/doc/update/upgrading_from_source.md
+++ b/doc/update/upgrading_from_source.md
@@ -131,7 +131,7 @@ Remember to set `git -> bin_path` to `/usr/local/bin/git` in `config/gitlab.yml`
 ### 7. Update PostgreSQL
 
 WARNING:
-GitLab 14.0 requires at least PostgreSQL 12.
+GitLab 16.0 requires at least PostgreSQL 13.
 
 The latest version of GitLab might depend on a more recent PostgreSQL version
 than what you are running. You may also have to enable some
diff --git a/doc/user/analytics/value_streams_dashboard.md b/doc/user/analytics/value_streams_dashboard.md
index 771a7334c4e..384f4ce3455 100644
--- a/doc/user/analytics/value_streams_dashboard.md
+++ b/doc/user/analytics/value_streams_dashboard.md
@@ -107,10 +107,10 @@ title: 'Custom Dashboard title'
 # description - Change the description of the Value Streams Dashboard. [optional]
 description: 'Custom description'
 
-# widgets - List of widgets that contain panel settings.
+# panels - List of panels that contain panel settings.
 #   title - Change the title of the panel. [optional]
 #   data.namespace - The Group or Project path to use for the chart panel.
-widgets:
+panels:
   - title: 'My Custom Project'
     data:
       namespace: group/my-custom-project
@@ -123,10 +123,10 @@ widgets:
       namespace: group/another-group
 ```
 
-  The following example has an option configuration for a widget for the `my-group` namespace:
+  The following example has an option configuration for a panel for the `my-group` namespace:
 
   ```yaml
-  widgets:
+  panels:
     - data:
         namespace: my-group
   ```
diff --git a/doc/user/award_emojis.md b/doc/user/award_emojis.md
index 919b76e930f..29ca6fe8d98 100644
--- a/doc/user/award_emojis.md
+++ b/doc/user/award_emojis.md
@@ -6,9 +6,18 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Award emojis **(FREE)**
 
+> Awarding emojis to work items (such as tasks, objectives, and key results) [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/393599) in GitLab 16.0.
+
 When you're collaborating online, you get fewer opportunities for high-fives
-and thumbs-ups. Emojis can be awarded to [issues](project/issues/index.md), [merge requests](project/merge_requests/index.md),
-[snippets](snippets.md), and anywhere you can have a thread.
+and thumbs-ups. Add award emojis to:
+
+- [Issues](project/issues/index.md).
+- [Tasks](tasks.md).
+- [Merge requests](project/merge_requests/index.md),
+[snippets](snippets.md).
+- [Epics](../user/group/epics/index.md).
+- [Objectives and key results](okrs.md).
+- Anywhere else you can have a comment thread.
 
 ![Award emoji](img/award_emoji_select_v14_6.png)
 
diff --git a/doc/user/group/access_and_permissions.md b/doc/user/group/access_and_permissions.md
index 5092779b63d..50506d005b0 100644
--- a/doc/user/group/access_and_permissions.md
+++ b/doc/user/group/access_and_permissions.md
@@ -37,12 +37,8 @@ The group's new subgroups have push rules set for them based on either:
 
 ## Restrict Git access protocols
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/365601) in GitLab 15.1 [with a flag](../../administration/feature_flags.md) named `group_level_git_protocol_control`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to
-[enable the feature flag](../../administration/feature_flags.md) named `group_level_git_protocol_control`. On GitLab.com,
-this feature is available.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/365601) in GitLab 15.1.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/365357) in GitLab 16.0.
 
 You can set the permitted protocols used to access a group's repositories to either SSH, HTTPS, or both. This setting
 is disabled when the [instance setting](../admin_area/settings/visibility_and_access_controls.md#configure-enabled-git-access-protocols) is
diff --git a/doc/user/img/todos_add_okrs_v16_0.png b/doc/user/img/todos_add_okrs_v16_0.png
new file mode 100644
index 00000000000..45c04e647e2
--- /dev/null
+++ b/doc/user/img/todos_add_okrs_v16_0.png
diff --git a/doc/user/img/todos_mark_done_okrs_v16_0.png b/doc/user/img/todos_mark_done_okrs_v16_0.png
new file mode 100644
index 00000000000..545b3569ed5
--- /dev/null
+++ b/doc/user/img/todos_mark_done_okrs_v16_0.png
diff --git a/doc/user/project/git_attributes.md b/doc/user/project/git_attributes.md
index 034fc1dc079..698b888a32a 100644
--- a/doc/user/project/git_attributes.md
+++ b/doc/user/project/git_attributes.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Git Attributes **(FREE)**
+# Git attributes **(FREE)**
 
 GitLab supports defining custom [Git attributes](https://git-scm.com/docs/gitattributes) such as what
 files to treat as binary, and what language to use for syntax highlighting
@@ -14,13 +14,13 @@ diffs.
 To define these attributes, create a file called `.gitattributes` in the root
 directory of your repository and push it to the default branch of your project.
 
-## Encoding Requirements
+## Encoding requirements
 
 The `.gitattributes` file _must_ be encoded in UTF-8 and _must not_ contain a
 Byte Order Mark. If a different encoding is used, the file's contents are
 ignored.
 
-## Support for Mixed File Encodings
+## Support for mixed file encodings
 
 GitLab attempts to detect the encoding of files automatically, but defaults to UTF-8 unless
 the detector is confident of a different type (such as `ISO-8859-1`). Incorrect encoding
@@ -47,8 +47,8 @@ be performed for the whole repository by running `git add --renormalize .`.
 
 For more information, see [working-tree-encoding](https://git-scm.com/docs/gitattributes#_working_tree_encoding).
 
-## Syntax Highlighting
+## Syntax highlighting
 
 The `.gitattributes` file can be used to define which language to use when
-syntax highlighting files and diffs. See
-["Syntax Highlighting"](highlighting.md) for more information.
+syntax highlighting files and diffs. For more information, see
+[Syntax highlighting](highlighting.md).
diff --git a/doc/user/project/merge_requests/approvals/index.md b/doc/user/project/merge_requests/approvals/index.md
index 6b50aaf1128..717358df9f3 100644
--- a/doc/user/project/merge_requests/approvals/index.md
+++ b/doc/user/project/merge_requests/approvals/index.md
@@ -109,12 +109,11 @@ Without the approvals, the work cannot merge. Required approvals enable multiple
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/334698) in GitLab 15.1.
 > - [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/389905) in GitLab 15.11 [with a flag](../../../../administration/feature_flags.md) named `invalid_scan_result_policy_prevents_merge`. Disabled by default.
-> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/405023) in GitLab 16.0.
 
 FLAG:
-On self-managed GitLab, by default this feature is available. To hide the feature,
-ask an administrator to [disable the feature flag](../../../../administration/feature_flags.md) named `invalid_scan_result_policy_prevents_merge`.
-On GitLab.com, this feature is enabled by default.
+On self-managed GitLab, by default this feature is not available. To make it available per project or for your entire instance,
+ask an administrator to [enable the feature flag](../../../../administration/feature_flags.md) named `invalid_scan_result_policy_prevents_merge`.
+On GitLab.com, this feature is available but can be configured by GitLab.com administrators only.
 
 Whenever an approval rule cannot be satisfied, the rule is displayed as **(!) Auto approved**. This applies to the following conditions:
 
diff --git a/doc/user/todos.md b/doc/user/todos.md
index 29fe3336ea2..b05e968dd11 100644
--- a/doc/user/todos.md
+++ b/doc/user/todos.md
@@ -81,6 +81,8 @@ When you enable this feature:
 
 ## Create a to-do item
 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390549) in objectives, key results and, tasks in GitLab 16.0.
+
 You can manually add an item to your To-Do List.
 
 1. Go to your:
@@ -90,11 +92,15 @@ You can manually add an item to your To-Do List.
    - [Epic](group/epics/index.md)
    - [Design](project/issues/design_management.md)
    - [Incident](../operations/incident_management/incidents.md)
+   - [Objective or key result](../user/okrs.md)
+   - [Task](tasks.md)
 
-1. On the right sidebar, at the top, select **Add a to do**.
+1. In the upper-right corner, select  **Add a to do** (**{todo-add}**).
 
    ![Adding a to-do item from the issuable sidebar](img/todos_add_todo_sidebar_v14_1.png)
 
+   ![Adding a to-do item from the Objective and Key results](img/todos_add_okrs_v16_0.png)
+
 ## Create a to-do item by mentioning someone
 
 You can create a to-do item by mentioning someone anywhere except for a code block. Mentioning a user many times in one message only creates one to-do item.
@@ -150,10 +156,12 @@ You can manually mark a to-do item as done.
 There are two ways to do this:
 
 - In the To-Do List, to the right of the to-do item, select **Mark as done** (**{check}**).
-- In the sidebar of an issue, merge request, or epic, select **Mark as done**.
+- In the upper-right corner of the resource (for example, issue or merge request), select **Mark as done** (**{todo-done}**).
 
   ![Mark as done from the sidebar](img/todos_mark_done_sidebar_v14_1.png)
 
+  ![Mark as done from the Objectives and Key results](img/todos_mark_done_okrs_v16_0.png)
+
 ## Mark all to-do items as done
 
 You can mark all your to-do items as done at the same time.