diff --git a/doc/administration/feature_flags.md b/doc/administration/feature_flags.md
index 74f27f5f4c20358c0187c33ff7497aaee79f51c3..83d7ca9b4def6f6b656cd0520bdbccd7b512f226 100644
--- a/doc/administration/feature_flags.md
+++ b/doc/administration/feature_flags.md
@@ -16,7 +16,7 @@ to deploy features in an early stage of development so that they can be
incrementally rolled out.
Before making them permanently available, features can be deployed behind
-flags for a [number of reasons](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags), such as:
+flags for a [number of reasons](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags), such as:
- To test the feature.
- To get feedback from users and customers while in an early stage of the development of the feature.
diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md
index c1081e1b8c75a7aa5d83905c46d78909d0b0216f..f0bc6147b97d76cd14ceba45a0132c5e472af0de 100644
--- a/doc/api/project_import_export.md
+++ b/doc/api/project_import_export.md
@@ -270,7 +270,7 @@ The `Content-Type` header must be `application/gzip`.
## Import a file from AWS S3
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/348874) in GitLab 14.9 in [Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta), [with a flag](../administration/feature_flags.md) named `import_project_from_remote_file_s3`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/348874) in GitLab 14.9 in [Beta](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga), [with a flag](../administration/feature_flags.md) named `import_project_from_remote_file_s3`. Disabled by default.
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/348874) in GitLab 14.10.
> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/350571) in GitLab 15.11. Feature flag `import_project_from_remote_file_s3` removed.
diff --git a/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md b/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md
index fc35cc0dd500ad89104e548ea44dad7bd54ef78d..d28593b0f44d48d50acf523aee85a378c575800f 100644
--- a/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md
+++ b/doc/architecture/blueprints/composable_codebase_using_rails_engines/index.md
@@ -40,7 +40,7 @@ implementing separate gems in a single repository. The [Rails Engines](https://g
allowed us to well describe the individual components with its dependencies and run an application
consisting of many Rails Engines.
-The blueprint aims to retain all key aspects of GitLab success: single and monolithic codebase (with a [single data-store](https://about.gitlab.com/handbook/product/single-application/#single-data-store)),
+The blueprint aims to retain all key aspects of GitLab success: single and monolithic codebase (with a [single data-store](https://handbook.gitlab.com/handbook/product/single-application/#single-data-store)),
but allows us to better model application and make our codebase more composable.
## Challenges of the Monolith (a current state)
diff --git a/doc/architecture/blueprints/feature_flags_usage_in_dev_and_ops/index.md b/doc/architecture/blueprints/feature_flags_usage_in_dev_and_ops/index.md
index ad6dd755607608fa56707b1be82c9fc02552f511..051e04cc50d75c82451f2c6353c2273c81db4a53 100644
--- a/doc/architecture/blueprints/feature_flags_usage_in_dev_and_ops/index.md
+++ b/doc/architecture/blueprints/feature_flags_usage_in_dev_and_ops/index.md
@@ -31,7 +31,7 @@ Feature flags can be used for different purposes:
to be hidden from anyone. In that case, the feature flag allows to merge all the changes to the main branch without actually using
the feature yet.
- Beta features: We might
- [not be confident we'll be able to scale, support, and maintain a feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga)
+ [not be confident we'll be able to scale, support, and maintain a feature](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga)
in its current form for every designed use case ([example](https://gitlab.com/gitlab-org/gitlab/-/issues/336070#note_1523983444)).
There are also scenarios where a feature is not complete enough to be considered an MVC.
Providing a flag in this case allows engineers and customers to disable the new feature until it's performant enough.
diff --git a/doc/architecture/blueprints/gitlab_services/index.md b/doc/architecture/blueprints/gitlab_services/index.md
index 8acdae9f29e6e9d8b1af286bba0bb1384e400327..54229b31fa31fecfccf8c0da0b68ccba70671e4d 100644
--- a/doc/architecture/blueprints/gitlab_services/index.md
+++ b/doc/architecture/blueprints/gitlab_services/index.md
@@ -34,7 +34,7 @@ A service would connect to the SCM, registry or issues through release artifacts
a specific version of the given release artifact is deployed (or being deployed).
Having a concept of services allows our users to track their applications in production, not only in CI/CD pipelines. This opens up possibilities, like cost management.
-The current work in [Analyze:Observability](https://about.gitlab.com/handbook/product/categories/#observability-group) could be integrated into GitLab if it supports services.
+The current work in [Analyze:Observability](https://handbook.gitlab.com/handbook/product/categories/#observability-group) could be integrated into GitLab if it supports services.
### Goals
@@ -60,7 +60,7 @@ The current work in [Analyze:Observability](https://about.gitlab.com/handbook/pr
- Metrics related to a service should be customizable and configurable by project maintainers (developers?). Metrics might differ from service to service both in the query and in the meaning. (e.g. traffic does not make sense for a queue).
- Metrics should integrate with various external tools, like OpenTelemetry/Prometheus, Datadog, etc.
-- We don't want to tackle GitLab observability solution built by [Analyze:Observability](https://about.gitlab.com/handbook/product/categories/#observability-group). The proposal here should treat it as one observability integration backend.
+- We don't want to tackle GitLab observability solution built by [Analyze:Observability](https://handbook.gitlab.com/handbook/product/categories/#observability-group). The proposal here should treat it as one observability integration backend.
- We don't want to cover alerting, SLOs, SLAs and incident management.
- Some infrastructures might already have better support within GitLab than others (Kubernetes is supported better than pure AWS). There is no need to discuss functionalities that we provide or plan to provide for Kubernetes and how to achieve feature parity with other infrastructures.
- Services can be filtered by metadata (e.g. tenant, region). These could vary by customer or even by group.
@@ -110,7 +110,7 @@ and grouping it by the **name** of the environments. For example:
classDiagram
Group "1" o-- "*" Project : There may be multiple projects with services in a group
Project "1" <.. "*" Service : A service is part of a project
- Project "1" <.. "*" Environment :
+ Project "1" <.. "*" Environment :
Environment "*" .. "*" Service : A service is linked to 1+ environments
Service "1" <|-- "*" ReleaseArtifact : A release artifact packages a specific version of a service
ReleaseArtifact "1" <|-- "*" Deployment : A release artifact can be deployed
@@ -126,4 +126,3 @@ See [Glossary](https://about.gitlab.com/direction/delivery/glossary.html) for mo
- [Add dynamically populated organization-level environments page](https://gitlab.com/gitlab-org/gitlab/-/issues/241506).
This approach was concluded as no-go in favor of Service concept.
- There is an alternative proposal to introduce [Group Environment entity](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/129696#note_1557477581) for [Group-level environment views](#aggregate-environments-and-services-at-group-level).
-
\ No newline at end of file
diff --git a/doc/architecture/blueprints/modular_monolith/bounded_contexts.md b/doc/architecture/blueprints/modular_monolith/bounded_contexts.md
index 8133106050d260a99c0c024e64706aecee952535..877baba9bbddbc084b0532911d3b4b0bf148ca23 100644
--- a/doc/architecture/blueprints/modular_monolith/bounded_contexts.md
+++ b/doc/architecture/blueprints/modular_monolith/bounded_contexts.md
@@ -55,7 +55,7 @@ easier will be identifying and separating bounded context.
### 1. What makes a bounded context?
From the research in [Proposal: split GitLab monolith into components](https://gitlab.com/gitlab-org/gitlab/-/issues/365293)
-it seems that following [product categories](https://about.gitlab.com/handbook/product/categories/#hierarchy), as a guideline,
+it seems that following [product categories](https://handbook.gitlab.com/handbook/product/categories/#hierarchy), as a guideline,
would be much better than translating organization structure into folder structure (for example, `app/modules/verify/pipeline-execution/...`).
However, this guideline alone is not sufficient and we need a more specific strategy:
diff --git a/doc/architecture/blueprints/observability_tracing/index.md b/doc/architecture/blueprints/observability_tracing/index.md
index 4c95d23e6bdf97a77d44c798e7b4e21881fc9da2..0b167400188ce08429191d1b0767c43c862a2118 100644
--- a/doc/architecture/blueprints/observability_tracing/index.md
+++ b/doc/architecture/blueprints/observability_tracing/index.md
@@ -52,7 +52,7 @@ Specific goals:
## Timeline
-In order to achieve the group objectives, the following timelines must be met for [GitLab phased rollout](https://about.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga) of Tracing.
+In order to achieve the group objectives, the following timelines must be met for [GitLab phased rollout](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga) of Tracing.
- **Tracing Experiment Release**: 16.2
- **Tracing Beta Release**: 16.3
diff --git a/doc/development/adding_service_component.md b/doc/development/adding_service_component.md
index aabd65be8a7b681111e15535c45bc5f94c3efbd7..a07dcc597b25de58aa00fc6f03c5fc0568e7fa87 100644
--- a/doc/development/adding_service_component.md
+++ b/doc/development/adding_service_component.md
@@ -31,9 +31,9 @@ The following outline re-uses the [maturity metric](https://about.gitlab.com/dir
The initial step for integrating a new component with GitLab starts with creating a [Feature proposal in the issue tracker](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal).
-Identify the [product category](https://about.gitlab.com/handbook/product/categories/) the component falls under and assign the Engineering Manager and Product Manager responsible for that category.
+Identify the [product category](https://handbook.gitlab.com/handbook/product/categories/) the component falls under and assign the Engineering Manager and Product Manager responsible for that category.
-The general steps for getting any GitLab feature from proposal to release can be found in the [Product development flow](https://about.gitlab.com/handbook/product-development-flow/).
+The general steps for getting any GitLab feature from proposal to release can be found in the [Product development flow](https://handbook.gitlab.com/handbook/product-development-flow/).
## Integrating a new service with GitLab
diff --git a/doc/development/ai_features/glossary.md b/doc/development/ai_features/glossary.md
index e608a1998ade8b340fb5cbefbc1f4f4f9ddb3871..c96ef4d9aa8543e96940ebca9c408e4dc13aa6ed 100644
--- a/doc/development/ai_features/glossary.md
+++ b/doc/development/ai_features/glossary.md
@@ -56,7 +56,7 @@ to AI that you think could benefit from being in this list, add it!
learn and predict. Ground truth data is usually human-annotated.
- **Model Validation**: group within the AI-powered Stage working on the Prompt
Library and researching AI/ML models to support other use-cases for AI at GitLab.
- [Team handbook section](https://about.gitlab.com/handbook/product/categories/features/#ai-poweredai-model-validation-group).
+ [Team handbook section](https://handbook.gitlab.com/handbook/product/categories/features/#ai-powered-ai-model-validation-group).
- **Prompt library**: The ["Prompt Library"](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/prompt-library) is a Python library that provides a CLI for testing different prompting techniques with LLMs. It enables data-driven improvements to LLM applications by facilitating hypothesis testing. Key features include the ability to manage and run dataflow pipelines using Apache Beam, and the execution of multiple evaluation experiments in a single pipeline run.
on prompts with various third-party AI Services.
[Code](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/prompt-library).
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index 25a118829f8b9a9f41b7fc310655087688009dc3..cd048a5503e0820e2dffbfbbe4e6b34b77e6ed91 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -15,7 +15,7 @@ First of all, you have to gather information and decide which are the different
limits that are set for the different GitLab tiers. Coordinate with others to [document](../administration/instance_limits.md)
and communicate those limits.
-There is a guide about [introducing application limits](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits).
+There is a guide about [introducing application limits](https://handbook.gitlab.com/handbook/product/product-processes/#introducing-application-limits).
## Implement plan limits
diff --git a/doc/development/application_settings.md b/doc/development/application_settings.md
index 835fd78263331118659656c4ffee8f8f50fabfbd..a51272617e8b31262c726d68debc92d4b174ae60 100644
--- a/doc/development/application_settings.md
+++ b/doc/development/application_settings.md
@@ -14,7 +14,7 @@ Application settings are stored in the `application_settings` table. Each settin
## Add a new application setting
First of all, you have to decide if it is necessary to add an application setting.
-Consider our [configuration principles](https://about.gitlab.com/handbook/product/product-principles/#configuration-principles) when adding a new setting.
+Consider our [configuration principles](https://handbook.gitlab.com/handbook/product/product-principles/#configuration-principles) when adding a new setting.
To add a new setting, you have to:
diff --git a/doc/development/avoiding_required_stops.md b/doc/development/avoiding_required_stops.md
index 74db216a1f0c20983bdb6f5e10b838eb975bf4d0..a9ecc382d5670d469ad9c9eac9d1a92bc1b39a4d 100644
--- a/doc/development/avoiding_required_stops.md
+++ b/doc/development/avoiding_required_stops.md
@@ -32,7 +32,7 @@ Wherever possible, a required stop should be avoided. If it can't be avoided,
the required stop should be aligned to a _scheduled_ required stop.
In cases where we are considering retroactively declaring an unplanned required stop,
-contact the [Distribution team product manager](https://about.gitlab.com/handbook/product/categories/#distributionbuild-group) to advise on next steps. If there
+contact the [Distribution team product manager](https://handbook.gitlab.com/handbook/product/categories/#distributionbuild-group) to advise on next steps. If there
is uncertainty about whether we should declare a required stop, the Distribution product
manager may escalate to GitLab product leadership (VP or Chief Product Officer) to make
a final determination. This may happen, for example, if a change might require a stop for
diff --git a/doc/development/backend/create_source_code_be/index.md b/doc/development/backend/create_source_code_be/index.md
index 3ae3c9899665dba6a8e6aca7e90fcc36a3afa957..f808f021616d61b101e7558639bcfb1a571f129f 100644
--- a/doc/development/backend/create_source_code_be/index.md
+++ b/doc/development/backend/create_source_code_be/index.md
@@ -7,16 +7,16 @@ info: Any user with at least the Maintainer role can merge updates to this conte
# Source Code Management
The Source Code Management team is responsible for all backend aspects of the product categories
-that fall under the [Source Code group](https://about.gitlab.com/handbook/product/categories/#source-code-group)
-of the [Create stage](https://about.gitlab.com/handbook/product/categories/#create-stage)
-of the [DevOps lifecycle](https://about.gitlab.com/handbook/product/categories/#devops-stages).
+that fall under the [Source Code group](https://handbook.gitlab.com/handbook/product/categories/#source-code-group)
+of the [Create stage](https://handbook.gitlab.com/handbook/product/categories/#create-stage)
+of the [DevOps lifecycle](https://handbook.gitlab.com/handbook/product/categories/#devops-stages).
The Source Code Management team interfaces with the Gitaly and Code Review teams and works across three codebases: Workhorse, GitLab Shell and GitLab Rails.
## Source Code Features Reference
Features owned by the Source Code Management group are listed on the
-[Features by Group Page](https://about.gitlab.com/handbook/product/categories/features/#createsource-code-group).
+[Features by Group Page](https://handbook.gitlab.com/handbook/product/categories/features/#create-source-code-group).
### Code Owners
diff --git a/doc/development/cicd/templates.md b/doc/development/cicd/templates.md
index bd3023ebf8dae5173ed66789bb40abbee7f0db54..9f62de9bbdcdeb8076e2416d0a551be886ebc85e 100644
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@@ -459,7 +459,7 @@ To add a metric definition for a new template:
- `introduced_by_url:`: The URL of the MR adding the template.
- `data_source:`: Set to `redis_hll`.
- `description`: Add a short description of what this metric counts, for example: `Count of pipelines using the latest Auto Deploy template`
- - `product_*`: Set to [section, stage, group, and feature category](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+ - `product_*`: Set to [section, stage, group, and feature category](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)
as per the [metrics dictionary guide](../internal_analytics/metrics/metrics_dictionary.md#metrics-definition-and-validation).
If you are unsure what to use for these keywords, you can ask for help in the merge request.
- Add the following to the end of each file:
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 230d9a87e8a67cbecdc73dd8e00f4a81721a4bcc..ff8f5d8f6f258a1e9f881635dd7f1d0d5559b526 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -90,7 +90,7 @@ To find a domain expert:
- In the Merge Request approvals widget, select [View eligible approvers](../user/project/merge_requests/approvals/rules.md#eligible-approvers).
This widget shows recommended and required approvals per area of the codebase.
These rules are defined in [Code Owners](../user/project/merge_requests/approvals/rules.md#code-owners-as-eligible-approvers).
-- View the list of team members who work in the [stage or group](https://about.gitlab.com/handbook/product/categories/#devops-stages) related to the merge request.
+- View the list of team members who work in the [stage or group](https://handbook.gitlab.com/handbook/product/categories/#devops-stages) related to the merge request.
- View team members' domain expertise on the [engineering projects](https://handbook.gitlab.com/handbook/engineering/projects/) page or on the [GitLab team page](https://about.gitlab.com/company/team/). Domains are self-identified, so use your judgment to map the changes on your merge request to a domain.
- Look for team members who have contributed to the files in the merge request. View the logs by running `git log <file>`.
- Look for team members who have reviewed the files. You can find the relevant merge request by:
@@ -179,7 +179,7 @@ by a reviewer before passing it to a maintainer as described in the
| `~UX` user-facing changes <sup>3</sup> | [Product Designer](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX). Refer to the [design and user interface guidelines](contributing/design.md) for details. |
| Adding a new JavaScript library <sup>1</sup> | - [Frontend foundations member](https://about.gitlab.com/direction/manage/foundations/) if the library significantly increases the [bundle size](https://gitlab.com/gitlab-org/frontend/playground/webpack-memory-metrics/-/blob/master/doc/report.md).<br/>- A [legal department member](https://handbook.gitlab.com/handbook/legal/) if the license used by the new library hasn't been approved for use in GitLab.<br/><br/>More information about license compatibility can be found in our [GitLab Licensing and Compatibility documentation](licensing.md). |
| A new dependency or a file system change | - [Distribution team member](https://about.gitlab.com/company/team/). See how to work with the [Distribution team](https://handbook.gitlab.com/handbook/engineering/infrastructure/core-platform/systems/distribution/#how-to-work-with-distribution) for more details.<br/>- For RubyGems, request an [AppSec review](gemfile.md#request-an-appsec-review). |
-| `~documentation` or `~UI text` changes | [Technical writer](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments) based on assignments in the appropriate [DevOps stage group](https://about.gitlab.com/handbook/product/categories/#devops-stages). |
+| `~documentation` or `~UI text` changes | [Technical writer](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments) based on assignments in the appropriate [DevOps stage group](https://handbook.gitlab.com/handbook/product/categories/#devops-stages). |
| Changes to development guidelines | Follow the [review process](development_processes.md#development-guidelines-review) and get the approvals accordingly. |
| End-to-end **and** non-end-to-end changes <sup>4</sup> | [Software Engineer in Test](https://handbook.gitlab.com/handbook/engineering/quality/#individual-contributors). |
| Only End-to-end changes <sup>4</sup> **or** if the MR author is a [Software Engineer in Test](https://handbook.gitlab.com/handbook/engineering/quality/#individual-contributors) | [Quality maintainer](https://handbook.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa). |
@@ -288,7 +288,7 @@ See the [test engineering process](https://handbook.gitlab.com/handbook/engineer
1. You have considered using a feature flag for this change because the change may be high risk.
1. If you are using a feature flag, you plan to test the change in staging before you test it in production, and you have considered rolling it out to a subset of production customers before rolling it out to all customers.
- - [When to use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)
+ - [When to use a feature flag](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)
1. You have informed the Infrastructure department of a default setting or new setting change per [definition of done](contributing/merge_request_workflow.md#definition-of-done), or decided that this is unnecessary.
##### Compliance
@@ -788,7 +788,7 @@ Enterprise Edition instance. This has some implications:
cached value returns (say, from a string or nil to an array), change the
cache key at the same time.
1. **Settings** should be added as a
- [last resort](https://about.gitlab.com/handbook/product/product-principles/#convention-over-configuration). See [Adding a new setting to GitLab Rails](architecture.md#adding-a-new-setting-in-gitlab-rails).
+ [last resort](https://handbook.gitlab.com/handbook/product/product-principles/#convention-over-configuration). See [Adding a new setting to GitLab Rails](architecture.md#adding-a-new-setting-in-gitlab-rails).
1. **File system access** is not possible in a [cloud-native architecture](architecture.md#adapting-existing-and-introducing-new-components).
Ensure that we support object storage for any file storage we need to perform. For more
information, see the [uploads documentation](uploads/index.md).
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index a81424b50255cadd0c9580faf603023a24b99a49..144a1300104ffe19524020739f2b283805a42fc8 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -59,13 +59,13 @@ For a walkthrough of the contribution process, see [Tutorial: Make a GitLab cont
### Best practices
- If the change is non-trivial, we encourage you to start a discussion with
- [a product manager or a member of the team](https://about.gitlab.com/handbook/product/categories/).
+ [a product manager or a member of the team](https://handbook.gitlab.com/handbook/product/categories/).
You can do this by tagging them in an MR before submitting the code for review. Talking
to team members can be helpful when making design decisions. Communicating the
intent behind your changes can also help expedite merge request reviews.
- Consider placing your code behind a feature flag if you think it might affect production availability.
- Not sure? Read [When to use feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
+ Not sure? Read [When to use feature flags](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
- If you would like quick feedback on your merge request feel free to mention someone
from the [core team](https://about.gitlab.com/community/core-team/) or one of the
diff --git a/doc/development/contributing/verify/index.md b/doc/development/contributing/verify/index.md
index 5f9e2e3acb3d4d10aabd03159e9f73fd87a8558a..a77739f5b56084c5ca40837d36d3fbda99bba640 100644
--- a/doc/development/contributing/verify/index.md
+++ b/doc/development/contributing/verify/index.md
@@ -212,7 +212,7 @@ is recommended.
After your merge request is merged by a maintainer, it is time to release it to
users and the wider community. We usually do this with feature flags.
While not every merge request needs a feature flag, most merge
-requests in Verify should have [feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
+requests in Verify should have [feature flags](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
If you already follow the advice on this page, you probably already have a
few metrics and perhaps a few loggers added that make your new code observable
diff --git a/doc/development/deprecation_guidelines/index.md b/doc/development/deprecation_guidelines/index.md
index 7d1551cfc6c7a84ec445230316b46cc2dd2f2347..c1dd415025447366a064eb81d517ca515439f7ff 100644
--- a/doc/development/deprecation_guidelines/index.md
+++ b/doc/development/deprecation_guidelines/index.md
@@ -15,7 +15,7 @@ For details about the terms used on this page, see [the terminology](../../updat
Deprecations should be announced on the [Deprecated feature removal schedule](../../update/deprecations.md).
-Deprecations should be announced [no later than the third milestone preceding intended removal](https://about.gitlab.com/handbook/product/gitlab-the-product/#process-for-deprecating-and-removing-a-feature).
+Deprecations should be announced [no later than the third milestone preceding intended removal](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#process-for-deprecating-and-removing-a-feature).
Do not include the deprecation announcement in the merge request that introduces a code change for the deprecation.
Use a separate MR to create a deprecation entry. For steps to create a deprecation entry, see
diff --git a/doc/development/documentation/metadata.md b/doc/development/documentation/metadata.md
index af065e64e11711193252393fea5594066f5f83d8..d265f3cc01d09f77946258d0ad5da7e0da7c8187 100644
--- a/doc/development/documentation/metadata.md
+++ b/doc/development/documentation/metadata.md
@@ -25,7 +25,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
To populate the metadata, include this information:
-- `stage`: The [Stage](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+- `stage`: The [Stage](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)
that the majority of the page's content belongs to.
- `group`: The [Group](https://about.gitlab.com/company/team/structure/#product-groups)
that the majority of the page's content belongs to.
diff --git a/doc/development/documentation/review_apps.md b/doc/development/documentation/review_apps.md
index 2402a15e61b631b23829e94e14228f62fa313148..7c1f0173eab04e521fc800800baf5f6111101214 100644
--- a/doc/development/documentation/review_apps.md
+++ b/doc/development/documentation/review_apps.md
@@ -146,5 +146,5 @@ In that case, you can:
- Check the status of the remote pipeline from the link in the merge request's job output.
If the pipeline failed or got stuck, GitLab team members can ask for help in the `#docs`
internal Slack channel. Contributors can ping a
- [technical writer](https://about.gitlab.com/handbook/product/ux/technical-writing/#designated-technical-writers)
+ [technical writer](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-devops-stages-and-groups)
in the merge request.
diff --git a/doc/development/documentation/site_architecture/automation.md b/doc/development/documentation/site_architecture/automation.md
index 6573b7f191608abe5bcd453fecaae0c498d4908a..35723a5623b65a62f7140858acf08601e4153734 100644
--- a/doc/development/documentation/site_architecture/automation.md
+++ b/doc/development/documentation/site_architecture/automation.md
@@ -41,15 +41,15 @@ that are coded across multiple repositories.
| Page | Details | Owner |
|---|---|---|
-| [All feature flags in GitLab](../../../user/feature_flags.md) | [Generated during docs build](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/raketasks.md#generate-the-feature-flag-tables) | [Technical Writing](https://about.gitlab.com/handbook/product/ux/technical-writing/) |
+| [All feature flags in GitLab](../../../user/feature_flags.md) | [Generated during docs build](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/raketasks.md#generate-the-feature-flag-tables) | [Technical Writing](https://handbook.gitlab.com/handbook/product/ux/technical-writing/) |
| [GitLab Runner feature flags](https://docs.gitlab.com/runner/configuration/feature-flags.html) | [Page source](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/ec6e1797d2173a95c8ac7f726bd62f6f110b7211/docs/configuration/feature-flags.md?plain=1#L39) | [Runner](https://handbook.gitlab.com/handbook/engineering/development/ops/verify/runner/) |
| [Deprecations and removals by version](../../../update/deprecations.md) | [Deprecating GitLab features](../../deprecation_guidelines/index.md) | |
| [GraphQL API resources](../../../api/graphql/reference/index.md) | [GraphQL API style guide](../../api_graphql_styleguide.md#documentation-and-schema) | [Import and Integrate](https://about.gitlab.com/handbook/engineering/development/dev/manage/import-and-integrate/) |
| [Audit event types](../../../administration/audit_event_streaming/audit_event_types.md) | [Audit event development guidelines](../../audit_event_guide/index.md) | [Compliance](https://about.gitlab.com/handbook/engineering/development/sec/govern/compliance/) |
| [Available custom role permissions](../../../user/custom_roles/abilities.md) | [Generated by Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/tooling/custom_roles/docs/templates/custom_abilities.md.erb) | [Authorization](https://handbook.gitlab.com/handbook/product/categories/#authorization-group)|
-| DAST vulnerability check documentation ([Example](../../../user/application_security/dast/checks/798.19.md)) | [How to generate the Markdown](https://gitlab.com/gitlab-org/security-products/dast-cwe-checks/-/blob/main/doc/how-to-generate-the-markdown-documentation.md) | [Dynamic Analysis](https://about.gitlab.com/handbook/product/categories/#dynamic-analysis-group) |
+| DAST vulnerability check documentation ([Example](../../../user/application_security/dast/checks/798.19.md)) | [How to generate the Markdown](https://gitlab.com/gitlab-org/security-products/dast-cwe-checks/-/blob/main/doc/how-to-generate-the-markdown-documentation.md) | [Dynamic Analysis](https://handbook.gitlab.com/handbook/product/categories/#dynamic-analysis-group) |
| Blueprints ([Example](../../../architecture/blueprints/ci_data_decay/pipeline_partitioning.md)) | | |
-| [The docs homepage](../../../index.md) | | [Technical Writing](https://about.gitlab.com/handbook/product/ux/technical-writing/) |
+| [The docs homepage](../../../index.md) | | [Technical Writing](https://handbook.gitlab.com/handbook/product/ux/technical-writing/) |
## Make an automation request
diff --git a/doc/development/documentation/versions.md b/doc/development/documentation/versions.md
index be0c90bb308a965e586d6bd8d72ceb5f40aa7826..750817446d4d349305eb26cf1339e5fcf333042f 100644
--- a/doc/development/documentation/versions.md
+++ b/doc/development/documentation/versions.md
@@ -117,7 +117,7 @@ To deprecate a page or topic:
```markdown
## Title (deprecated)
-
+
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
@@ -145,7 +145,7 @@ To deprecate a page or topic:
<!--- start_remove The following content will be removed on remove_date: 'YYYY-MM-DD' -->
## Title (deprecated)
-
+
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
@@ -184,7 +184,7 @@ To remove a page:
---
# Title (removed)
-
+
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
@@ -197,7 +197,7 @@ To remove a page:
1. Remove the page's entry from the global navigation by editing [`navigation.yaml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/content/_data/navigation.yaml) in `gitlab-docs`.
This content is removed from the documentation as part of the Technical Writing team's
-[regularly scheduled tasks](https://about.gitlab.com/handbook/product/ux/technical-writing/#regularly-scheduled-tasks).
+[regularly scheduled tasks](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#regularly-scheduled-tasks).
### Remove a topic
@@ -213,7 +213,7 @@ To remove a topic:
<!--- start_remove The following content will be removed on remove_date: 'YYYY-MM-DD' -->
## Title (removed)
-
+
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
@@ -226,7 +226,7 @@ To remove a topic:
```
This content is removed from the documentation as part of the Technical Writing team's
-[regularly scheduled tasks](https://about.gitlab.com/handbook/product/ux/technical-writing/#regularly-scheduled-tasks).
+[regularly scheduled tasks](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#regularly-scheduled-tasks).
## Which versions are removed
diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md
index 965559bd217b119917a5033828b3eac3ab45993b..f870e219a2942da15b126ff9537d82f1e7d8fbb2 100644
--- a/doc/development/documentation/workflow.md
+++ b/doc/development/documentation/workflow.md
@@ -94,7 +94,7 @@ For these reasons, do not add AI-generated content to the documentation.
## Related topics
-- [Reviews and levels of edit](https://about.gitlab.com/handbook/product/ux/technical-writing/#reviews)
+- [Reviews and levels of edit](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#reviews)
- [Technical writing assignments](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments)
- The [Style Guide](styleguide/index.md)
- The [Word list](styleguide/word_list.md)
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index fd00b8b86cb23764f2cc5e1013d937d5f21ad0aa..3cdf8e49c9422f6ddd0325f3417439435f387f20 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -22,7 +22,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
Use the following guidelines when you develop a feature that is only applicable for SaaS (for example, a CustomersDot integration).
-In general, features should be provided for [both SaaS and self-managed deployments](https://about.gitlab.com/handbook/product/product-principles/#parity-between-saas-and-self-managed-deployments).
+In general, features should be provided for [both SaaS and self-managed deployments](https://handbook.gitlab.com/handbook/product/product-principles/#parity-between-saas-and-self-managed-deployments).
However, there are cases when a feature should only be available on SaaS and this guide will help show how that is
accomplished.
@@ -61,7 +61,7 @@ Each SaaS feature is defined in a separate YAML file consisting of a number of f
| `name` | yes | Name of the SaaS feature. |
| `introduced_by_url` | no | The URL to the merge request that introduced the SaaS feature. |
| `milestone` | no | Milestone in which the SaaS feature was created. |
-| `group` | no | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
+| `group` | no | The [group](https://handbook.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
#### Create a new SaaS feature file definition
diff --git a/doc/development/fe_guide/getting_started.md b/doc/development/fe_guide/getting_started.md
index a53f0e6123005416aff72594812976a86ed94c45..58cbbd7276ca6bea2988d4520004a39e330505d5 100644
--- a/doc/development/fe_guide/getting_started.md
+++ b/doc/development/fe_guide/getting_started.md
@@ -24,7 +24,7 @@ Before writing code, make sure to ask yourself the following questions and have
- If this is GraphQL, write a query proposal and ask your BE counterpart to confirm they are in agreement.
- Can I use [GitLab UI components](https://gitlab-org.gitlab.io/gitlab-ui/?path=/docs/base-accordion--docs)? Which components are appropriate and do they have all of the functionality that I need?
- Are there existing components or utilities in the GitLab project that I could use?
-- [Should this change live behind a Feature Flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)?
+- [Should this change live behind a Feature Flag](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags)?
- In which directory should this code live?
- Should I build part of this feature as reusable? If so, where should it live in the codebase and how do I make it discoverable?
- Note: For now this is still being considered, but the `vue_shared` folder is still the preferred directory for GitLab-wide components.
diff --git a/doc/development/feature_categorization/index.md b/doc/development/feature_categorization/index.md
index f5bb20ff61caa60cb9293a204df0347caa4d1a1f..0236ad63b704a44bc775220e29b647b47cc3bd70 100644
--- a/doc/development/feature_categorization/index.md
+++ b/doc/development/feature_categorization/index.md
@@ -10,7 +10,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
Each Sidekiq worker, Batched Background migrations, controller action, [test example](../testing_guide/best_practices.md#feature-category-metadata) or API endpoint
must declare a `feature_category` attribute. This attribute maps each
-of these to a [feature category](https://about.gitlab.com/handbook/product/categories/). This
+of these to a [feature category](https://handbook.gitlab.com/handbook/product/categories/). This
is done for error budgeting, alert routing, and team attribution.
The list of feature categories can be found in the file `config/feature_categories.yml`.
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index 798e978ac266ad16c5a100a739940bd1b254cf70..b773c24132063ba0e5ed210d74c425304adf2471 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -24,11 +24,11 @@ Blueprints:
This document is the subject of continued work as part of an epic to [improve internal usage of feature flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
-For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.
+For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.
## When to use feature flags
-Moved to the ["When to use feature flags"](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) section in the handbook.
+Moved to the ["When to use feature flags"](https://handbook.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) section in the handbook.
## Feature flags in GitLab development
@@ -161,7 +161,7 @@ push_frontend_feature_flag(:my_wip_flag, project, type: :wip)
### `beta` type
We might
-[not be confident we'll be able to scale, support, and maintain a feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga)
+[not be confident we'll be able to scale, support, and maintain a feature](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga)
in its current form for every designed use case ([example](https://gitlab.com/gitlab-org/gitlab/-/issues/336070#note_1523983444)).
There are also scenarios where a feature is not complete enough to be considered an MVC.
Providing a flag in this case allows engineers and customers to disable the new feature until it's performant enough.
@@ -275,7 +275,7 @@ Each feature flag is defined in a separate YAML file consisting of a number of f
| `default_enabled` | yes | The default state of the feature flag. |
| `introduced_by_url` | yes | The URL to the merge request that introduced the feature flag. |
| `milestone` | yes | Milestone in which the feature flag was created. |
-| `group` | yes | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
+| `group` | yes | The [group](https://handbook.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
| `feature_issue_url` | no | The URL to the original feature issue. |
| `rollout_issue_url` | no | The URL to the Issue covering the feature flag rollout. |
| `log_state_changes` | no | Used to log the state of the feature flag |
diff --git a/doc/development/gemfile.md b/doc/development/gemfile.md
index 4801a8c25578f2c33763c27995c1f83dddab996a..9ebae8cbaa35058e1ded1e776da9d4d2dbac9b92 100644
--- a/doc/development/gemfile.md
+++ b/doc/development/gemfile.md
@@ -80,8 +80,8 @@ For gems not listed in this table, it's still recommended but not required that
| Gem | Requires approval by |
| ------ | ------ |
-| `doorkeeper` | [Manage:Authentication and Authorization](https://about.gitlab.com/handbook/product/categories/#authentication-and-authorization-group) |
-| `doorkeeper-openid_connect` | [Manage:Authentication and Authorization](https://about.gitlab.com/handbook/product/categories/#authentication-and-authorization-group) |
+| `doorkeeper` | [Manage:Authentication and Authorization](https://handbook.gitlab.com/handbook/product/categories/#authentication-and-authorization-group) |
+| `doorkeeper-openid_connect` | [Manage:Authentication and Authorization](https://handbook.gitlab.com/handbook/product/categories/#authentication-and-authorization-group) |
## Request an Appsec review
diff --git a/doc/development/geo.md b/doc/development/geo.md
index 365893b3be74da1646cb93f557dad93b71dce3c6..e0b4b2a68103184d6f7969d6b82701fad986a1ed 100644
--- a/doc/development/geo.md
+++ b/doc/development/geo.md
@@ -596,7 +596,7 @@ Geo depends on PostgreSQL replication of the main and CI databases, so if you ad
However, if you introduce a new kind of data which is stored outside of the main and CI PostgreSQL databases, then you need to ensure that this data is replicated and verified by Geo. This is necessary for customers to be able to rely on their secondary sites for [disaster recovery](../administration/geo/disaster_recovery/index.md).
-The following subsections describe how to determine whether work is needed, and if so, how to proceed. If you have any questions, [contact the Geo team](https://about.gitlab.com/handbook/product/categories/#geo-group).
+The following subsections describe how to determine whether work is needed, and if so, how to proceed. If you have any questions, [contact the Geo team](https://handbook.gitlab.com/handbook/product/categories/#geo-group).
For comparison with your own features, see [Supported Geo data types](../administration/geo/replication/datatypes.md). It has a detailed, up-to-date list of the types of data that Geo replicates and verifies.
diff --git a/doc/development/go_guide/go_upgrade.md b/doc/development/go_guide/go_upgrade.md
index 5386221ea7eba2caa74eb8a10ba88bff390e8947..cab4ce4cae64b0471c296f690294ce000b51dfa5 100644
--- a/doc/development/go_guide/go_upgrade.md
+++ b/doc/development/go_guide/go_upgrade.md
@@ -10,7 +10,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
All Go binaries, with the exception of
[GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) and [Security Projects](https://gitlab.com/gitlab-org/security-products), are built in
-projects managed by the [Distribution team](https://about.gitlab.com/handbook/product/categories/#distribution-group).
+projects managed by the [Distribution team](https://handbook.gitlab.com/handbook/product/categories/#distribution-group).
The [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab) project creates a
single, monolithic operating system package containing all the binaries, while
@@ -71,15 +71,15 @@ The upgrade process involves several key steps:
#### Tracking work
-Use [the product categories page](https://about.gitlab.com/handbook/product/categories/)
+Use [the product categories page](https://handbook.gitlab.com/handbook/product/categories/)
if you need help finding the correct person or labels:
1. Create the epic in `gitlab-org` group:
- Title the epic `Update Go version to <VERSION_NUMBER>`.
- Ping the engineering managers responsible for [the projects listed below](#known-dependencies-using-go).
- Most engineering managers can be identified on
- [the product page](https://about.gitlab.com/handbook/product/categories/) or the
- [feature page](https://about.gitlab.com/handbook/product/categories/features/).
+ [the product page](https://handbook.gitlab.com/handbook/product/categories/) or the
+ [feature page](https://handbook.gitlab.com/handbook/product/categories/features/).
- If you still can't find the engineering manager, use
[Git blame](/ee/user/project/repository/git_blame.md) to identify a maintainer
involved in the project.
diff --git a/doc/development/internal_analytics/index.md b/doc/development/internal_analytics/index.md
index 465d4dec14c1720a70fa7b2c651ee756f42a3ddb..13ecaddaf705f9bacdeb67dfefae60b7c8173b1a 100644
--- a/doc/development/internal_analytics/index.md
+++ b/doc/development/internal_analytics/index.md
@@ -83,7 +83,7 @@ WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --set to metric of
ORDER BY ping_created_at DESC
```
-For a list of other metrics tables refer to the [Data Models Cheat Sheet](https://about.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models).
+For a list of other metrics tables refer to the [Data Models Cheat Sheet](https://handbook.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models).
### Querying events
@@ -100,7 +100,7 @@ AND app_id='gitlab' -- use gitlab for production events and gitlab-staging for e
GROUP BY 1 ORDER BY 1 desc
```
-For a list of other event tables refer to the [Data Models Cheat Sheet](https://about.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models-2).
+For a list of other event tables refer to the [Data Models Cheat Sheet](https://handbook.gitlab.com/handbook/product/product-analysis/data-model-cheat-sheet/#commonly-used-data-models-2).
## Data flow
diff --git a/doc/development/labels/index.md b/doc/development/labels/index.md
index b65d610e87892739f4def714ae174a55e35ef24e..3ec9785c9cb505aa6e25d04b31b9cf543762f818 100644
--- a/doc/development/labels/index.md
+++ b/doc/development/labels/index.md
@@ -54,7 +54,7 @@ The GitLab handbook documents [when something is a bug](https://about.gitlab.com
## Stage labels
-Stage labels specify which [stage](https://about.gitlab.com/handbook/product/categories/#hierarchy) the issue belongs to.
+Stage labels specify which [stage](https://handbook.gitlab.com/handbook/product/categories/#hierarchy) the issue belongs to.
### Naming and color convention
@@ -98,7 +98,7 @@ The current group labels can be found by [searching the labels list for `group::
These labels are [scoped labels](../../user/project/labels.md#scoped-labels)
and thus are mutually exclusive.
-You can find the groups listed in the [Product Stages, Groups, and Categories](https://about.gitlab.com/handbook/product/categories/) page.
+You can find the groups listed in the [Product Stages, Groups, and Categories](https://handbook.gitlab.com/handbook/product/categories/) page.
We use the term group to map down product requirements from our product stages.
As a team needs some way to collect the work their members are planning to be assigned to, we use the `~group::` labels to do so.
@@ -106,7 +106,7 @@ As a team needs some way to collect the work their members are planning to be as
## Category labels
From the handbook's
-[Product stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/#hierarchy)
+[Product stages, groups, and categories](https://handbook.gitlab.com/handbook/product/categories/#hierarchy)
page:
> Categories are high-level capabilities that may be a standalone product at
@@ -138,7 +138,7 @@ in <https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml
## Feature labels
From the handbook's
-[Product stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/#hierarchy)
+[Product stages, groups, and categories](https://handbook.gitlab.com/handbook/product/categories/#hierarchy)
page:
> Features: Small, discrete functionalities, for example Issue weights. Some common
diff --git a/doc/development/merge_request_concepts/rate_limits.md b/doc/development/merge_request_concepts/rate_limits.md
index 45b667aa2a39e3d59bb791e12cc464199c720112..7d468b9a654899ad086b6b5bf30eb7af4c7a1764 100644
--- a/doc/development/merge_request_concepts/rate_limits.md
+++ b/doc/development/merge_request_concepts/rate_limits.md
@@ -24,5 +24,5 @@ Limits are applicable for:
## Additional reading
- Existing [GitLab application limits](../../administration/instance_limits.md)
-- Product processes: [introducing application limits](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits)
+- Product processes: [introducing application limits](https://handbook.gitlab.com/handbook/product/product-processes/#introducing-application-limits)
- Development docs: [guide for adding application limits](../application_limits.md)
diff --git a/doc/development/product_qualified_lead_guide/index.md b/doc/development/product_qualified_lead_guide/index.md
index fae0225b52c3ff0fa7b9bcd2077793f3679be57b..47568c97e2ba15e4015c3a6a04121a24f80f522f 100644
--- a/doc/development/product_qualified_lead_guide/index.md
+++ b/doc/development/product_qualified_lead_guide/index.md
@@ -6,7 +6,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
# Product Qualified Lead (PQL) development guidelines
-The Product Qualified Lead (PQL) funnel connects our users with our team members. Read more about [PQL product principles](https://about.gitlab.com/handbook/product/product-principles/#product-qualified-leads-pqls).
+The Product Qualified Lead (PQL) funnel connects our users with our team members. Read more about [PQL product principles](https://handbook.gitlab.com/handbook/product/product-principles/#product-qualified-leads-pqls).
A hand-raise PQL is a user who requests to speak to sales from within the product.
diff --git a/doc/development/project_templates.md b/doc/development/project_templates.md
index 7200927858ccb4fc08e16f41a968f2c957cc52c6..aba409ce142f7f2e98a86af04893702f64188dda 100644
--- a/doc/development/project_templates.md
+++ b/doc/development/project_templates.md
@@ -13,7 +13,7 @@ If you'd like to contribute a new built-in project template to be distributed wi
1. Create a new public project with the project content you'd like to contribute in a namespace of your choosing. You can view a working example [here](https://gitlab.com/gitlab-org/project-templates/dotnetcore).
- Projects should be as simple as possible and free of any unnecessary assets or dependencies.
1. When the project is ready for review, create a new issue in [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) with a link to your project.
- - In your issue, `@` mention the relevant Backend Engineering Manager and Product Manager for the [Create:Source Code group](https://about.gitlab.com/handbook/product/categories/#source-code-group).
+ - In your issue, `@` mention the relevant Backend Engineering Manager and Product Manager for the [Create:Source Code group](https://handbook.gitlab.com/handbook/product/categories/#source-code-group).
To make the project template available when creating a new project, the vendoring process will have to be completed:
diff --git a/doc/development/software_design.md b/doc/development/software_design.md
index a771e7a9e6143eec31c1e2b09984c903a9bc0f38..55170ceafe6a63fb40cd78c80de94047efc48f4e 100644
--- a/doc/development/software_design.md
+++ b/doc/development/software_design.md
@@ -94,7 +94,7 @@ for example `Project::CreateService` or `Groups::TransferService`.
For controllers we allow `app/controllers/projects` and `app/controllers/groups` to be exceptions.
We use this convention to indicate the scope of a given web endpoint.
-Do not use the [stage or group name](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+Do not use the [stage or group name](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)
because a feature category could be reassigned to a different group in the future.
```ruby
@@ -262,12 +262,12 @@ user_score.telesign
user_score.arkose_global
```
-See a real example [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117853#note_1423070054).
+See a real example [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117853#note_1423070054).
### Example: Use Dependency Inversion to extract a domain concept
```ruby
-##
+##
# BAD: methods related to integrations defined in Project.
class Project
has_many :integrations
diff --git a/doc/development/stage_group_observability/index.md b/doc/development/stage_group_observability/index.md
index 37aeb666d370aed49daefe5f3b6600b5715ed684..d295a302c9bdd913d193eda22366223b66660121 100644
--- a/doc/development/stage_group_observability/index.md
+++ b/doc/development/stage_group_observability/index.md
@@ -11,7 +11,7 @@ understand the state of each component, with context, to support
performance tuning and debugging. To run a SaaS platform at scale, a
rich and detailed observability platform is needed.
-To make information available to [stage groups](https://about.gitlab.com/handbook/product/categories/#hierarchy),
+To make information available to [stage groups](https://handbook.gitlab.com/handbook/product/categories/#hierarchy),
we are aggregating metrics by feature category and then show
this information on [dashboards](dashboards/index.md) tailored to the groups. Only metrics
for the features built by the group are visible on their
diff --git a/doc/development/testing_guide/end_to_end/beginners_guide.md b/doc/development/testing_guide/end_to_end/beginners_guide.md
index 5fc18d7aeaec668be78b2b6dfe814e3ebd4e09ac..8ead75d4d9545b58218677b0d547b847ed46842d 100644
--- a/doc/development/testing_guide/end_to_end/beginners_guide.md
+++ b/doc/development/testing_guide/end_to_end/beginners_guide.md
@@ -65,7 +65,7 @@ end-to-end flows, and is easiest to understand.
The GitLab QA end-to-end tests are organized by the different
[stages in the DevOps lifecycle](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa/qa/specs/features/browser_ui).
Determine where the test should be placed by
-[stage](https://about.gitlab.com/handbook/product/categories/#devops-stages),
+[stage](https://handbook.gitlab.com/handbook/product/categories/#devops-stages),
determine which feature the test belongs to, and then place it in a subdirectory
under the stage.
diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md
index 10ecbece34520f7d0b88d7c25b6a91adfcffde79..1f9a28da850a4412e41fd344fdaa946d1e51ea7a 100644
--- a/doc/development/testing_guide/end_to_end/best_practices.md
+++ b/doc/development/testing_guide/end_to_end/best_practices.md
@@ -129,7 +129,7 @@ end
1. Keep descriptions as concise as possible.
1. Long descriptions or multiple conditionals could be a sign it should be split up (additional `context` blocks).
1. The [Documentation Style Guide](../../documentation/styleguide/index.md) gives recommendations on how to write concisely and with [active voice](../../documentation/styleguide/index.md#active-voice).
-1. The outermost `Rspec.describe` block should be [the DevOps stage name](https://about.gitlab.com/handbook/product/categories/#devops-stages)
+1. The outermost `Rspec.describe` block should be [the DevOps stage name](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)
1. Inside the `Rspec.describe` block is a `describe` block with the name of the feature being tested
1. Optional `context` blocks define what the conditions being tested are
1. `context` blocks descriptions should begin with `when`, `with`, `without`, `for`, `and`, `on`, `in`, `as`, or `if` to match the [rubocop rule](https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/ContextWording)
diff --git a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
index c6dbbfc7b9d572e9566f86ed19cd0a40bb3a512e..f9be76e4e470a2c7feabf5be86013aa4aa129c1e 100644
--- a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
+++ b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
@@ -37,7 +37,7 @@ This is a partial list of the [RSpec metadata](https://rspec.info/features/3-12/
| `:object_storage` | The test requires a GitLab instance to be configured to use multiple [object storage types](../../../administration/object_storage.md). Uses MinIO as the object storage server. |
| `:only` | The test is only to be run in specific execution contexts. See [test execution context selection](execution_context_selection.md) for more information. |
| `:orchestrated` | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging). | |
-| `:product_group` | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/) for the comprehensive groups list. |
+| `:product_group` | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://handbook.gitlab.com/handbook/product/categories/) for the comprehensive groups list. |
| `:quarantine` | The test has been [quarantined](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs in a specific context](execution_context_selection.md#quarantine-a-test-for-a-specific-environment). |
| `:relative_url` | The test requires a GitLab instance to be installed under a [relative URL](../../../install/relative_url.md). |
| `:reliable` | The test has been [promoted to a reliable test](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 99852645914da5e11b837d01bb57f5cdc72e181a..01237630c5aa2be94808d633adbd56570bc90d53 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -476,7 +476,7 @@ Every new feature should come with a [test plan](https://gitlab.com/gitlab-org/g
| Tests path | Testing engine | Notes |
| ---------- | -------------- | ----- |
-| `qa/qa/specs/features/` | [Capybara](https://github.com/teamcapybara/capybara) + [RSpec](https://github.com/rspec/rspec-rails#feature-specs) + Custom QA framework | Tests should be placed under their corresponding [Product category](https://about.gitlab.com/handbook/product/categories/) |
+| `qa/qa/specs/features/` | [Capybara](https://github.com/teamcapybara/capybara) + [RSpec](https://github.com/rspec/rspec-rails#feature-specs) + Custom QA framework | Tests should be placed under their corresponding [Product category](https://handbook.gitlab.com/handbook/product/categories/) |
> See [end-to-end tests](end_to_end/index.md) for more information.
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index 403e8cd2e2626dd321f7fa0127f09730da298562..7057005fdc654aef6a336858da220ba421a2c52f 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -479,7 +479,7 @@ To work around the issue, give these users the Guest role or higher to any proje
## Related topics
- [Custom roles](custom_roles.md)
-- [The GitLab principles behind permissions](https://about.gitlab.com/handbook/product/gitlab-the-product/#permissions-in-gitlab)
+- [The GitLab principles behind permissions](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#permissions-in-gitlab)
- [Members](project/members/index.md)
- Customize permissions on [protected branches](project/protected_branches.md)
- [LDAP user permissions](group/access_and_permissions.md#manage-group-memberships-via-ldap)