Add latest changes from gitlab-org/gitlab@master

11 files changed, 158 insertions, 130 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 9d51be5ebf4..a600a4d7501 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -357,6 +357,8 @@ The following user actions on a GitLab instance generate instance audit events:
 - Enabled Admin Mode. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/362101) in GitLab 15.7.
 - All [group events](#group-events) and [project events](#project-events).
 - User was unblocked using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115727) in GitLab 15.11.
+- User was banned using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116103) in GitLab 15.11.
+- User was unbanned using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116221) in GitLab 15.11.
 
 Instance events can also be accessed using the [Instance Audit Events API](../api/audit_events.md#instance-audit-events).
 
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 4b3d2a1dda5..cabf55d96ca 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -15484,11 +15484,11 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 | ---- | ---- | ----------- |
 | <a id="groupvaluestreamanalyticsflowmetricscycletimeassigneeusernames"></a>`assigneeUsernames` | [`[String!]`](#string) | Usernames of users assigned to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricscycletimeauthorusername"></a>`authorUsername` | [`String`](#string) | Username of the author of the issue. |
-| <a id="groupvaluestreamanalyticsflowmetricscycletimefrom"></a>`from` | [`Time!`](#time) | Issues created after the date. |
+| <a id="groupvaluestreamanalyticsflowmetricscycletimefrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="groupvaluestreamanalyticsflowmetricscycletimelabelnames"></a>`labelNames` | [`[String!]`](#string) | Labels applied to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricscycletimemilestonetitle"></a>`milestoneTitle` | [`String`](#string) | Milestone applied to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricscycletimeprojectids"></a>`projectIds` | [`[ID!]`](#id) | Project IDs within the group hierarchy. |
-| <a id="groupvaluestreamanalyticsflowmetricscycletimeto"></a>`to` | [`Time!`](#time) | Issues created before the date. |
+| <a id="groupvaluestreamanalyticsflowmetricscycletimeto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ##### `GroupValueStreamAnalyticsFlowMetrics.deploymentCount`
 
@@ -15500,9 +15500,9 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="groupvaluestreamanalyticsflowmetricsdeploymentcountfrom"></a>`from` | [`Time!`](#time) | Deployments finished after the date. |
+| <a id="groupvaluestreamanalyticsflowmetricsdeploymentcountfrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="groupvaluestreamanalyticsflowmetricsdeploymentcountprojectids"></a>`projectIds` | [`[ID!]`](#id) | Project IDs within the group hierarchy. |
-| <a id="groupvaluestreamanalyticsflowmetricsdeploymentcountto"></a>`to` | [`Time!`](#time) | Deployments finished before the date. |
+| <a id="groupvaluestreamanalyticsflowmetricsdeploymentcountto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ##### `GroupValueStreamAnalyticsFlowMetrics.issueCount`
 
@@ -15516,11 +15516,11 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 | ---- | ---- | ----------- |
 | <a id="groupvaluestreamanalyticsflowmetricsissuecountassigneeusernames"></a>`assigneeUsernames` | [`[String!]`](#string) | Usernames of users assigned to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricsissuecountauthorusername"></a>`authorUsername` | [`String`](#string) | Username of the author of the issue. |
-| <a id="groupvaluestreamanalyticsflowmetricsissuecountfrom"></a>`from` | [`Time!`](#time) | Issues created after the date. |
+| <a id="groupvaluestreamanalyticsflowmetricsissuecountfrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="groupvaluestreamanalyticsflowmetricsissuecountlabelnames"></a>`labelNames` | [`[String!]`](#string) | Labels applied to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricsissuecountmilestonetitle"></a>`milestoneTitle` | [`String`](#string) | Milestone applied to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricsissuecountprojectids"></a>`projectIds` | [`[ID!]`](#id) | Project IDs within the group hierarchy. |
-| <a id="groupvaluestreamanalyticsflowmetricsissuecountto"></a>`to` | [`Time!`](#time) | Issues created before the date. |
+| <a id="groupvaluestreamanalyticsflowmetricsissuecountto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ##### `GroupValueStreamAnalyticsFlowMetrics.leadTime`
 
@@ -15534,11 +15534,11 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 | ---- | ---- | ----------- |
 | <a id="groupvaluestreamanalyticsflowmetricsleadtimeassigneeusernames"></a>`assigneeUsernames` | [`[String!]`](#string) | Usernames of users assigned to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricsleadtimeauthorusername"></a>`authorUsername` | [`String`](#string) | Username of the author of the issue. |
-| <a id="groupvaluestreamanalyticsflowmetricsleadtimefrom"></a>`from` | [`Time!`](#time) | Issues created after the date. |
+| <a id="groupvaluestreamanalyticsflowmetricsleadtimefrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="groupvaluestreamanalyticsflowmetricsleadtimelabelnames"></a>`labelNames` | [`[String!]`](#string) | Labels applied to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricsleadtimemilestonetitle"></a>`milestoneTitle` | [`String`](#string) | Milestone applied to the issue. |
 | <a id="groupvaluestreamanalyticsflowmetricsleadtimeprojectids"></a>`projectIds` | [`[ID!]`](#id) | Project IDs within the group hierarchy. |
-| <a id="groupvaluestreamanalyticsflowmetricsleadtimeto"></a>`to` | [`Time!`](#time) | Issues created before the date. |
+| <a id="groupvaluestreamanalyticsflowmetricsleadtimeto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ### `GroupWikiRepositoryRegistry`
 
@@ -19985,10 +19985,10 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 | ---- | ---- | ----------- |
 | <a id="projectvaluestreamanalyticsflowmetricscycletimeassigneeusernames"></a>`assigneeUsernames` | [`[String!]`](#string) | Usernames of users assigned to the issue. |
 | <a id="projectvaluestreamanalyticsflowmetricscycletimeauthorusername"></a>`authorUsername` | [`String`](#string) | Username of the author of the issue. |
-| <a id="projectvaluestreamanalyticsflowmetricscycletimefrom"></a>`from` | [`Time!`](#time) | Issues created after the date. |
+| <a id="projectvaluestreamanalyticsflowmetricscycletimefrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="projectvaluestreamanalyticsflowmetricscycletimelabelnames"></a>`labelNames` | [`[String!]`](#string) | Labels applied to the issue. |
 | <a id="projectvaluestreamanalyticsflowmetricscycletimemilestonetitle"></a>`milestoneTitle` | [`String`](#string) | Milestone applied to the issue. |
-| <a id="projectvaluestreamanalyticsflowmetricscycletimeto"></a>`to` | [`Time!`](#time) | Issues created before the date. |
+| <a id="projectvaluestreamanalyticsflowmetricscycletimeto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ##### `ProjectValueStreamAnalyticsFlowMetrics.deploymentCount`
 
@@ -20000,8 +20000,8 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="projectvaluestreamanalyticsflowmetricsdeploymentcountfrom"></a>`from` | [`Time!`](#time) | Deployments finished after the date. |
-| <a id="projectvaluestreamanalyticsflowmetricsdeploymentcountto"></a>`to` | [`Time!`](#time) | Deployments finished before the date. |
+| <a id="projectvaluestreamanalyticsflowmetricsdeploymentcountfrom"></a>`from` | [`Time!`](#time) | After the date. |
+| <a id="projectvaluestreamanalyticsflowmetricsdeploymentcountto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ##### `ProjectValueStreamAnalyticsFlowMetrics.issueCount`
 
@@ -20015,10 +20015,10 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 | ---- | ---- | ----------- |
 | <a id="projectvaluestreamanalyticsflowmetricsissuecountassigneeusernames"></a>`assigneeUsernames` | [`[String!]`](#string) | Usernames of users assigned to the issue. |
 | <a id="projectvaluestreamanalyticsflowmetricsissuecountauthorusername"></a>`authorUsername` | [`String`](#string) | Username of the author of the issue. |
-| <a id="projectvaluestreamanalyticsflowmetricsissuecountfrom"></a>`from` | [`Time!`](#time) | Issues created after the date. |
+| <a id="projectvaluestreamanalyticsflowmetricsissuecountfrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="projectvaluestreamanalyticsflowmetricsissuecountlabelnames"></a>`labelNames` | [`[String!]`](#string) | Labels applied to the issue. |
 | <a id="projectvaluestreamanalyticsflowmetricsissuecountmilestonetitle"></a>`milestoneTitle` | [`String`](#string) | Milestone applied to the issue. |
-| <a id="projectvaluestreamanalyticsflowmetricsissuecountto"></a>`to` | [`Time!`](#time) | Issues created before the date. |
+| <a id="projectvaluestreamanalyticsflowmetricsissuecountto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ##### `ProjectValueStreamAnalyticsFlowMetrics.leadTime`
 
@@ -20032,10 +20032,10 @@ Returns [`ValueStreamAnalyticsMetric`](#valuestreamanalyticsmetric).
 | ---- | ---- | ----------- |
 | <a id="projectvaluestreamanalyticsflowmetricsleadtimeassigneeusernames"></a>`assigneeUsernames` | [`[String!]`](#string) | Usernames of users assigned to the issue. |
 | <a id="projectvaluestreamanalyticsflowmetricsleadtimeauthorusername"></a>`authorUsername` | [`String`](#string) | Username of the author of the issue. |
-| <a id="projectvaluestreamanalyticsflowmetricsleadtimefrom"></a>`from` | [`Time!`](#time) | Issues created after the date. |
+| <a id="projectvaluestreamanalyticsflowmetricsleadtimefrom"></a>`from` | [`Time!`](#time) | After the date. |
 | <a id="projectvaluestreamanalyticsflowmetricsleadtimelabelnames"></a>`labelNames` | [`[String!]`](#string) | Labels applied to the issue. |
 | <a id="projectvaluestreamanalyticsflowmetricsleadtimemilestonetitle"></a>`milestoneTitle` | [`String`](#string) | Milestone applied to the issue. |
-| <a id="projectvaluestreamanalyticsflowmetricsleadtimeto"></a>`to` | [`Time!`](#time) | Issues created before the date. |
+| <a id="projectvaluestreamanalyticsflowmetricsleadtimeto"></a>`to` | [`Time!`](#time) | Before the date. |
 
 ### `ProjectWikiRepositoryRegistry`
 
diff --git a/doc/architecture/blueprints/consolidating_groups_and_projects/index.md b/doc/architecture/blueprints/consolidating_groups_and_projects/index.md
index 56f46d27e8e..f5bd53627cb 100644
--- a/doc/architecture/blueprints/consolidating_groups_and_projects/index.md
+++ b/doc/architecture/blueprints/consolidating_groups_and_projects/index.md
@@ -13,10 +13,9 @@ participating-stages: []
 
 # Consolidating Groups and Projects
 
-There are numerous features that exist exclusively within groups or
-projects. The boundary between group and project features used to be clear.
-However, there is growing demand to have group features within projects, and
-project features within groups. For example, having issues in groups, and epics
+Numerous features exist exclusively within groups or projects. The boundary between group and project features used to be clear.
+However, there is growing demand to have group features in projects, and
+project features in groups. For example, having issues in groups, and epics
 in projects.
 
 The [Simplify Groups & Projects Working Group](https://about.gitlab.com/company/team/structure/working-groups/simplify-groups-and-projects/)
@@ -34,12 +33,12 @@ no established process in place. This results in the reimplementation of
 the same feature. Those implementations diverge from each other over time as
 they all live on their own. A few more problems with this approach:
 
-- Features are coupled to their container. In practice it is not straight
+- Features are coupled to their container. In practice, it is not straight
   forward to decouple a feature from its container. The degree of coupling
   varies across features.
 - Naive duplication of features will result in a more complex and fragile codebase.
 - Generalizing solutions across groups and projects may degrade system performance.
-- The range of features span across many teams, and these changes will need to
+- The range of features spans across many teams, and these changes will need to
   manage development interference.
 - The group/project hierarchy creates a natural feature hierarchy. When features
   exist across containers the feature hierarchy becomes ambiguous.
@@ -51,33 +50,33 @@ remains consistent.
 
 ### Performance
 
-Resources can only be queried in elaborate / complicated ways. This caused
+Resources can only be queried in elaborate/complicated ways. This caused
 performance issues with authorization, epics, and many other places. As an
 example, to query the projects a user has access to, the following sources need
 to be considered:
 
-- personal projects
-- direct group membership
-- direct project membership
-- inherited group membership
-- inherited project membership
-- group sharing
-- inherited membership via group sharing
-- project sharing
+- Personal projects
+- Direct group membership
+- Direct project membership
+- Inherited group membership
+- Inherited project membership
+- Group sharing
+- Inherited membership via group sharing
+- Project sharing
 
-Group / project membership, group / project sharing are also examples of
+Group/project membership, group/project sharing are also examples of
 duplicated features.
 
 ## Goals
 
-For now this blueprint strictly relates to the engineering challenges.
+For now, this blueprint strictly relates to the engineering challenges.
 
 - Consolidate the group and project container architecture.
 - Develop a set of solutions to decouple features from their container.
 - Decouple engineering changes from product changes.
 - Develop a strategy to make architectural changes without adversely affecting
   other teams.
-- Provide a solution for requests asking for features availability of other levels.
+- Provide a solution for requests asking for features to be made available at other levels.
 
 ## Proposal
 
@@ -105,9 +104,9 @@ New features should be implemented on `Namespace`. Similarly, when a feature
 need to be reimplemented on a different level, moving it to `Namespace`
 essentially makes it available on all levels:
 
-- personal namespaces
-- groups
-- projects
+- Personal namespaces
+- Groups
+- Projects
 
 Various traversal queries are already available on `Namespaces` to query the
 group hierarchy. `Projects` represent the leaf nodes in the hierarchy, but with
@@ -116,14 +115,14 @@ retrieve projects as well.
 
 This also enables further simplification of some of our core features:
 
-- routes should be generated based on the `Namespace` hierarchy, instead of
-  mixing project with the group hierarchy.
-- there is no need to differentiate between `GroupMembers` and `ProjectMembers`.
+- Routes should be generated based on the `Namespace` hierarchy, instead of
+  mixing the project with the group hierarchy.
+- There is no need to differentiate between `GroupMembers` and `ProjectMembers`.
   All `Members` should be related to a `Namespace`. This can lead to simplified
   querying, and potentially deduplicating policies.
 
-As more and more features will be migrated to `Namespace`, the role of `Project`
-model will diminish over time to essentially a container around repository
+As more and more features will be migrated to `Namespace`, the role of the `Project`
+model will diminish over time to essentially a container around the repository
 related functionality.
 
 ## Iterations
@@ -132,9 +131,103 @@ The work required to establish `Namespace` as a container for our features is
 tracked under [Consolidate Groups and Projects](https://gitlab.com/groups/gitlab-org/-/epics/6473)
 epic.
 
+### Phase 1 (complete)
+
+- [Phase 1 epic](https://gitlab.com/groups/gitlab-org/-/epics/6697).
+- **Goals**:
+  1. Ensure every project receives a corresponding record in the `namespaces`
+     table with `type='Project'`.
+  1. For user namespaces, the type changes from `NULL` to `User`.
+
+We should make sure that projects, and the project namespace, are equivalent:
+
+- **Create project:** Use Rails callbacks to ensure a new project namespace is
+  created for each project. Project namespace records should contain `created_at` and
+  `updated_at` attributes equal to the project's `created_at`/`updated_at` attributes.
+- **Update project:** Use the `after_save` callback in Rails to ensure some
+  attributes are kept in sync between project and project namespaces.
+  Read [`project#after_save`](https://gitlab.com/gitlab-org/gitlab/blob/6d26634e864d7b748dda0e283eb2477362263bc3/app/models/project.rb#L101-L101)
+  for more information.
+- **Delete project:** Use FKs cascade delete or Rails callbacks to ensure when a `Project`
+  or its `ProjectNamespace` is removed, its corresponding `ProjectNamespace` or `Project`
+  is also removed.
+- **Transfer project to a different group:** Make sure that when a project is transferred,
+  its corresponding project namespace is transferred to the same group.
+- **Transfer group:** Make sure when transferring a group that all of its sub-projects,
+  either direct or through descendant groups, have their corresponding project
+  namespaces transferred correctly as well.
+- **Export or import project**
+  - **Export project** continues to export only the project, and not its project namespace,
+    in this phase. The project namespace does not contain any specific information
+    to export at this point. Eventually, we want the project namespace to be exported as well.
+  - **Import project** creates a new project, so the project namespace is created through
+    Rails `after_save` callback on the project model.
+- **Export or import group:** When importing or exporting a `Group`, projects are not
+  included in the operation. If that feature is changed to include `Project` when its group is
+  imported or exported, the logic must include their corresponding project namespaces
+  in the import or export.
+
+After ensuring these points, run a database migration to create a `ProjectNamespace`
+record for every `Project`. Project namespace records created during the migration
+should have `created_at` and `updated_at` attributes set to the migration runtime.
+The project namespaces' `created_at` and `updated_at` attributes would not match
+their corresponding project's `created_at` and `updated_at` attributes. We want
+the different dates to help audit any of the created project namespaces, in case we need it.
+After this work completes, we must migrate data as described in
+[Backfill `ProjectNamespace` for every Project](https://gitlab.com/gitlab-org/gitlab/-/issues/337100).
+
+### Phase 2 (complete)
+
+- [Phase 2 epic](https://gitlab.com/groups/gitlab-org/-/epics/6768).
+- **Goal**: Link `ProjectNamespace` to other entities on the database level.
+
+In this phase:
+
+- Communicate the changes company-wide at the engineering level. We want to make
+  engineers aware of the upcoming changes, even though teams are not expected to
+  collaborate actively until phase 3.
+- Raise awareness to avoid regressions and conflicting or duplicate work that
+  can be dealt with before phase 3.
+
+### Phase 3 (ongoing)
+
+- [Phase 3 epic](https://gitlab.com/groups/gitlab-org/-/epics/6585).
+
+In this phase we are migrating basic, high-priority project functionality from `Project` to `ProjectNamespace`, or directly to `Namespace`. Problems to solve as part of this phase:
+
+- [Unify members/members actions](https://gitlab.com/groups/gitlab-org/-/epics/8010) - on UI and API level.
+- Starring: Right now only projects can be starred. We want to bring this to the group level.
+- Common actions: Destroying, transferring, restoring. This can be unified on the controller level and then propagated lower.
+- Archiving currently only works on the project level. This can be brought to the group level, similar to the mechanism for “pending deletion”.
+- Avatar's serving and actions.
+
+### Phase 4
+
+- [Phase 4 epic](https://gitlab.com/groups/gitlab-org/-/epics/8687)
+
+In this phase we are migrating additional functionality from `Project` to `ProjectNamespace`/`Namespace`:
+
+- Replace usages of `Project` with `ProjectNamespace` in the code.
+- API changes to expose namespaces and namespace features.
+  - Investigate if we extend API for `groups` or we introduce a `namespaces` endpoint and slowly deprecate `groups` and `projects` endpoints.
+- Break down each feature that needs to be migrated from `Project` to `ProjectNamespace` or `Namespace`.
+  - Investigate if we can move a feature from `Project -> Namespace` directly vs `Project -> ProjectNamespace -> Namespace`. This can be decided on a feature by feature case.
+- [Migrate Project#namespace to reference ProjectNamespace](https://gitlab.com/groups/gitlab-org/-/epics/6581).
+- [Routes consolidation between Project & ProjectNamespace](https://gitlab.com/gitlab-org/gitlab/-/issues/337103).
+- [Policies consolidation](https://gitlab.com/groups/gitlab-org/-/epics/6689).
+
+### Phase 5
+
+- [Phase 5 epic](https://gitlab.com/groups/gitlab-org/-/epics/6944)
+
+We should strive to do the code clean up as we move through the phases. However, not everything can be cleaned up while something is still being developed. For example, dropping database columns can be done as the last task when we are sure everything is working. This phase will focus on:
+
+- Code cleanup
+- Database cleanup
+
 ## Migrating features to Namespaces
 
-The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider a number of factors when migrating their features over to `Namespaces`:
+The initial iteration will provide a framework to house features under `Namespaces`. Stage groups will eventually need to migrate their own features and functionality over to `Namespaces`. This may impact these features in unexpected ways. Therefore, to minimize UX debt and maintain product consistency, stage groups will have to consider several factors when migrating their features over to `Namespaces`:
 
 1. **Conceptual model**: What are the current and future state conceptual models of these features ([see object modeling for designers](https://hpadkisson.medium.com/object-modeling-for-designers-an-introduction-7871bdcf8baf))? These should be documented in Pajamas (example: [merge requests](https://design.gitlab.com/objects/merge-request/)).
 1. **Merge conflicts**: What inconsistencies are there across project, group, and administrator levels? How might these be addressed? For an example of how we rationalized this for labels, please see [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338820).
@@ -151,3 +244,4 @@ The initial iteration will provide a framework to house features under `Namespac
 ## Related topics
 
 - [Organization developer documentation](../../../development/organization/index.md)
+- [Organization user documentation](../../../user/organization/index.md)
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 7a9c3572406..d1e16b7f137 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -558,7 +558,7 @@ GitLab CI/CD is the open-source continuous integration service included with Git
 
 #### GitLab Workhorse
 
-- [Project page](https://gitlab.com/gitlab-org/gitlab-workhorse/blob/master/README.md)
+- [Project page](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/workhorse/index.md)
 - Configuration:
   - [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template)
   - [Charts](https://docs.gitlab.com/charts/charts/gitlab/webservice/)
@@ -567,7 +567,7 @@ GitLab CI/CD is the open-source continuous integration service included with Git
 - Process: `gitlab-workhorse`
 - GitLab.com: [Service Architecture](https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/#service-architecture)
 
-[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alleviate pressure from Puma. You can read more about the [historical reasons for developing](https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole.
+[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/workhorse) is a program designed at GitLab to help alleviate pressure from Puma. You can read more about the [historical reasons for developing](https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole.
 
 #### Grafana
 
diff --git a/doc/development/organization/index.md b/doc/development/organization/index.md
index ef016c2d603..3a23e50caf9 100644
--- a/doc/development/organization/index.md
+++ b/doc/development/organization/index.md
@@ -38,87 +38,14 @@ A solution for this problem is to consolidate groups and projects into a single
 entity, `namespace`. The work on this solution is split into several phases and
 is tracked in [epic 6473](https://gitlab.com/groups/gitlab-org/-/epics/6473).
 
-### Phase 1
-
-- [Phase 1 epic](https://gitlab.com/groups/gitlab-org/-/epics/6697).
-- **Goals**:
-  1. Ensure every project receives a corresponding record in the `namespaces`
-     table with `type='Project'`.
-  1. For user namespaces, the type changes from `NULL` to `User`.
-
-We should make sure that projects, and the project namespace, are equivalent:
-
-- **Create project:** use Rails callbacks to ensure a new project namespace is
-  created for each project. Project namespace records should contain `created_at` and
-  `updated_at` attributes equal to the project's `created_at`/`updated_at` attributes.
-- **Update project:** use the `after_save` callback in Rails to ensure some
-  attributes are kept in sync between project and project namespaces.
-  Read [`project#after_save`](https://gitlab.com/gitlab-org/gitlab/blob/6d26634e864d7b748dda0e283eb2477362263bc3/app/models/project.rb#L101-L101)
-  for more information.
-- **Delete project:** use FKs cascade delete or Rails callbacks to ensure when a `Project`
-  or its `ProjectNamespace` is removed, its corresponding `ProjectNamespace` or `Project`
-  is also removed.
-- **Transfer project to a different group:** make sure that when a project is transferred,
-  its corresponding project namespace is transferred to the same group.
-- **Transfer group:** make sure when transferring a group that all of its sub-projects,
-  either direct or through descendant groups, have their corresponding project
-  namespaces transferred correctly as well.
-- **Export or import project**
-  - **Export project** continues to export only the project, and not its project namespace,
-    in this phase. The project namespace does not contain any specific information
-    to export at this point. Eventually we want the project namespace to be exported as well.
-  - **Import project** creates a new project, so the project namespace is created through
-    Rails `after_save` callback on the project model.
-- **Export or import group:** when importing or exporting a `Group`, projects are not
-  included in the operation. If that feature is changed to include `Project` when its group is
-  imported or exported, the logic must include their corresponding project namespaces
-  in the import or export.
-
-After ensuring these points, run a database migration to create a `ProjectNamespace`
-record for every `Project`. Project namespace records created during the migration
-should have `created_at` and `updated_at` attributes set to the migration runtime.
-The project namespaces' `created_at` and `updated_at` attributes would not match
-their corresponding project's `created_at` and `updated_at` attributes. We want
-the different dates to help audit any of the created project namespaces, in case we need it.
-After this work completes, we must migrate data as described in
-[Backfill `ProjectNamespace` for every Project](https://gitlab.com/gitlab-org/gitlab/-/issues/337100).
-
-### Phase 2
-
-- [Phase 2 epic](https://gitlab.com/groups/gitlab-org/-/epics/6768).
-- **Goal**: Link `ProjectNamespace` to other entities on the database level.
-
-In this phase:
-
-- Communicate the changes company-wide at the engineering level. We want to make
-  engineers aware of the upcoming changes, even though teams are not expected to
-  collaborate actively until phase 3.
-- Raise awareness to avoid regressions, and conflicting or duplicate work that
-  can be dealt with before phase 3.
-
-### Phase 3
-
-- [Phase 3 epic](https://gitlab.com/groups/gitlab-org/-/epics/6585).
-- **Goal**: Achieve feature parity between the namespace types.
-Problems to solve as part of this phase:
-
-- Routes handling through `ProjectNamespace` rather than `Project`.
-- Memberships handling.
-- Policies handling.
-- Import and export.
-- Other interactions between project namespace and project models.
-
-Phase 3 is when the active migration of features from `Project` to `ProjectNamespace`,
-or directly to `Namespace`, happens.
-
-### How to plan features that interact with Group and ProjectNamespace
+## How to plan features that interact with Group and ProjectNamespace
 
 As of now, every Project in the system has a record in the `namespaces` table. This makes it possible to
 use common interface to create features that are shared between Groups and Projects. Shared behavior can be added using
 a concerns mechanism. Because the `Namespace` model is responsible for `UserNamespace` methods as well, it is discouraged
 to use the `Namespace` model for shared behavior for Projects and Groups.
 
-#### Resource-based features
+### Resource-based features
 
 To migrate resource-based features, existing functionality will need to be supported. This can be achieved in two Phases.
 
@@ -140,7 +67,7 @@ To migrate resource-based features, existing functionality will need to be suppo
 
 Introducing new functionality is very much dependent on every single team and feature.
 
-#### Settings-related features
+### Settings-related features
 
 Right now, cascading settings are available for `NamespaceSettings`. By creating `ProjectNamespace`,
 we can use this framework to make sure that some settings are applicable on the project level as well.
@@ -149,7 +76,7 @@ When working on settings, we need to make sure that:
 
 - They are not used in `join` queries or modify those queries.
 - Updating settings is taken into consideration.
-- If we want to move from project to project namespace, we follow a similar database process to the one described in [Phase 1](#phase-1).
+- If we want to move from project to project namespace, we follow a similar database process to the one described in Phase 1.
 
 ## Related topics
 
diff --git a/doc/development/workhorse/index.md b/doc/development/workhorse/index.md
index 91795336f78..680dd0c205b 100644
--- a/doc/development/workhorse/index.md
+++ b/doc/development/workhorse/index.md
@@ -15,9 +15,14 @@ Workhorse itself is not a feature, but there are
 
 The canonical source for Workhorse is
 [`gitlab-org/gitlab/workhorse`](https://gitlab.com/gitlab-org/gitlab/tree/master/workhorse).
-Prior to [epic #4826](https://gitlab.com/groups/gitlab-org/-/epics/4826), it was
-[`gitlab-org/gitlab-workhorse`](https://gitlab.com/gitlab-org/gitlab-workhorse/tree/master),
-but that repository is no longer used for development.
+
+## Learning Resources
+
+- Workhorse documentation (this page)
+- [GitLab Workhorse Deep Dive: Dependency Proxy](https://www.youtube.com/watch?v=9cRd-k0TRqI) _video_
+- [How Dependency Proxy via Workhorse works](https://gitlab.com/gitlab-org/gitlab/-/issues/370235)
+- [Workhorse overview for the Dependency Proxy](https://www.youtube.com/watch?v=WmBibT9oQms)
+- [Workhorse architecture discussion](https://www.youtube.com/watch?v=QlHdh-yudtw)
 
 ## Install Workhorse
 
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 002797b386a..928e2dbe6a2 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -327,7 +327,7 @@ This table shows granted privileges for jobs triggered by specific types of user
 | Push source and LFS                          |                 |           |            |               |
 
 1. Only if the triggering user is not an external one.
-1. Only if the triggering user is a member of the project. See also [Usage of private Docker images with `if-not-present` pull policy](http://docs.gitlab.com/runner/security/index.html#usage-of-private-docker-images-with-if-not-present-pull-policy).
+1. Only if the triggering user is a member of the project. See also [Usage of private Docker images with `if-not-present` pull policy](https://docs.gitlab.com/runner/security/index.html#usage-of-private-docker-images-with-if-not-present-pull-policy).
 
 ## Group members permissions
 
diff --git a/doc/user/product_analytics/index.md b/doc/user/product_analytics/index.md
index 00e48e5d5d3..618db406ec8 100644
--- a/doc/user/product_analytics/index.md
+++ b/doc/user/product_analytics/index.md
@@ -45,7 +45,7 @@ flowchart TB
 Product Analytics uses several tools:
 
 - [**Jitsu**](https://jitsu.com/docs) - A web and app event collection platform that provides a consistent API to collect user data and pass it through to Clickhouse.
-- [**Clickhouse**](https://clickhouse.com/docs) - A database suited to store, query, and retrieve analytical data.
+- [**Clickhouse**](https://clickhouse.com/docs/) - A database suited to store, query, and retrieve analytical data.
 - [**Cube.js**](https://cube.dev/docs/) - An analytical graphing library that provides an API to run queries against the data stored in Clickhouse.
 
 ## Enable product analytics
diff --git a/doc/user/project/clusters/add_gke_clusters.md b/doc/user/project/clusters/add_gke_clusters.md
index 3a91796a7c6..c6561fffa0b 100644
--- a/doc/user/project/clusters/add_gke_clusters.md
+++ b/doc/user/project/clusters/add_gke_clusters.md
@@ -77,7 +77,7 @@ cluster certificates:
    - **Zone** - Choose the [region zone](https://cloud.google.com/compute/docs/regions-zones/)
      under which to create the cluster.
    - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
-   - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
+   - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-resource)
      of the Virtual Machine instance to base the cluster on.
    - **Enable Cloud Run for Anthos** - Check this if you want to use Cloud Run for Anthos for this cluster.
      See the [Cloud Run for Anthos section](#cloud-run-for-anthos) for more information.
diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md
index b83feda0c96..e4486938edf 100644
--- a/doc/user/project/file_lock.md
+++ b/doc/user/project/file_lock.md
@@ -58,7 +58,7 @@ git-lfs --version
 ```
 
 If it doesn't recognize this command, you must install it. There are
-several [installation methods](https://git-lfs.github.com/) that you can
+several [installation methods](https://git-lfs.com/) that you can
 choose according to your OS. To install it with Homebrew:
 
 ```shell
diff --git a/doc/user/ssh.md b/doc/user/ssh.md
index 30cae7ddab4..3ab61fa77a9 100644
--- a/doc/user/ssh.md
+++ b/doc/user/ssh.md
@@ -291,7 +291,7 @@ You can use [1Password](https://1password.com/) and the [1Password browser exten
 1. Optional. Update **Expiration date** to modify the default expiration date.
 1. Select **Add key**.
 
-For more information about using 1Password with SSH keys, see the [1Password documentation](https://developer.1password.com/docs/ssh/get-started).
+For more information about using 1Password with SSH keys, see the [1Password documentation](https://developer.1password.com/docs/ssh/get-started/).
 
 ## Add an SSH key to your GitLab account