Update docs links in product pages

### Communicating with the Product Division

Below are team emails and handles that can be used for different departments and sub-departments in the Product Division. These groups are used for internal communication and the `@mention` can only be used by project members. Please remember that tagging `@mention` on issues will generate in-product [to-do items](https://docs.gitlab.com/ee/user/todos.html) and email notifications to **all** team members in that project, so use it only when you need to communicate with the entire team. For communication specifically for product managers, please leverage [How to Engage](/handbook/product/product-management/how-to-engage/).

Below are team emails and handles that can be used for different departments and sub-departments in the Product Division. These groups are used for internal communication and the `@mention` can only be used by project members. Please remember that tagging `@mention` on issues will generate in-product [to-do items](https://docs.gitlab.com/user/todos/) and email notifications to **all** team members in that project, so use it only when you need to communicate with the entire team. For communication specifically for product managers, please leverage [How to Engage](/handbook/product/product-management/how-to-engage/).

- `@gl-product-leadership` tags all group managers, directors and VPs in the Product Division

- `@gl-product-plt` tags all direct reports to the VP Product in the Product Division

- Clearly state why you are tagging the entire product team and what action you need product team members to take.

- Write a short summary in the same comment so team members can quickly understand the necessary context.

- Review the issue title and description to ensure it has relevant details other product team members need **BEFORE** submitting the comment. The issue title will be the subject of email notifications and in-product to-do items.

- If asking team members to review a change, please directly link to the specific page on the [review app](https://docs.gitlab.com/ee/ci/review_apps/#how-review-apps-work) and any relevant issues or MRs.

- If asking team members to review a change, please directly link to the specific page on the [review app](https://docs.gitlab.com/ci/review_apps/#how-review-apps-work) and any relevant issues or MRs.

## Special considerations for AI features

* [AI ethics principles](/handbook/legal/ethics-compliance-program/ai-ethics-principles/#1-avoid-unfair-bias): Principles to guide our decision making as we continue to build AI features into GitLab and to ensure that these features properly embody our values.

* [AI data usage and privacy](https://docs.gitlab.com/ee/user/gitlab_duo/data_usage.html): Public facing docs about how we use and protect data.

* [AI data usage and privacy](https://docs.gitlab.com/user/gitlab_duo/data_usage/): Public facing docs about how we use and protect data.

## Engineering AI features

* [Development process AI features](https://docs.gitlab.com/ee/development/ai_features/index.html)

* [List of language models](https://docs.gitlab.com/ee/user/gitlab_duo/index.html): All the models we are using to power features.

* [Development process AI features](https://docs.gitlab.com/development/ai_features/)

* [List of language models](https://docs.gitlab.com/user/gitlab_duo/): All the models we are using to power features.

* [Process for choosing or switching AI vendors](/handbook/product/ai/continuity-plan/)

## Support engineering AI features

## Current AI features and teams

* [List of AI features](/handbook/engineering/development/data-science/ai-powered/#features): Current AI features in developement, the team that owns them and whether they are integrated into Duo Chat.

* [AI features by tier](https://docs.gitlab.com/ee/user/gitlab_duo/index.html): All features that are available to use, and how to access them.

* [AI features by tier](https://docs.gitlab.com/user/gitlab_duo/): All features that are available to use, and how to access them.

* [AI teams](/handbook/engineering/development/data-science/ai-powered/#stage-groups)

## Summary

The following guidelines focus on the **UX** aspect of the maturity of AI-assisted features. [Other aspects](https://docs.gitlab.com/ee/policy/development_stages_support.html), like stability or documentation, should also be taken into account to determine the appropriate feature maturity.

The following guidelines focus on the **UX** aspect of the maturity of AI-assisted features. [Other aspects](https://docs.gitlab.com/policy/development_stages_support/), like stability or documentation, should also be taken into account to determine the appropriate feature maturity.

To evaluate the UX maturity of AI-assisted features, use three criteria from the [Product Development Flow](/handbook/product-development-flow/):

#### High Confidence & Low Risk

When an AI-powered feature has high confidence in the output quality and low risk of producing harmful or incorrect results, the feature can rely primarily on the standard [feature maturity](https://docs.gitlab.com/ee/policy/development_stages_support.html) definitions. In this case an evaluation dataset is not required, however the feature should have basic guardrails like unit tests and can rely mainly on the existing AI Framework and AI Gateway.

When an AI-powered feature has high confidence in the output quality and low risk of producing harmful or incorrect results, the feature can rely primarily on the standard [feature maturity](https://docs.gitlab.com/policy/development_stages_support/) definitions. In this case an evaluation dataset is not required, however the feature should have basic guardrails like unit tests and can rely mainly on the existing AI Framework and AI Gateway.

Consider running a UX Bash with at least 10 external users validating the quality of the output. We have a framework for how to run them to evaluate output quality.

1. **Sections**: Are a collection of stages. We attempt to align these logically along common workflows like Dev, Sec and Ops.

Sections are maintained in [`data/sections.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/sections.yml).

1. **Stages**: are maintained in [`data/stages.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).

Each stage has a corresponding [`devops::<stage>` label](https://docs.gitlab.com/ee/development/labels/index.html#stage-labels) under the `gitlab-org` group.

Each stage has a corresponding [`devops::<stage>` label](https://docs.gitlab.com/development/labels/#stage-labels) under the `gitlab-org` group.

1. **Group**: A stage has one or more [groups](/handbook/company/structure/#product-groups).

Groups are maintained in [`data/stages.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).

Each group has a corresponding [`group::<group>` label](https://docs.gitlab.com/ee/development/labels/index.html#group-labels) under the `gitlab-org` group.

Each group has a corresponding [`group::<group>` label](https://docs.gitlab.com/development/labels/#group-labels) under the `gitlab-org` group.

1. **Categories**: A group has one or more categories. Categories are high-level

capabilities that may be a standalone product at another company. e.g.

Portfolio Management. To the extent possible we should map categories to

lines when rendered would exceed 13 lines, when accounting for category names

to word-wrap, which occurs at approximately 15 characters.

Categories are maintained in [`data/categories.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml).

Each category has a corresponding [`Category:<Category>` label](https://docs.gitlab.com/ee/development/labels/index.html#category-labels) under the `gitlab-org` group. Category maturity is managed in the product [Category Maturity Change](/handbook/product/categories/#changing-category-maturity) process

Each category has a corresponding [`Category:<Category>` label](https://docs.gitlab.com/development/labels/#category-labels) under the `gitlab-org` group. Category maturity is managed in the product [Category Maturity Change](/handbook/product/categories/#changing-category-maturity) process

1. **Features**: Small, discrete functionalities. e.g. Issue weights. Some

common features are listed within parentheses to facilitate finding

responsible PMs by keyword.

Features are maintained in [`data/features.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml).

It's recommended to associate [feature labels](https://docs.gitlab.com/ee/development/labels/index.html#feature-labels) to a category or a group with `feature_labels` in [`data/categories.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/categories.yml?ref_type=heads) or [`data/stages.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/stages.yml?ref_type=heads).

It's recommended to associate [feature labels](https://docs.gitlab.com/development/labels/#feature-labels) to a category or a group with `feature_labels` in [`data/categories.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/categories.yml?ref_type=heads) or [`data/stages.yml`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/stages.yml?ref_type=heads).

Notes:

This is to ensure that [GitLab Bot auto-labeling](/handbook/engineering/infrastructure/engineering-productivity/triage-operations/#auto-labelling-of-issues-and-merge-requests) can be updated prior to the change, which can be [disruptive if missed](https://gitlab.com/gitlab-org/quality/triage-ops/-/issues/467#note_337325686).

Upon approval, tag the group Technical Writer in the merge request to ensure [documentation metadata](https://docs.gitlab.com/ee/development/documentation/#stage-and-group-metadata) is updated after the category change is merged.

Upon approval, tag the group Technical Writer in the merge request to ensure [documentation metadata](https://docs.gitlab.com/development/documentation/#stage-and-group-metadata) is updated after the category change is merged.

Ensure that relevant slack channels are updated following our [slack channel naming convention](/handbook/communication/chat/#channel-categories), open an [access request](/handbook/it/end-user-services/onboarding-access-requests/access-requests/) to have slack channel names updated as they can no longer be updated by creators.

[Code Review group](/handbook/product/categories/#code-review-group)

- [Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/)

- [Merge Requests](https://docs.gitlab.com/user/project/merge_requests/)

- [GitLab CLI](https://gitlab.com/gitlab-org/cli)

#### Remote Development group

[Remote Development group](/handbook/product/categories/#remote-development-group/)

- [GitLab Workflow extension for Visual Studio Code](https://docs.gitlab.com/ee/editor_extensions/visual_studio_code/)

- [GitLab Workflow extension for Visual Studio Code](https://docs.gitlab.com/editor_extensions/visual_studio_code/)

### Other functionality in Verify

[Pipeline Authoring Group](#pipeline-authoring-group)

- [CI/CD Template Management and Contributions](https://docs.gitlab.com/ee/development/cicd/templates.html)

- [CI/CD Template Management and Contributions](https://docs.gitlab.com/development/cicd/templates/)

### Other functionality in Monitor stage

[Developer Experience](/handbook/engineering/infrastructure-platforms/developer-experience/)

- [Reference Architectures](https://docs.gitlab.com/ee/administration/reference_architectures/)

- [Reference Architectures](https://docs.gitlab.com/administration/reference_architectures/)

- [GitLab Environment Toolkit (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit)

- [GitLab Performance Tool (GPT)](https://gitlab.com/gitlab-org/quality/performance)

- [Performance Test Data](https://gitlab.com/gitlab-org/quality/performance-data)

[Product Analytics group](/handbook/product/categories/#product-analytics-group)

- [Analytics Dashboards](https://docs.gitlab.com/ee/user/product_analytics/#product-analytics-dashboards) - used by many groups to add visualizations or provide pre-configured dashboards to users

- [Analytics Dashboards](https://docs.gitlab.com/user/product_analytics/#product-analytics-dashboards) - used by many groups to add visualizations or provide pre-configured dashboards to users

### Facilitated functionality

Some product areas are have a broad impact across multiple stages. Examples of this include, among others:

- Shared project views, like the [project](https://docs.gitlab.com/ee/user/project/#projects) overview and settings page.

- Functionality specific to the [admin area](https://docs.gitlab.com/ee/administration/settings/) and not tied to a feature belonging to a particular stage.

- Shared project views, like the [project](https://docs.gitlab.com/user/project/#projects) overview and settings page.

- Functionality specific to the [admin area](https://docs.gitlab.com/administration/settings/) and not tied to a feature belonging to a particular stage.

- UI components available through our design system, [Pajamas](https://design.gitlab.com/).

- Dashboards for displaying analytics, such as Product Analytics, Value Stream Analytics, and others.

### Naming features

Naming new features or [renaming existing features](https://docs.gitlab.com/ee/development/renaming_features.html) is notoriously hard and sensitive to many opinions.

Naming new features or [renaming existing features](https://docs.gitlab.com/development/renaming_features/) is notoriously hard and sensitive to many opinions.

#### Factors in picking a name

All the above can be achieved by iteratively improving existing roles.

[Documentation on permissions](https://docs.gitlab.com/ee/user/permissions.html)

[Documentation on permissions](https://docs.gitlab.com/user/permissions/)

### Security Paradigm

GitLab ships with built-in integrations to many popular applications. We aspire

to have the world's best integrations for Slack, JIRA, and Jenkins.

Many other applications [integrate with GitLab](/partners/technology-partners/integrate/), and we are open to adding new integrations to our [technology partners page](/partners/technology-partners/). New integrations with GitLab can vary in richness and complexity; from a simple webhook, and all the way to a [Project Service](https://docs.gitlab.com/ee/user/project/integrations/).

Many other applications [integrate with GitLab](/partners/technology-partners/integrate/), and we are open to adding new integrations to our [technology partners page](/partners/technology-partners/). New integrations with GitLab can vary in richness and complexity; from a simple webhook, and all the way to a [Project Service](https://docs.gitlab.com/user/project/integrations/).

GitLab [welcomes and supports new integrations](/partners/technology-partners/integrate/) to be created to extend collaborations with other products.

GitLab plays well with others by providing APIs for nearly anything you can do within GitLab.

GitLab can be a [provider of authentication](https://docs.gitlab.com/ee/integration/oauth_provider.html) for external applications.

GitLab can be a [provider of authentication](https://docs.gitlab.com/integration/oauth_provider/) for external applications.

There is some natural tension between GitLab being a single-application for the

entire DevOps lifecycle, and our support for better user experience via integration