Format user roles notes to reducs extra links

We don't need so many links.

doc/api/audit_events.md

@@ -312,7 +312,7 @@ Example response:
 
 ### Retrieve a specific project audit event
 
-Only available to users with at least the [Maintainer role](../user/permissions.md) for the project.
+Only available to users with at least the Maintainer role for the project.
 
 ```plaintext
 GET /projects/:id/audit_events/:audit_event_id

doc/api/dependency_proxy.md

@@ -12,8 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/273655) from GitLab Premium to GitLab Free in 13.6.
 
 Schedules for deletion the cached manifests and blobs for a group. This endpoint requires the
-[Owner role](../user/permissions.md)
-for the group.
+Owner role for the group.
 
 ```plaintext
 DELETE /groups/:id/dependency_proxy/cache

doc/api/deploy_tokens.md

@@ -49,7 +49,7 @@ Example response:
 
 ## Project deploy tokens
 
-Project deploy token API endpoints require the [Maintainer role](../user/permissions.md) or higher
+Project deploy token API endpoints require the Maintainer role or higher
 for the project.
 
 ### List project deploy tokens
@@ -165,7 +165,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" \
 
 ## Group deploy tokens
 
-Users with at least the [Maintainer role](../user/permissions.md) for the group can list group deploy
+Users with at least the Maintainer role for the group can list group deploy
 tokens. Only group Owners can create and delete group deploy tokens.
 
 ### List group deploy tokens

doc/api/dora/metrics.md

@@ -10,7 +10,7 @@ type: reference, api
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/279039) in GitLab 13.10.
 > - The legacy key/value pair `{ "<date>" => "<value>" }` was removed from the payload in GitLab 14.0.
 
-All methods require at least the Reporter [role](../../user/permissions.md).
+All methods require at least the Reporter role.
 
 ## Get project-level DORA metrics
 

doc/api/error_tracking.md

@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Error Tracking project settings
 
 The project settings API allows you to retrieve the [Error Tracking](../operations/error_tracking.md)
-settings for a project. Only for users with [Maintainer role](../user/permissions.md) for the project.
+settings for a project. Only for users with Maintainer role for the project.
 
 ### Get Error Tracking settings
 
@@ -42,7 +42,7 @@ Example response:
 ### Enable or disable the Error Tracking project settings
 
 The API allows you to enable or disable the Error Tracking settings for a project. Only for users with the
-[Maintainer role](../user/permissions.md) for the project.
+Maintainer role for the project.
 
 ```plaintext
 PATCH /projects/:id/error_tracking/settings
@@ -75,7 +75,7 @@ Example response:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68384) in GitLab 14.3.
 
 For [integrated error tracking](https://gitlab.com/gitlab-org/gitlab/-/issues/329596) feature. Only for users with the
-[Maintainer role](../user/permissions.md) for the project.
+Maintainer role for the project.
 
 ### List project client keys
 

doc/api/group_clusters.md

@@ -17,7 +17,7 @@ Similarly to [project-level](../user/project/clusters/index.md) and
 group-level Kubernetes clusters allow you to connect a Kubernetes cluster to
 your group, enabling you to use the same cluster across multiple projects.
 
-Users need at least the [Maintainer role](../user/permissions.md) for the group to use these endpoints.
+Users need at least the Maintainer role for the group to use these endpoints.
 
 ## List group clusters
 

doc/api/groups.md

@@ -808,7 +808,7 @@ Parameters:
 
 ### Options for `default_branch_protection`
 
-The `default_branch_protection` attribute determines whether users with the Developer or [Maintainer role](../user/permissions.md) can push to the applicable [default branch](../user/project/repository/branches/default.md), as described in the following table:
+The `default_branch_protection` attribute determines whether users with the Developer or Maintainer role can push to the applicable [default branch](../user/project/repository/branches/default.md), as described in the following table:
 
 | Value | Description |
 |-------|-------------------------------------------------------------------------------------------------------------|

doc/api/integrations.md

@@ -13,7 +13,7 @@ In GitLab 14.4, the `services` endpoint was [renamed](https://gitlab.com/gitlab-
 Calls to the Integrations API can be made to both `/projects/:id/services` and `/projects/:id/integrations`.
 The examples in this document refer to the endpoint at `/projects/:id/integrations`.
 
-This API requires an access token with the [Maintainer or Owner role](../user/permissions.md).
+This API requires an access token with the Maintainer or Owner role.
 
 ## List all active integrations
 

doc/api/project_clusters.md

@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 WARNING:
 This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
 
-Users need at least the [Maintainer](../user/permissions.md) role to use these endpoints.
+Users need at least the Maintainer role to use these endpoints.
 
 ## List project clusters
 

doc/api/project_snippets.md

@@ -246,7 +246,7 @@ curl "https://gitlab.com/api/v4/projects/1/snippets/2/files/master/snippet%2Erb/
 
 ## Get user agent details
 
-Available only for users with the Administrator [role](../user/permissions.md).
+Available only for users with the Administrator role.
 
 ```plaintext
 GET /projects/:id/snippets/:snippet_id/user_agent_detail

doc/api/projects.md

@@ -1434,7 +1434,7 @@ Supported attributes:
 | `request_access_enabled`                                    | boolean        | **{dotted-circle}** No | Allow users to request member access. |
 | `requirements_access_level`                                 | string         | **{dotted-circle}** No | One of `disabled`, `private`, `enabled` or `public` |
 | `resolve_outdated_diff_discussions`                         | boolean        | **{dotted-circle}** No | Automatically resolve merge request diffs discussions on lines changed with a push. |
-| `restrict_user_defined_variables`                           | boolean        | **{dotted-circle}** No | Allow only users with the [Maintainer role](../user/permissions.md) to pass user-defined variables when triggering a pipeline. For example when the pipeline is triggered in the UI, with the API, or by a trigger token. |
+| `restrict_user_defined_variables`                           | boolean        | **{dotted-circle}** No | Allow only users with the Maintainer role to pass user-defined variables when triggering a pipeline. For example when the pipeline is triggered in the UI, with the API, or by a trigger token. |
 | `service_desk_enabled`                                      | boolean        | **{dotted-circle}** No | Enable or disable Service Desk feature. |
 | `shared_runners_enabled`                                    | boolean        | **{dotted-circle}** No | Enable shared runners for this project. |
 | `show_default_award_emojis`                                 | boolean        | **{dotted-circle}** No | Show default award emojis. |

doc/api/runners.md

@@ -178,7 +178,7 @@ To view more than the first 20 runners, use [pagination](index.md#pagination).
 
 Get details of a runner.
 
-At least the [Maintainer role](../user/permissions.md) is required to get runner details at the
+At least the Maintainer role is required to get runner details at the
 project and group level.
 
 Instance-level runner details via this endpoint are available to all signed in users.

doc/api/suggestions.md

@@ -13,8 +13,8 @@ Every API call to suggestions must be authenticated.
 
 ## Applying suggestions
 
-Applies a suggested patch in a merge request. Users must be
-at least [Developer](../user/permissions.md) to perform such action.
+Applies a suggested patch in a merge request. Users must have
+at least the Developer role to perform such action.
 
 ```plaintext
 PUT /suggestions/:id/apply

doc/ci/chatops/index.md

@@ -43,7 +43,7 @@ job completes:
   [Slack API](https://api.slack.com/) to send data to the channel.
 
 To use the `run` command, you must have at least the
-[Developer role](../../user/permissions.md#project-members-permissions).
+Developer role.
 If a job shouldn't be able to be triggered from chat, you can set the job to `except: [chat]`.
 
 ## Best practices for ChatOps CI jobs
@@ -55,7 +55,7 @@ functions available. Consider these best practices when creating ChatOps jobs:
   of the standard CI pipeline.
 - If the job is set to `when: manual`, ChatOps creates the pipeline, but the job waits to be started.
 - ChatOps provides limited support for access control. If the user triggering the
-  slash command has at least the [Developer role](../../user/permissions.md#project-members-permissions)
+  slash command has at least the Developer role
   in the project, the job runs. The job itself can use existing
   [CI/CD variables](../variables/index.md#predefined-cicd-variables) like
   `GITLAB_USER_ID` to perform additional rights validation, but

doc/ci/environments/deployment_approvals.md

@@ -66,7 +66,7 @@ curl --header 'Content-Type: application/json' --request POST \
 ```
 
 To protect, update, or unprotect an environment, you must have at least the
-[Maintainer role](../../user/permissions.md).
+Maintainer role.
 
 ## Approve or reject a deployment
 

doc/ci/environments/deployment_safety.md

@@ -26,7 +26,7 @@ If you are using a continuous deployment workflow and want to ensure that concur
 ## Restrict write access to a critical environment
 
 By default, environments can be modified by any team member that has at least the
-[Developer role](../../user/permissions.md#project-members-permissions).
+Developer role.
 If you want to restrict write access to a critical environment (for example a `production` environment),
 you can set up [protected environments](protected_environments.md).
 
@@ -119,7 +119,7 @@ The other pipelines don't get the protected variable. You can also
 We recommend that you use protected variables on protected environments to make sure that the
 secrets aren't exposed unintentionally. You can also define production secrets on the
 [runner side](../runners/configure_runners.md#prevent-runners-from-revealing-sensitive-information).
-This prevents other users with the [Maintainer role](../../user/permissions.md) from reading the secrets and makes sure
+This prevents other users with the Maintainer role from reading the secrets and makes sure
 that the runner only runs on protected branches.
 
 For more information, see [pipeline security](../pipelines/index.md#pipeline-security-on-protected-branches).

doc/ci/environments/index.md

@@ -27,7 +27,7 @@ You can even access a [web terminal](#web-terminals-deprecated) for your environ
 
 Prerequisites:
 
-- You must have at least the Reporter [role](../../user/permissions.md#project-members-permissions).
+- You must have at least the Reporter role.
 
 To view a list of environments and deployments:
 

doc/ci/environments/protected_environments.md

@@ -20,7 +20,7 @@ NOTE:
 GitLab administrators can use all environments, including protected environments.
 
 To protect, update, or unprotect an environment, you need to have at least the
-[Maintainer role](../../user/permissions.md).
+Maintainer role.
 
 ## Protecting environments
 
@@ -103,12 +103,12 @@ The group now has access and can be seen in the UI.
 ## Environment access by group membership
 
 A user may be granted access to protected environments as part of [group membership](../../user/group/index.md). Users
-with the Reporter [role](../../user/permissions.md) can only be granted access to protected environments with this
+with the Reporter role can only be granted access to protected environments with this
 method.
 
 ## Deployment branch access
 
-Users with the [Developer role](../../user/permissions.md) can be granted
+Users with the Developer role can be granted
 access to a protected environment through any of these methods:
 
 - As an individual contributor, through a role.
@@ -125,7 +125,7 @@ they have the following privileges:
 
 Users granted access to a protected environment, but not push or merge access
 to the branch deployed to it, are only granted access to deploy the environment. An individual in a
-group with the Reporter [role](../../user/permissions.md), or in groups added to the project with the Reporter
+group with the Reporter role, or in groups added to the project with the Reporter
 role, appears in the dropdown menu for deployment-only access.
 
 To add deployment-only access:
@@ -136,7 +136,7 @@ To add deployment-only access:
 1. Follow the steps in [Protecting Environments](#protecting-environments).
 
 Note that deployment-only access is the only possible access level for groups with the Reporter
-[role](../../user/permissions.md).
+role.
 
 ## Modifying and unprotecting environments
 
@@ -194,14 +194,14 @@ and are protected at the same time.
 In an enterprise organization, with thousands of projects under a single group,
 ensuring that all of the [project-level protected environments](#protecting-environments)
 are properly configured is not a scalable solution. For example, a developer
-might gain privileged access to a higher environment when they are given the [Maintainer role](../../user/permissions.md)
+might gain privileged access to a higher environment when they are given the Maintainer role
 for a new project. Group-level protected environments can be a solution in this situation.
 
 To maximize the effectiveness of group-level protected environments,
 [group-level memberships](../../user/group/index.md) must be correctly
 configured:
 
-- Operators should be given at least the [Maintainer role](../../user/permissions.md)
+- Operators should be given at least the Maintainer role
   for the top-level group. They can maintain CI/CD configurations for
   the higher environments (such as production) in the group-level settings page,
   which includes group-level protected environments,
@@ -210,8 +210,8 @@ configured:
   configurations are inherited to the child projects as read-only entries.
   This ensures that only operators can configure the organization-wide
   deployment ruleset.
-- Developers should be given no more than the [Developer role](../../user/permissions.md)
-  for the top-level group, or explicitly given the [Maintainer role](../../user/permissions.md) for a child project
+- Developers should be given no more than the Developer role
+  for the top-level group, or explicitly given the Maintainer role for a child project
   They do *NOT* have access to the CI/CD configurations in the
   top-level group, so operators can ensure that the critical configuration won't
   be accidentally changed by the developers.
@@ -224,7 +224,7 @@ configured:
     environment configurations exist, to run a deployment job, the user must be allowed in **both**
     rulesets.
   - In a project or a subgroup of the top-level group, developers can be
-    safely assigned the [Maintainer role](../../user/permissions.md) to tune their lower environments (such
+    safely assigned the Maintainer role to tune their lower environments (such
     as `testing`).
 
 Having this configuration in place:

doc/ci/jobs/ci_job_token.md

@@ -94,7 +94,7 @@ The job token scope is only for controlling access to private projects.
 1. Expand **Token Access**.
 1. Toggle **Limit CI_JOB_TOKEN access** to enabled.
 1. Optional. Add existing projects to the token's access scope. The user adding a
-   project must have the [maintainer role](../../user/permissions.md) in both projects.
+   project must have the Maintainer role in both projects.
 
 There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559) to improve
 the feature with more strategic control of the access permissions.

doc/ci/pipelines/index.md

@@ -281,7 +281,7 @@ pipelines.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24851) in GitLab 12.7.
 
-Users with the [Owner role](../../user/permissions.md) in a project can delete a pipeline
+Users with the Owner role for a project can delete a pipeline
 by clicking on the pipeline in the **CI/CD > Pipelines** to get to the **Pipeline Details**
 page, then using the **Delete** button.
 

doc/ci/pipelines/job_artifacts.md

@@ -259,7 +259,7 @@ You can delete a single job, which also removes the job's
 artifacts and log. You must be:
 
 - The owner of the job.
-- A [maintainer](../../user/permissions.md#gitlab-cicd-permissions) of the project.
+- A Maintainer of the project.
 
 To delete a job:
 

doc/ci/pipelines/merge_request_pipelines.md

@@ -58,7 +58,7 @@ To use merge request pipelines:
   jobs that run in merge request pipelines. To do this, you can use:
   - [`rules`](#use-rules-to-add-jobs).
   - [`only/except`](#use-only-to-add-jobs).
-- You must have at least the Developer [role](../../user/permissions.md) in the
+- You must have at least the Developer role in the
   source project to run a merge request pipeline.
 - Your repository must be a GitLab repository, not an [external repository](../ci_cd_for_external_repos/index.md).
 
@@ -142,7 +142,7 @@ parent project when the pipeline runs, even before merge. As a reviewer, careful
 check the changes in the merge request before triggering the pipeline. GitLab shows
 a warning that you must accept before you can trigger the pipeline.
 
-Parent project members with at least the [Developer role](../../user/permissions.md)
+Parent project members with at least the Developer role
 can create pipelines in the parent project for merge requests from a forked project:
 
 1. In the merge request, go to the **Pipelines** tab.

doc/ci/pipelines/merge_trains.md

@@ -67,7 +67,7 @@ branch](https://www.youtube.com/watch?v=D4qCqXgZkHQ).
 
 To enable merge trains:
 
-- You must have the [Maintainer role](../../user/permissions.md).
+- You must have the Maintainer role.
 - You must be using [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) 11.9 or later.
 - In GitLab 13.0 and later, you need [Redis](https://redis.io/) 5.0 or later.
 - Your repository must be a GitLab repository, not an

doc/ci/pipelines/merged_results_pipelines.md

@@ -40,7 +40,7 @@ To use merged results pipelines:
 ## Enable merged results pipelines
 
 To enable merged results pipelines in a project, you must have at least the
-[Maintainer role](../../user/permissions.md):
+Maintainer role:
 
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > General**.

doc/ci/pipelines/multi_project_pipelines.md

@@ -283,7 +283,7 @@ tag in a different project.
 Prerequisites:
 
 - The upstream project must be [public](../../public_access/public_access.md).
-- The user must have the [Developer role](../../user/permissions.md#project-members-permissions)
+- The user must have the Developer role
   in the upstream project.
 
 To trigger the pipeline when the upstream project is rebuilt:

doc/ci/quick_start/index.md

@@ -12,7 +12,7 @@ Use this document to get started with [GitLab CI/CD](../index.md).
 Before you start, make sure you have:
 
 - A project in GitLab that you would like to use CI/CD for.
-- The [Maintainer or Owner role](../../user/permissions.md) for the project.
+- The Maintainer or Owner role for the project.
 
 If you are migrating from another CI/CD tool, view this documentation:
 

doc/ci/resource_groups/index.md

@@ -58,7 +58,7 @@ can still run `build` jobs concurrently for maximizing the pipeline efficiency.
 
 - The basic knowledge of the [GitLab CI/CD pipelines](../pipelines/index.md)
 - The basic knowledge of the [GitLab Environments and Deployments](../environments/index.md)
-- [Developer role](../../user/permissions.md) (or above) in the project to configure CI/CD pipelines.
+- At least the Developer role for the project to configure CI/CD pipelines.
 
 ### Limitations
 

doc/ci/review_apps/index.md

@@ -73,7 +73,7 @@ you can copy and paste into `.gitlab-ci.yml` as a starting point.
 
 Prerequisite:
 
-- You need at least the Developer [role](../../user/permissions.md) for the project.
+- You need at least the Developer role for the project.
 
 To use the Review Apps template:
 

doc/ci/runners/configure_runners.md

@@ -160,7 +160,7 @@ the GitLab instance. To determine this:
 ### Determine the IP address of a specific runner
 
 To can find the IP address of a runner for a specific project,
-you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the
+you must have the Owner role for the
 project.
 
 1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
@@ -187,7 +187,7 @@ the appropriate dependencies to run Rails test suites.
 
 When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
 [tagged jobs](../yaml/index.md#tags).
-To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
+To change this, you must have the Owner role for the project.
 
 To make a runner pick untagged jobs:
 

doc/ci/runners/runners_scope.md

@@ -55,7 +55,7 @@ To enable shared runners:
 ### Disable shared runners
 
 You can disable shared runners for individual projects or for groups.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the project
+You must have the Owner role for the project
 or group.
 
 To disable shared runners for a project:
@@ -144,7 +144,7 @@ Group runners process jobs by using a first in, first out ([FIFO](https://en.wik
 ### Create a group runner
 
 You can create a group runner for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
+You must have the Owner role for the group.
 
 To create a group runner:
 
@@ -160,7 +160,7 @@ To create a group runner:
 
 You can view and manage all runners for a group, its subgroups, and projects.
 You can do this for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
+You must have the Owner role for the group.
 
 1. Go to the group where you want to view the runners.
 1. Go to **Settings > CI/CD** and expand the **Runners** section.
@@ -183,7 +183,7 @@ From this page, you can edit, pause, and remove runners from the group, its subg
 ### Pause or remove a group runner
 
 You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
+You must have the Owner role for the group.
 
 1. Go to the group you want to remove or pause the runner for.
 1. Go to **Settings > CI/CD** and expand the **Runners** section.
@@ -213,7 +213,7 @@ A fork *does* copy the CI/CD settings of the cloned repository.
 ### Create a specific runner
 
 You can create a specific runner for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
+You must have the Owner role for the project.
 
 To create a specific runner:
 
@@ -227,7 +227,7 @@ To create a specific runner:
 A specific runner is available in the project it was created for. An administrator can
 enable a specific runner to apply to additional projects.
 
-- You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the
+- You must have the Owner role for the
   project.
 - The specific runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects).
 

doc/ci/test_cases/index.md

@@ -20,7 +20,7 @@ use external test planning tools, which require additional overhead, context swi
 
 Prerequisite:
 
-- You must have at least the Reporter [role](../../user/permissions.md).
+- You must have at least the Reporter role.
 
 To create a test case in a GitLab project:
 
@@ -36,7 +36,7 @@ issue list with a search query, including labels or the test case's title.
 
 Prerequisite:
 
-- You must have at least the Guest [role](../../user/permissions.md).
+- You must have at least the Guest role.
 
 To view a test case:
 
@@ -51,7 +51,7 @@ You can edit a test case's title and description.
 
 Prerequisite:
 
-- You must have at least the Reporter [role](../../user/permissions.md).
+- You must have at least the Reporter role.
 - Users demoted to the Guest role can continue to edit the test cases they created
 when they were in the higher role.
 
@@ -68,7 +68,7 @@ When you want to stop using a test case, you can archive it. You can [reopen an
 
 Prerequisite:
 
-- You must have at least the Reporter [role](../../user/permissions.md).
+- You must have at least the Reporter role.
 
 To archive a test case, on the test case's page, select the **Archive test case** button.
 
@@ -81,6 +81,6 @@ To view archived test cases:
 
 If you decide to start using an archived test case again, you can reopen it.
 
-You must have at least the Reporter [role](../../user/permissions.md).
+You must have at least the Reporter role.
 
 To reopen an archived test case, on the test case's page, select **Reopen test case**.

doc/ci/triggers/index.md

@@ -22,7 +22,7 @@ to authenticate an API call. The token impersonates a user's project access and
 
 Prerequisite:
 
-- You must have at least the [Maintainer role](../../user/permissions.md) for the project.
+- You must have at least the Maintainer role for the project.
 
 To create a trigger token:
 

doc/ci/variables/index.md

@@ -154,7 +154,7 @@ job:
 ### Add a CI/CD variable to a project
 
 You can add CI/CD variables to a project's settings. Only project members with the
-[Maintainer role](../../user/permissions.md#project-members-permissions)
+Maintainer role
 can add or update project CI/CD variables. To keep a CI/CD variable secret, put it
 in the project settings, not in the `.gitlab-ci.yml` file.
 
@@ -233,7 +233,7 @@ inherited.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299879) in GitLab 13.11.
 
 To make a CI/CD variable available to all projects and groups in a GitLab instance,
-add an instance CI/CD variable. You must have the [Administrator role](../../user/permissions.md).
+add an instance CI/CD variable. You must have the Administrator access level.
 
 You can define instance variables via the UI or [API](../../api/instance_level_ci_variables.md).
 
@@ -900,7 +900,7 @@ if [[ -d "/builds/gitlab-examples/ci-debug-trace/.git" ]]; then
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292661) in GitLab 13.8.
 
 You can restrict access to debug logging. When restricted, only users with
-[developer or higher permissions](../../user/permissions.md#project-members-permissions)
+at least the Developer role
 can view job logs when debug logging is enabled with a variable in:
 
 - The [`.gitlab-ci.yml` file](#create-a-custom-cicd-variable-in-the-gitlab-ciyml-file).

doc/development/documentation/workflow.md

@@ -79,7 +79,7 @@ A member of the Technical Writing team adds these labels:
 
 ### Reviewing and merging
 
-Anyone with the [Maintainer role](../../user/permissions.md) to the relevant GitLab project can
+Anyone with the Maintainer role to the relevant GitLab project can
 merge documentation changes. Maintainers must make a good-faith effort to ensure that the content:
 
 - Is clear and sufficiently easy for the intended audience to navigate and understand.

doc/development/policies.md

@@ -111,7 +111,7 @@ Each line represents a rule that was evaluated. There are a few things to note:
 
 Here you can see that the first four rules were evaluated `false` for
 which user and subject. For example, you can see in the last line that
-the rule was activated because the user `john` had the Reporter [role](../user/permissions.md) on
+the rule was activated because the user `john` had the Reporter role on
 `Project/4`.
 
 When a policy is asked whether a particular ability is allowed

doc/development/testing_guide/end_to_end/index.md

@@ -101,7 +101,7 @@ This is due to technical limitations in the GitLab permission model: the ability
 against a protected branch is controlled by the ability to push/merge to this branch.
 This means that for developers to be able to trigger a pipeline for the default branch in
 `gitlab-org/omnibus-gitlab`/`gitlab-org/gitlab-qa`, they would need to have the
-[Maintainer role](../../../user/permissions.md) for those projects.
+Maintainer role for those projects.
 For security reasons and implications, we couldn't open up the default branch to all the Developers.
 Hence we created these mirrors where Developers and Maintainers are allowed to push/merge to the default branch.
 This problem was discovered in <https://gitlab.com/gitlab-org/gitlab-qa/-/issues/63#note_107175160> and the "mirror"

doc/integration/datadog.md

@@ -26,7 +26,7 @@ project, group, or instance level:
       Copy this value, as you need it in a later step.
 1. *For project-level or group-level integrations:* In GitLab, go to your project or group.
 1. *For instance-level integrations:*
-   1. Sign in to GitLab as a user with the [Administrator role](../user/permissions.md).
+   1. Sign in to GitLab as a user with the Administrator access level.
    1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > Integrations**.
 1. Scroll to **Add an integration**, and select **Datadog**.

doc/integration/jira/connect-app.md

@@ -23,7 +23,7 @@ We recommend the GitLab.com for Jira Cloud app, because data is
 synchronized in real time. The DVCS connector updates data only once per hour.
 
 The user configuring the GitLab.com for Jira Cloud app must have
-at least the [Maintainer](../../user/permissions.md) role in the GitLab.com namespace.
+at least the Maintainer role in the GitLab.com namespace.
 
 This integration method supports [Smart Commits](dvcs.md#smart-commits).
 
@@ -43,7 +43,7 @@ To install the GitLab.com for Jira Cloud app:
 
    ![Start GitLab.com app configuration on Jira Cloud](img/jira_dev_panel_setup_com_2.png)
 1. If not already signed in to GitLab.com, you must sign in as a user with
-   [Maintainer](../../user/permissions.md) permissions to add namespaces.
+   the Maintainer role to add namespaces.
 
    ![Sign in to GitLab.com in GitLab.com for Jira Cloud app](img/jira_dev_panel_setup_com_3_v13_9.png)
 1. To open the list of available namespaces, select **Add namespace**.

doc/operations/incident_management/alerts.md

@@ -10,7 +10,7 @@ Alerts are a critical entity in your incident management workflow. They represen
 
 ## Alert List
 
-Users with at least the Developer [role](../../user/permissions.md) can
+Users with at least the Developer role can
 access the Alert list at **Monitor > Alerts** in your project's
 sidebar. The Alert list displays alerts sorted by start time, but
 you can change the sort order by clicking the headers in the Alert list.
@@ -68,7 +68,7 @@ Alerts contain one of the following icons:
 ## Alert details page
 
 Navigate to the Alert details view by visiting the [Alert list](alerts.md)
-and selecting an alert from the list. You need at least the Developer [role](../../user/permissions.md)
+and selecting an alert from the list. You need at least the Developer role
 to access alerts.
 
 NOTE:
@@ -96,7 +96,7 @@ instance.
 
 Prerequisite:
 
-- You must have at least the Developer [role](../../user/permissions.md).
+- You must have at least the Developer role.
 
 To view the metrics for an alert:
 
@@ -120,7 +120,7 @@ your application's performance and how to resolve any problems.
 
 Prerequisite:
 
-- You must have at least the Developer [role](../../user/permissions.md).
+- You must have at least the Developer role.
 
 To view the logs for an alert:
 

doc/operations/incident_management/escalation_policies.md

@@ -17,7 +17,7 @@ where you manage [On-call schedules](oncall_schedules.md).
 
 Prerequisite:
 
-- You must have at least the Maintainer [role](../../user/permissions.md).
+- You must have at least the Maintainer role.
 - You must have an [on-call schedule](oncall_schedules.md).
 
 To create an escalation policy:

doc/operations/incident_management/incidents.md

@@ -47,7 +47,7 @@ To create an incident from the Issues List:
 
 ### Create incidents automatically **(ULTIMATE)**
 
-With at least the Maintainer [role](../../user/permissions.md), you can enable
+With at least the Maintainer role, you can enable
  GitLab to create incident automatically whenever an alert is triggered:
 
 1. Navigate to **Settings > Monitor > Incidents** and expand **Incidents**.
@@ -55,7 +55,7 @@ With at least the Maintainer [role](../../user/permissions.md), you can enable
 1. To customize the incident, select an
    [issue template](../../user/project/description_templates.md#create-an-issue-template).
 1. To send [an email notification](paging.md#email-notifications) to users
-   with the Developer [role](../../user/permissions.md), select
+   with the Developer role, select
    **Send a separate email notification to Developers**. Email notifications are
    also sent to users with the **Maintainer** and **Owner** roles.
 1. Click **Save changes**.
@@ -68,7 +68,7 @@ You can set up a webhook with PagerDuty to automatically create a GitLab inciden
 for each PagerDuty incident. This configuration requires you to make changes
 in both PagerDuty and GitLab:
 
-1. Sign in as a user with the Maintainer [role](../../user/permissions.md).
+1. Sign in as a user with the Maintainer role.
 1. Navigate to **Settings > Monitor > Incidents** and expand **Incidents**.
 1. Select the **PagerDuty integration** tab:
 
@@ -276,7 +276,7 @@ templates.
 > - [Introduced for Prometheus Integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/13401) in GitLab 12.5.
 > - [Introduced for HTTP Integrations](https://gitlab.com/gitlab-org/gitlab/-/issues/13402) in GitLab 13.4.
 
-With at least the Maintainer [role](../../user/permissions.md), you can enable
+With at least the Maintainer role, you can enable
  GitLab to close an incident automatically when a **Recovery Alert** is received:
 
 1. Navigate to **Settings > Monitor > Incidents** and expand **Incidents**.

doc/operations/incident_management/integrations.md

@@ -18,7 +18,7 @@ to use this endpoint.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/245331) in GitLab 13.5.
 
-With at least the Maintainer [role](../../user/permissions.md), you can view the list of configured
+With at least the Maintainer role, you can view the list of configured
 alerts integrations by navigating to **Settings > Monitor**
 in your project's sidebar menu, and expanding the **Alerts** section. The list displays
 the integration name, type, and status (enabled or disabled):
@@ -36,7 +36,7 @@ Enabling the HTTP Endpoint in a GitLab projects activates it to
 receive alert payloads in JSON format. You can always
 [customize the payload](#customize-the-alert-payload-outside-of-gitlab) to your liking.
 
-1. Sign in to GitLab as a user with the Maintainer [role](../../user/permissions.md)
+1. Sign in to GitLab as a user with the Maintainer role
    for a project.
 1. Navigate to **Settings > Monitor** in your project.
 1. Expand the **Alerts** section, and in the **Select integration type** dropdown menu,
@@ -53,7 +53,7 @@ In [GitLab Premium](https://about.gitlab.com/pricing/), you can create multiple
 unique HTTP endpoints to receive alerts from any external source in JSON format,
 and you can [customize the payload](#customize-the-alert-payload-outside-of-gitlab).
 
-1. Sign in to GitLab as a user with the Maintainer [role](../../user/permissions.md)
+1. Sign in to GitLab as a user with the Maintainer role
    for a project.
 1. Navigate to **Settings > Monitor** in your project.
 1. Expand the **Alerts** section.
@@ -225,7 +225,7 @@ After a [project maintainer or owner](../../user/permissions.md)
 configures an integration, you can trigger a test
 alert to confirm your integration works properly.
 
-1. Sign in as a user with at least the Developer [role](../../user/permissions.md).
+1. Sign in as a user with at least the Developer role.
 1. Navigate to **Settings > Monitor** in your project.
 1. Click **Alerts** to expand the section.
 1. Click the **{settings}** settings icon on the right side of the integration in [the list](#integrations-list).
@@ -279,7 +279,7 @@ active at the same time.
 
 To enable Opsgenie integration:
 
-1. Sign in as a user with the Maintainer or Owner [role](../../user/permissions.md).
+1. Sign in as a user with the Maintainer or Owner role.
 1. Navigate to **Monitor > Alerts**.
 1. In the **Integrations** select box, select **Opsgenie**.
 1. Select the **Active** toggle.

doc/operations/incident_management/oncall_schedules.md

@@ -24,7 +24,7 @@ Set up an on-call schedule for your team to add rotations to.
 
 Prerequisite:
 
-- You must have at least the Maintainer [role](../../user/permissions.md).
+- You must have at least the Maintainer role.
 
 To create an on-call schedule:
 

doc/operations/incident_management/status_page.md

@@ -41,7 +41,7 @@ Only AWS S3 is supported as a deploy target.
 
 Prerequisite:
 
-- You must have at least the Maintainer [role](../../user/permissions.md).
+- You must have at least the Maintainer role.
 
 To provide GitLab with the AWS account information needed to push content to your Status Page:
 

doc/operations/metrics/alerts.md

@@ -99,8 +99,7 @@ GitLab tags each incident issue with the `incident` label automatically. If the
 does not yet exist, it is also created automatically.
 
 If the metric exceeds the threshold of the alert for over 5 minutes, GitLab sends
-an email to all [Maintainers and Owners](../../user/permissions.md#project-members-permissions)
-of the project.
+an email to all Maintainers and Owners of the project.
 
 ### Recovery alerts
 

doc/operations/metrics/embed.md

@@ -53,7 +53,7 @@ The following requirements must be met for the metric to unfurl:
 - The `<environment_id>` must correspond to a real environment.
 - Prometheus must be monitoring the environment.
 - The GitLab instance must be configured to receive data from the environment.
-- The user must be allowed access to the monitoring dashboard for the environment ([Reporter or higher](../../user/permissions.md)).
+- The user must have at least the Reporter role for the monitoring dashboard for the environment.
 - The dashboard must have data within the last 8 hours.
 
  If all of the above are true, then the metric unfurls as seen below:

doc/operations/product_analytics.md

@@ -50,7 +50,7 @@ Feature.disable(:product_analytics, Project.find(<project ID>))
 After enabling the feature flag for Product Analytics, you can access the
 user interface:
 
-1. Sign in to GitLab as a user with at least the Reporter [role](../user/permissions.md).
+1. Sign in to GitLab as a user with at least the Reporter role.
 1. Navigate to **Monitor > Product Analytics**.
 
 The user interface contains:

doc/public_access/public_access.md

@@ -7,7 +7,7 @@ type: reference
 
 # Project and group visibility **(FREE)**
 
-GitLab allows users with the Owner [role](../user/permissions.md) to set a project's or group's visibility as:
+GitLab allows users with the Owner role to set a project's or group's visibility as:
 
 - **Public**
 - **Internal**
@@ -24,7 +24,7 @@ Public projects can be cloned **without any** authentication over HTTPS.
 
 They are listed in the public access directory (`/public`) for all users.
 
-**Any signed-in user** has the Guest [role](../user/permissions.md) on the repository.
+**Any signed-in user** has the Guest role on the repository.
 
 NOTE:
 By default, `/public` is visible to unauthenticated users. However, if the
@@ -39,7 +39,7 @@ Internal projects can be cloned by any signed-in user except
 They are also listed in the public access directory (`/public`), but only for signed-in users.
 
 Any signed-in users except [external users](../user/permissions.md#external-users) have the
-Guest [role](../user/permissions.md) on the repository.
+Guest role on the repository.
 
 NOTE:
 From July 2019, the `Internal` visibility setting is disabled for new projects, groups,
@@ -57,7 +57,7 @@ They appear in the public access directory (`/public`) for project members only.
 
 Prerequisite:
 
-- You must have the Owner [role](../user/permissions.md) for a project.
+- You must have the Owner role for a project.
 
 1. On the top bar, select **Menu > Projects** and find your project.
 1. On the left sidebar, select **Settings > General**.
@@ -69,7 +69,7 @@ Prerequisite:
 
 Prerequisite:
 
-- You must have the Owner [role](../user/permissions.md) for a group.
+- You must have the Owner role for a group.
 
 1. On the top bar, select **Menu > Groups** and find your project.
 1. On the left sidebar, select **Settings > General**.

doc/subscriptions/gitlab_com/index.md

@@ -44,7 +44,7 @@ To subscribe to GitLab SaaS:
 
 Prerequisite:
 
-- You must have the Owner [role](../../user/permissions.md) for the group.
+- You must have the Owner role for the group.
 
 To see the status of your GitLab SaaS subscription:
 

doc/subscriptions/index.md

@@ -150,7 +150,7 @@ To change the namespace linked to a subscription:
 1. Navigate to the **Manage Purchases** page.
 1. Select **Change linked namespace**.
 1. Select the desired group from the **This subscription is for** dropdown. For a group to appear
-   here, you must have the Owner [role](../user/permissions.md)
+   here, you must have the Owner role
    for that group.
 1. Select **Proceed to checkout**.
 

doc/topics/git/lfs/migrate_to_git_lfs.md

@@ -46,7 +46,7 @@ Before beginning, make sure:
 
 To follow this tutorial, you need:
 
-- The [Maintainer role](../../../user/permissions.md) for the existing Git repository
+- The Maintainer role for the existing Git repository
   you'd like to migrate to LFS with access through the command line.
 - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
   and [Java Runtime Environment](https://www.java.com/en/download/manual.jsp)

doc/topics/gitlab_flow.md

@@ -221,7 +221,7 @@ If the assigned person does not feel comfortable, they can request more changes
 
 In GitLab, it is common to protect the long-lived branches, such as the `main` branch, so [most developers can't modify them](../user/permissions.md).
 So, if you want to merge into a protected branch, assign your merge request to someone with the
-[Maintainer role](../user/permissions.md).
+Maintainer role.
 
 After you merge a feature branch, you should remove it from the source control software.
 In GitLab, you can do this when merging.

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -7,12 +7,12 @@ type: reference
 
 # Control access and visibility **(FREE SELF)**
 
-GitLab enables users with the [Administrator role](../../permissions.md) to enforce
+GitLab enables users with the Administrator access level to enforce
 specific controls on branches, projects, snippets, groups, and more.
 
 To access the visibility and access control options:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -29,7 +29,7 @@ or configure [branch protection for groups](../../group/index.md#change-the-defa
 
 To change the default branch protection for the entire instance:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -55,7 +55,7 @@ can be overridden on a per-group basis by the group's owner. In
 [GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can
 disable this privilege for group owners, enforcing the instance-level protection rule:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -71,7 +71,7 @@ Instance-level protections for project creation define which roles can
 [add projects to a group](../../group/index.md#specify-who-can-add-projects-to-a-group)
 on the instance. To alter which roles have permission to create projects:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -86,7 +86,7 @@ on the instance. To alter which roles have permission to create projects:
 Anyone with the **Owner** role, either at the project or group level, can
 delete a project. To allow only users with the Administrator role to delete projects:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -137,7 +137,7 @@ Alternatively, projects that are marked for removal can be deleted immediately.
 
 To set the default [visibility levels for new projects](../../../public_access/public_access.md):
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -152,7 +152,7 @@ To set the default [visibility levels for new projects](../../../public_access/p
 
 To set the default visibility levels for new [snippets](../../snippets.md):
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -166,7 +166,7 @@ For more details on snippet visibility, read
 
 To set the default visibility levels for new groups:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -183,7 +183,7 @@ For more details on group visibility, see
 
 To restrict visibility levels for projects, snippets, and selected pages:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -200,7 +200,7 @@ For more details on project visibility, see
 
 You can specify from which hosting sites users can [import their projects](../../project/import/index.md):
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -212,7 +212,7 @@ You can specify from which hosting sites users can [import their projects](../..
 To enable the export of
 [projects and their data](../../../user/project/settings/import_export.md#export-a-project-and-its-data):
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.
@@ -228,7 +228,7 @@ The GitLab restrictions apply at the application level.
 
 To specify the enabled Git access protocols:
 
-1. Sign in to GitLab as a user with [Administrator role](../../permissions.md).
+1. Sign in to GitLab as a user with Administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. On the left sidebar, select **Settings > General**.
 1. Expand the **Visibility and access controls** section.

doc/user/analytics/code_review_analytics.md

@@ -17,7 +17,7 @@ requests, and:
 - Take action on individual merge requests.
 - Reduce overall cycle time.
 
-Code Review Analytics is available to users with at least the Reporter [role](../permissions.md), and displays a table of open merge requests that have at least one non-author comment. The review time is measured from the time the first non-author comment was submitted.
+Code Review Analytics is available to users with at least the Reporter role, and displays a table of open merge requests that have at least one non-author comment. The review time is measured from the time the first non-author comment was submitted.
 
 NOTE:
 Initially, no data appears. Data is populated as users comment on open merge requests.

doc/user/analytics/merge_request_analytics.md

@@ -116,4 +116,4 @@ bookmark for those preferred settings in your browser.
 The **Merge Request Analytics** feature can be accessed only:
 
 - On [GitLab Premium](https://about.gitlab.com/pricing/) and above.
-- By users with at least the Reporter [role](../permissions.md).
+- By users with at least the Reporter role.

doc/user/analytics/productivity_analytics.md

@@ -103,4 +103,4 @@ You can filter analytics based on a date range. To filter results:
 The **Productivity Analytics** dashboard can be accessed only:
 
 - On [GitLab Premium](https://about.gitlab.com/pricing/) and above.
-- By users with at least the Reporter [role](../permissions.md).
+- By users with at least the Reporter role.

doc/user/application_security/index.md

@@ -218,7 +218,7 @@ An approval is optional when the security report:
   the rule's severity levels.
 - Contains a vulnerability count equal to or less than what the rule allows.
 
-Project members assigned [at least the Maintainer role](../permissions.md#project-members-permissions) can enable or edit
+Project members with at least the Maintainer role can enable or edit
 the Vulnerability-Check rule.
 
 #### Enable the Vulnerability-Check rule

doc/user/clusters/agent/install/index.md

@@ -157,7 +157,7 @@ information to the cluster automatically without downtime.
 
 ## View your Agents
 
-If you have the [Developer role](../../../permissions.md) or above, you can access the Agent's
+If you have at least the Developer role, you can access the Agent's
 configuration repository and view the Agent's list:
 
 1. On the left sidebar, select **Infrastructure > Kubernetes clusters**.

doc/user/clusters/cost_management.md

@@ -22,7 +22,7 @@ insights within GitLab:
 
 ## Configure cluster cost management
 
-To get started with cluster cost management, you need the [Maintainer role](../permissions.md) in a project or group.
+To get started with cluster cost management, you need the Maintainer role for a project or group.
 
 1. Clone the [`kubecost-cost-model`](https://gitlab.com/gitlab-examples/kubecost-cost-model/)
    example repository, which contains minor modifications to the upstream Kubecost

doc/user/compliance/license_compliance/index.md

@@ -772,7 +772,7 @@ Developers of the project can view the policies configured in a project.
 
 Prerequisites:
 
-- Maintainer or Owner [role](../../permissions.md#project-members-permissions).
+- Maintainer or Owner role.
 
 `License-Check` is a [merge request approval](../../project/merge_requests/approvals/index.md) rule
 you can enable to allow an individual or group to approve a merge request that contains a `denied`

doc/user/discussions/index.md

@@ -115,8 +115,7 @@ You can use [Markdown](../markdown.md) and [quick actions](../project/quick_acti
 
 You can edit your own comment at any time.
 
-Anyone with the [Maintainer role](../permissions.md) or
-higher can also edit a comment made by someone else.
+Anyone with at least the Maintainer role can also edit a comment made by someone else.
 
 ## Prevent comments by locking an issue
 
@@ -209,7 +208,7 @@ When you reply to a standard comment, you create a thread.
 
 Prerequisites:
 
-- You must have at least the [Guest role](../permissions.md#project-members-permissions).
+- You must have at least the Guest role.
 - You must be in an issue, merge request, or epic. Threads in commits and snippets are not supported.
 
 To create a thread by replying to a comment:
@@ -231,7 +230,7 @@ You can create a thread without replying to a standard comment.
 
 Prerequisites:
 
-- You must have at least the [Guest role](../permissions.md#project-members-permissions).
+- You must have at least the Guest role.
 - You must be in an issue, merge request, commit, or snippet.
 
 To create a thread:
@@ -253,7 +252,7 @@ In a merge request, you can resolve a thread when you want to finish a conversat
 
 Prerequisites:
 
-- You must have at least the [Developer role](../permissions.md#project-members-permissions)
+- You must have at least the Developer role
   or be the author of the change being reviewed.
 - Resolvable threads can be added only to merge requests. It doesn't work
   for comments in issues, commits, or snippets.

doc/user/group/custom_project_templates.md

@@ -24,7 +24,7 @@ You can also configure [custom templates for the instance](../admin_area/custom_
 
 Prerequisite:
 
-- You must have the [Owner role for the group](../permissions.md#group-members-permissions).
+- You must have the Owner role for the group.
 
 To set up custom project templates in a group, add the subgroup that contains the
 project templates to the group settings:

doc/user/group/devops_adoption/index.md

@@ -32,7 +32,7 @@ how to use those features.
 
 Prerequisite:
 
-- You must have at least the [Reporter role](../../permissions.md) for the group.
+- You must have at least the Reporter role for the group.
 
 To view DevOps Adoption:
 

doc/user/group/epics/epic_boards.md

@@ -24,7 +24,7 @@ To view an epic board:
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 
 To create a new epic board:
 
@@ -49,7 +49,7 @@ To change these options later, [edit the board](#edit-the-scope-of-an-epic-board
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 - A minimum of two boards present in a group.
 
 To delete the active epic board:
@@ -73,7 +73,7 @@ To delete the active epic board:
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 
 To create a new list:
 
@@ -91,7 +91,7 @@ list view that's removed. You can always create it again later if you need.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 
 To remove a list from an epic board:
 
@@ -106,7 +106,7 @@ To remove a list from an epic board:
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 - You must have [created a list](#create-a-new-list) first.
 
 To create an epic from a list in epic board:
@@ -147,7 +147,7 @@ You can move epics and lists by dragging them.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 
 To move an epic, select the epic card and drag it to another position in its current list or
 into another list. Learn about possible effects in [Dragging epics between lists](#dragging-epics-between-lists).
@@ -170,7 +170,7 @@ and the target list.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md#group-members-permissions) for a group.
+- You must have at least the Reporter role for a group.
 
 To edit the scope of an epic board:
 

doc/user/group/epics/manage_epics.md

@@ -83,7 +83,7 @@ To edit an epic's start date, due date, or labels:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7250) in GitLab 12.2.
 
-Users with at least the [Reporter role](../../permissions.md) can manage epics.
+Users with at least the Reporter role can manage epics.
 
 When bulk editing epics in a group, you can edit their labels.
 
@@ -98,8 +98,7 @@ To update multiple epics at the same time:
 ## Delete an epic
 
 NOTE:
-To delete an epic, you must be an [Owner](../../permissions.md#group-members-permissions) of a group
-or subgroup.
+To delete an epic, you must be an Owner of a group or subgroup.
 
 To delete the epic:
 

doc/user/group/index.md

@@ -138,7 +138,7 @@ your group.
 ## Change the owner of a group
 
 You can change the owner of a group. Each group must always have at least one
-member with the [Owner role](../permissions.md#group-members-permissions).
+member with the Owner role.
 
 - As an administrator:
   1. Go to the group and from the left menu, select **Group information > Members**.
@@ -153,7 +153,7 @@ member with the [Owner role](../permissions.md#group-members-permissions).
 
 Prerequisites:
 
-- You must have the [Owner role](../permissions.md#group-members-permissions).
+- You must have the Owner role.
 - The member must have direct membership in the group. If
   membership is inherited from a parent group, then the member can be removed
   from the parent group only.
@@ -250,7 +250,7 @@ There are two different ways to add a new project to a group:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/2534) in GitLab 10.5.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/25975) from GitLab Premium to GitLab Free in 11.10.
 
-By default, [Developers and Maintainers](../permissions.md#group-members-permissions) can create projects under a group.
+By default, users with at least the Developer role can create projects under a group.
 
 To change this setting for a specific group:
 
@@ -534,7 +534,7 @@ disabled for the group and its subgroups.
 
 Prerequisite:
 
-- You must be assigned the [Owner role](../permissions.md#group-members-permissions) for the group.
+- You must be assigned the Owner role) for the group.
 
 To specify a user cap:
 
@@ -556,7 +556,7 @@ You can remove the user cap, so there is no limit on the number of members you c
 
 Prerequisite:
 
-- You must be assigned the [Owner role](../permissions.md#group-members-permissions) for the group.
+- You must be assigned the Owner role) for the group.
 
 To remove the user cap:
 
@@ -575,7 +575,7 @@ and must be approved.
 
 Prerequisite:
 
-- You must be assigned the [Owner role](../permissions.md#group-members-permissions) for the group.
+- You must be assigned the Owner role) for the group.
 
 To approve members that are pending because they've exceeded the user cap:
 

doc/user/group/iterations/index.md

@@ -52,7 +52,7 @@ With iteration cadences enabled, you must first
 
 Prerequisites:
 
-- You must have at least the [Developer role](../../permissions.md) for a group.
+- You must have at least the Developer role for a group.
 
 To create an iteration cadence:
 
@@ -65,7 +65,7 @@ To create an iteration cadence:
 
 Prerequisites:
 
-- You must have at least the [Developer role](../../permissions.md) for a group.
+- You must have at least the Developer role for a group.
 
 Deleting an iteration cadence also deletes all iterations within that cadence.
 
@@ -86,7 +86,7 @@ From there you can create a new iteration or select an iteration to get a more d
 
 Prerequisites:
 
-- You must have at least the [Developer role](../../permissions.md) for a group.
+- You must have at least the Developer role for a group.
 
 For manually scheduled iteration cadences, you create and add iterations yourself.
 
@@ -104,7 +104,7 @@ To create an iteration:
 
 Prerequisites:
 
-- You must have at least the [Developer role](../../permissions.md) for a group.
+- You must have at least the Developer role for a group.
 
 To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
 
@@ -114,7 +114,7 @@ To edit an iteration, select the three-dot menu (**{ellipsis_v}**) > **Edit**.
 
 Prerequisites:
 
-- You must have at least the [Developer role](../../permissions.md) for a group.
+- You must have at least the Developer role for a group.
 
 To delete an iteration, select the three-dot menu (**{ellipsis_v}**) > **Delete**.
 

doc/user/group/settings/import_export.md

@@ -16,7 +16,7 @@ You can also [export projects](../../project/settings/import_export.md).
 
 Prerequisite:
 
-- You must have the [Owner role](../../permissions.md) for the group.
+- You must have the Owner role for the group.
 
 To enable import and export for a group:
 
@@ -69,7 +69,7 @@ in GitLab 14.6 and replaced by [GitLab Migration](../import/).
 
 Prerequisites:
 
-- You must have the [Owner role](../../permissions.md) for the group.
+- You must have the Owner role for the group.
 
 To export the contents of a group:
 

doc/user/group/subgroups/index.md

@@ -158,7 +158,7 @@ added to), add the user to the new subgroup again with a higher set of permissio
 
 For example, if User 1 was first added to group `one/two` with Developer
 permissions, then they inherit those permissions in every other subgroup
-of `one/two`. To give them the [Maintainer role](../../permissions.md) for group `one/two/three/four`,
+of `one/two`. To give them the Maintainer role for group `one/two/three/four`,
 you would add them again in that group as Maintainer. Removing them from that group,
 the permissions fall back to those of the ancestor group.
 

doc/user/infrastructure/iac/mr_integration.md

@@ -16,7 +16,7 @@ enabling you to see statistics about the resources that Terraform creates,
 modifies, or destroys.
 
 WARNING:
-Like any other job artifact, Terraform Plan data is viewable by anyone with the Guest [role](../../permissions.md) on the repository.
+Like any other job artifact, Terraform Plan data is viewable by anyone with the Guest role for the repository.
 Neither Terraform nor GitLab encrypts the plan file by default. If your Terraform Plan
 includes sensitive data such as passwords, access tokens, or certificates, we strongly
 recommend encrypting plan output or modifying the project visibility settings.

doc/user/infrastructure/iac/terraform_state.md

@@ -33,11 +33,13 @@ before using this feature.
 
 ## Permissions for using Terraform
 
-In GitLab version 13.1, the [Maintainer role](../../permissions.md) was required to use a
-GitLab managed Terraform state backend. In GitLab versions 13.2 and greater, the
-[Maintainer role](../../permissions.md) is required to lock, unlock, and write to the state
-(using `terraform apply`), while the [Developer role](../../permissions.md) is required to read
-the state (using `terraform plan -lock=false`).
+In GitLab version 13.1, the Maintainer role was required to use a
+GitLab managed Terraform state backend.
+
+In GitLab versions 13.2 and later:
+
+- The Maintainer role is required to lock, unlock, and write to the state (using `terraform apply`).
+- The Developer role is required to read the state (using `terraform plan -lock=false`).
 
 ## Set up GitLab-managed Terraform state
 
@@ -205,7 +207,7 @@ and the CI YAML file:
 The output from the above `terraform` commands should be viewable in the job logs.
 
 WARNING:
-Like any other job artifact, Terraform plan data is viewable by anyone with the Guest [role](../../permissions.md) on the repository.
+Like any other job artifact, Terraform plan data is viewable by anyone with the Guest role on the repository.
 Neither Terraform nor GitLab encrypts the plan file by default. If your Terraform plan
 includes sensitive data such as passwords, access tokens, or certificates, GitLab strongly
 recommends encrypting plan output or modifying the project visibility settings.
@@ -255,7 +257,7 @@ An example setup is shown below:
 Outputs from the data source can now be referenced in your Terraform resources
 using `data.terraform_remote_state.example.outputs.<OUTPUT-NAME>`.
 
-You need at least the [Developer role](../../permissions.md) in the target project
+You need at least the Developer role in the target project
 to read the Terraform state.
 
 ## Migrating to GitLab Managed Terraform state
@@ -365,7 +367,7 @@ location. You can then go back to running it in GitLab CI/CD.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/273592) in GitLab 13.8.
 
-Users with Developer and greater [permissions](../../permissions.md) can view the
+Users with at least the Developer role can view the
 state files attached to a project at **Infrastructure > Terraform**. Users with the
 Maintainer role can perform commands on the state files. The user interface
 contains these fields:
@@ -404,7 +406,7 @@ curl --header "Private-Token: <your_access_token>" --request DELETE "https://git
 
 ## Remove a state file
 
-Users with Maintainer and greater [permissions](../../permissions.md) can use the
+Users with at least the Maintainer role can use the
 following options to remove a state file:
 
 - **GitLab UI**: Go to **Infrastructure > Terraform**. In the **Actions** column,

doc/user/packages/dependency_proxy/index.md

@@ -93,9 +93,8 @@ You can authenticate using:
 - A [personal access token](../../../user/profile/personal_access_tokens.md) with the scope set to `read_registry` and `write_registry`.
 - A [group deploy token](../../../user/project/deploy_tokens/index.md#group-deploy-token) with the scope set to `read_registry` and `write_registry`.
 
-Users accessing the Dependency Proxy with a personal access token or username and password require
-at least [Guest membership](../../permissions.md#group-members-permissions)
-to the group they pull images from.
+Users accessing the Dependency Proxy with a personal access token or username and password must
+have at least the Guest role for the group they pull images from.
 
 #### SAML SSO
 

doc/user/project/deploy_keys/index.md

@@ -29,7 +29,7 @@ repository in automation, it's a simple solution.
 A drawback is that your repository could become vulnerable if a remote machine is compromised
 by a hacker. You should limit access to the remote machine before a deploy key is
 enabled on your repository. A good rule to follow is to provide access only to trusted users,
-and make sure that the allowed users have at least the [Maintainer role](../../permissions.md)
+and make sure that the allowed users have at least the Maintainer role
 in the GitLab project.
 
 If this security implication is a concern for your organization,

doc/user/project/deploy_tokens/index.md

@@ -14,7 +14,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 Deploy tokens allow you to download (`git clone`) or push and pull packages and
 container registry images of a project without having a user and a password.
 
-Deploy tokens can be managed by [maintainers only](../../permissions.md).
+Deploy tokens can be managed only by users with the Maintainer role.
 
 Deploy tokens cannot be used with the GitLab API.
 

doc/user/project/file_lock.md

@@ -33,7 +33,7 @@ GitLab supports two different modes of file locking:
 ## Permissions
 
 Locks can be created by any person who has at least
-[Developer role](../permissions.md) in the repository.
+Developer role in the repository.
 
 Only the user who locked the file or directory can edit locked files. Other
 users are prevented from modifying locked files by pushing, merging,
@@ -77,7 +77,7 @@ Check this document to learn more about [using Git LFS](../../topics/git/lfs/ind
 
 ### Configure Exclusive File Locks
 
-You need the [Maintainer role](../permissions.md) to configure
+You need the Maintainer role
 Exclusive File Locks for your project through the command line.
 
 The first thing to do before using File Locking is to tell Git LFS which
@@ -226,4 +226,4 @@ To view and remove file locks:
 This list shows all the files locked either through LFS or GitLab UI.
 
 Locks can be removed by their author, or any user
-with at least the [Maintainer role](../permissions.md).
+with at least the Maintainer role.

doc/user/project/import/jira.md

@@ -40,9 +40,8 @@ iterations of the GitLab Jira importer.
 
 ### Permissions
 
-In order to be able to import issues from a Jira project you need to have read access on Jira
-issues and a [Maintainer or higher](../../permissions.md#project-members-permissions) role in the
-GitLab project that you wish to import into.
+To be able to import issues from a Jira project you must have read access on Jira
+issues and at least the Maintainer role in the GitLab project that you wish to import into.
 
 ### Jira integration
 

doc/user/project/integrations/index.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 You can find the available integrations under your project's
 **Settings > Integrations** page. You need to have at least
-the [Maintainer role](../../permissions.md) on the project.
+the Maintainer role on the project.
 
 ## Integrations
 

doc/user/project/integrations/mattermost_slash_commands.md

@@ -67,7 +67,7 @@ After you enable custom slash commands in Mattermost, you need configuration
 information from GitLab. To get this information:
 
 1. In a different browser tab than your current Mattermost session, sign in to
-   GitLab as a user with [Administrator role](../../permissions.md).
+   GitLab as a user with the administrator access level.
 1. On the top bar, select **Menu > Admin**.
 1. In the left menu, select **Settings > Integrations**, then select
    **Mattermost slash commands**.

doc/user/project/issue_board.md

@@ -194,7 +194,7 @@ card includes:
 
 ## Permissions
 
-Users with the [Reporter and higher roles](../permissions.md) can use all the functionality of the
+Users with at least the Reporter role can use all the functionality of the
 issue board feature to create or delete lists. They can also drag issues from one list to another.
 
 ## Ordering issues in a list
@@ -569,7 +569,7 @@ You can move issues and lists by dragging them.
 
 Prerequisites:
 
-- You must have at least the Reporter [role](../permissions.md#project-members-permissions) for a project in GitLab.
+- You must have at least the Reporter role for a project in GitLab.
 
 To move an issue, select the issue card and drag it to another position in its current list or
 into a different list. Learn about possible effects in [Dragging issues between lists](#dragging-issues-between-lists).

doc/user/project/issues/associate_zoom_meeting.md

@@ -25,7 +25,7 @@ In an issue, leave a comment using the `/zoom` quick action followed by a valid
 /zoom https://zoom.us/j/123456789
 ```
 
-If the Zoom meeting URL is valid and you have at least the Reporter [role](../../permissions.md),
+If the Zoom meeting URL is valid and you have at least the Reporter role,
 a system alert notifies you of its successful addition.
 The issue's description is automatically edited to include the Zoom link, and a button
 appears right under the issue's title.
@@ -44,5 +44,5 @@ Similarly to adding a Zoom meeting, you can remove it with a quick action:
 /remove_zoom
 ```
 
-If you have at least the Reporter [role](../../permissions.md),
+If you have at least the Reporter role,
 a system alert notifies you that the meeting URL was successfully removed.

doc/user/project/issues/confidential_issues.md

@@ -42,7 +42,7 @@ system note in the issue's comments.
 
 ![Confidential issues system notes](img/confidential_issues_system_notes.png)
 
-When an issue is made confidential, only users with at least the [Reporter role](../../permissions.md)
+When an issue is made confidential, only users with at least the Reporter role
 for the project have access to the issue.
 Users with Guest or [Minimal](../../permissions.md#users-with-minimal-access) roles can't access
 the issue even if they were actively participating before the change.
@@ -82,11 +82,11 @@ that prevent leaks of private data.
 
 There are two kinds of level access for confidential issues. The general rule
 is that confidential issues are visible only to members of a project with at
-least the Reporter [role](../../permissions.md#project-members-permissions). However, a guest user can also create
+least the Reporter role. However, a guest user can also create
 confidential issues, but can only view the ones that they created themselves.
 
 Confidential issues are also hidden in search results for unprivileged users.
-For example, here's what a user with the [Maintainer role](../../permissions.md) and the Guest role
+For example, here's what a user with the Maintainer role and the Guest role
 sees in the project's search results respectively.
 
 | Maintainer role                                                                        | Guest role                                                                     |

doc/user/project/issues/csv_import.md

@@ -14,9 +14,7 @@ retain columns such as labels and milestones, consider the [Move Issue feature](
 
 The user uploading the CSV file is set as the author of the imported issues.
 
-NOTE:
-A permission level of [Developer](../../permissions.md), or higher, is required
-to import issues.
+You must have at least the Developer role for a project to import issues.
 
 ## Prepare for the import
 

doc/user/project/issues/due_dates.md

@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Due dates **(FREE)**
 
 Due dates can be used in [issues](index.md) to keep track of deadlines and make sure features are
-shipped on time. Users need at least the Reporter [role](../../permissions.md)
+shipped on time. Users need at least the Reporter role
 to be able to edit the due date. All users with permission to view
 the issue can view the due date.
 

doc/user/project/issues/managing_issues.md

@@ -29,7 +29,7 @@ You can create an issue in many ways in GitLab:
 
 Prerequisites:
 
-- You must have at least the [Guest role](../../permissions.md) for the project.
+- You must have at least the Guest role for the project.
 
 To create an issue:
 
@@ -52,7 +52,7 @@ to the projects in the group.
 
 Prerequisites:
 
-- You must have at least the [Guest role](../../permissions.md) for the project in the group.
+- You must have at least the Guest role for the project in the group.
 
 To create an issue from a group:
 
@@ -78,7 +78,7 @@ You can create a new issue from an existing one. The two issues can then be mark
 
 Prerequisites:
 
-- You must have at least the [Guest role](../../permissions.md) for the project.
+- You must have at least the Guest role for the project.
 
 To create an issue from another issue:
 
@@ -98,7 +98,7 @@ You can create a new issue from an [issue board](../issue_board.md).
 
 Prerequisites:
 
-- You must have at least the [Guest role](../../permissions.md) for the project.
+- You must have at least the Guest role for the project.
 
 To create an issue from a project issue board:
 
@@ -133,7 +133,7 @@ Prerequisites:
 - Your GitLab instance must have [incoming email](../../../administration/incoming_email.md)
   configured.
 - There must be at least one issue in the issue list.
-- You must have at least the [Guest role](../../permissions.md) for the project.
+- You must have at least the Guest role for the project.
 
 To email an issue to a project:
 
@@ -224,7 +224,7 @@ You can edit an issue's title and description.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
+- You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
 
 To edit an issue:
 
@@ -242,7 +242,7 @@ You can edit multiple issues at a time when you're in a project.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project.
+- You must have at least the Reporter role for the project.
 
 To edit multiple issues at the same time:
 
@@ -275,7 +275,7 @@ You can edit multiple issues across multiple projects when you're in a group.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for a group.
+- You must have at least the Reporter role for a group.
 
 To edit multiple issues at the same time:
 
@@ -304,7 +304,7 @@ Be careful when moving an issue to a project with different access rules. Before
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project.
+- You must have at least the Reporter role for the project.
 
 To move an issue:
 
@@ -319,7 +319,7 @@ You can move all open issues from one project to another.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project.
+- You must have at least the Reporter role for the project.
 
 To do it:
 
@@ -353,7 +353,7 @@ The issue is marked as closed but is not deleted.
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
+- You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
 
 To close an issue, you can do the following:
 
@@ -366,7 +366,7 @@ To close an issue, you can do the following:
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
+- You must have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
 
 To reopen a closed issue, at the top of the issue, select **Reopen issue**.
 A reopened issue is no different from any other open issue.
@@ -442,7 +442,7 @@ in the [project's settings](../settings/index.md).
 
 Prerequisites:
 
-- You must have at least the [Maintainer role](../../permissions.md) for the project.
+- You must have at least the Maintainer role for the project.
 
 To disable automatic issue closing:
 
@@ -478,7 +478,7 @@ of your installation.
 
 Prerequisites:
 
-- You must be the issue author or have at least the [Reporter role](../../permissions.md) for the project, be the author of the issue, or be assigned to the issue.
+- You must be the issue author or have at least the Reporter role for the project, be the author of the issue, or be assigned to the issue.
 
 To change issue type:
 
@@ -496,7 +496,7 @@ To change issue type:
 
 Prerequisites:
 
-- You must have the [Owner role](../../permissions.md) for a project.
+- You must have the Owner role for a project.
 
 To delete an issue:
 
@@ -624,7 +624,7 @@ This status marks issues as progressing as planned or needing attention to keep
 
 Prerequisites:
 
-- You must have at least the [Reporter role](../../permissions.md) for the project.
+- You must have at least the Reporter role for the project.
 
 To edit health status of an issue:
 

doc/user/project/issues/related_issues.md

@@ -25,7 +25,7 @@ To manage linked issues through our API, visit the [issue links API documentatio
 
 Prerequisites:
 
-- You must have at least the Reporter [role](../../permissions.md) for both projects.
+- You must have at least the Reporter role for both projects.
 
 To link one issue to another:
 

doc/user/project/members/index.md

@@ -17,7 +17,7 @@ to perform actions.
 
 Prerequisite:
 
-- You must have the [Maintainer or Owner role](../../permissions.md).
+- You must have the Maintainer or Owner role.
 
 To add a user to a project:
 
@@ -48,7 +48,7 @@ Each user's access is based on:
 
 Prerequisite:
 
-- You must have the [Maintainer or Owner role](../../permissions.md).
+- You must have the Maintainer or Owner role.
 
 To add groups to a project:
 
@@ -72,7 +72,7 @@ retain the same permissions as the project you import them from.
 
 Prerequisite:
 
-- You must have the [Maintainer or Owner role](../../permissions.md).
+- You must have the Maintainer or Owner role.
 
 To import users:
 
@@ -111,7 +111,7 @@ group itself.
 
 Prerequisites:
 
-- You must have the [Owner role](../../permissions.md).
+- You must have the Owner role.
 - Optional. Unassign the member from all issues and merge requests that
   are assigned to them.
 

doc/user/project/merge_requests/allow_collaboration.md

@@ -50,7 +50,7 @@ You can push directly to the branch of the forked repository if:
 
 - The author of the merge request has enabled contributions from upstream
   members.
-- You have at least the [Developer role](../../permissions.md) in the
+- You have at least the Developer role in the
   upstream project.
 
 In the following example:

doc/user/project/merge_requests/approvals/rules.md

@@ -165,7 +165,7 @@ for protected branches.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40491) in GitLab 13.4.
 > - Moved to GitLab Premium in 13.9.
 
-You may have to grant users with the Reporter [role](../../../permissions.md#project-members-permissions)
+You may have to grant users with the Reporter role
 permission to approve merge requests before they can merge to a protected branch.
 Some users (like managers) may not need permission to push or merge code, but still need
 oversight on proposed work. To enable approval permissions for these users without

doc/user/project/merge_requests/authorization_for_merge_requests.md

@@ -16,7 +16,7 @@ There are two main ways to have a merge request flow with GitLab:
 
 With the protected branch flow everybody works within the same GitLab project.
 
-The project maintainers get the [Maintainer role](../../permissions.md) and the regular developers
+The project maintainers get the Maintainer role and the regular developers
 get the Developer role.
 
 Maintainers mark the authoritative branches as 'Protected'.
@@ -25,7 +25,7 @@ Developers push feature branches to the project and create merge requests
 to have their feature branches reviewed and merged into one of the protected
 branches.
 
-By default, only users with the [Maintainer role](../../permissions.md) can merge changes into a
+By default, only users with the Maintainer role can merge changes into a
 protected branch.
 
 **Advantages**
@@ -39,7 +39,7 @@ protected branch.
 
 ## Forking workflow
 
-With the forking workflow, maintainers get the [Maintainer role](../../permissions.md) and regular
+With the forking workflow, maintainers get the Maintainer role and regular
 developers get the Reporter role on the authoritative repository, which prohibits
 them from pushing any changes to it.
 

doc/user/project/merge_requests/drafts.md

@@ -44,7 +44,7 @@ as a draft. This feature is scheduled for removal in GitLab 14.0. Use `Draft:` i
 When a merge request is ready to be merged, you can remove the `Draft` flag in several ways:
 
 - **Viewing a merge request**: In the top right corner of the merge request, click **Mark as ready**.
-  Users with [Developer or greater permissions](../../permissions.md)
+  Users with at least the Developer role
   can also scroll to the bottom of the merge request description and click **Mark as ready**:
 
   ![Mark as ready](img/draft_blocked_merge_button_v13_10.png)

doc/user/project/merge_requests/getting_started.md

@@ -162,7 +162,7 @@ enabled by default for all new merge requests, enable it in the
 
 This option is also visible in an existing merge request next to
 the merge request button and can be selected or deselected before merging.
-It is only visible to users with the [Maintainer role](../../permissions.md)
+It is only visible to users with the Maintainer role
 in the source project.
 
 If the user viewing the merge request does not have the correct

doc/user/project/merge_requests/index.md

@@ -94,7 +94,7 @@ You cannot undo the deletion of a merge request.
 
 To delete a merge request:
 
-1. Sign in to GitLab as a user with the project Owner [role](../../permissions.md).
+1. Sign in to GitLab as a user with the project Owner role.
    Only users with this role can delete merge requests in a project.
 1. Go to the merge request you want to delete, and select **Edit**.
 1. Scroll to the bottom of the page, and select **Delete merge request**.

doc/user/project/merge_requests/reviews/index.md

@@ -160,7 +160,7 @@ Multiline comments display the comment's line numbers above the body of the comm
 
 ## Bulk edit merge requests at the project level
 
-Users with permission level of [Developer or higher](../../../permissions.md) can manage merge requests.
+Users with at least the Developer role can manage merge requests.
 
 When bulk-editing merge requests in a project, you can edit the following attributes:
 
@@ -183,7 +183,7 @@ To update multiple project merge requests at the same time:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12719) in GitLab 12.2.
 
-Users with permission level of [Developer or higher](../../../permissions.md) can manage merge requests.
+Users with at least the Developer role can manage merge requests.
 
 When bulk editing merge requests in a group, you can edit the following attributes:
 

doc/user/project/merge_requests/reviews/suggestions.md

@@ -42,7 +42,7 @@ After the author applies a suggestion:
 1. The suggestion is marked as **Applied**.
 1. The thread is resolved.
 1. GitLab creates a new commit with the changes.
-1. If the user has the [Developer role](../../../permissions.md), GitLab pushes
+1. If the user has the Developer role, GitLab pushes
    the suggested change directly into the codebase in the merge request's branch.
 
 ## Multi-line suggestions

doc/user/project/milestones/index.md

@@ -53,8 +53,7 @@ If you're in a project and select **Issues > Milestones**, GitLab displays only
 
 ## Creating milestones
 
-NOTE:
-A permission level of [Developer or higher](../../permissions.md) is required to create milestones.
+Users with at least the Developer role can create milestones.
 
 Milestones can be created either at project or group level.
 
@@ -70,8 +69,7 @@ To create a milestone:
 
 ## Editing milestones
 
-NOTE:
-A permission level of [Developer or higher](../../permissions.md) is required to edit milestones.
+Users with at least the Developer role can edit milestones.
 
 To edit a milestone:
 

doc/user/project/protected_branches.md

@@ -35,7 +35,7 @@ Administrators can set a default branch protection level in the
 
 Prerequisite:
 
-- You must have at least the [Maintainer role](../permissions.md).
+- You must have at least the Maintainer role.
 
 To protect a branch:
 
@@ -52,7 +52,7 @@ The protected branch displays in the list of protected branches.
 
 Prerequisite:
 
-- You must have at least the [Maintainer role](../permissions.md).
+- You must have at least the Maintainer role.
 
 To protect multiple branches at the same time:
 
@@ -75,7 +75,7 @@ The protected branch displays in the list of protected branches.
 
 ## Create a protected branch
 
-Users with the Developer or higher [role](../permissions.md) can create a protected branch.
+Users with at least the Developer role can create a protected branch.
 
 Prerequisites:
 
@@ -217,7 +217,7 @@ for details about the pipelines security model.
 
 ## Delete a protected branch
 
-Users with the [Maintainer role](../permissions.md) and greater can manually delete protected
+Users with at least the Maintainer can manually delete protected
 branches by using the GitLab web interface:
 
 1. Go to **Repository > Branches**.

doc/user/project/protected_tags.md

@@ -22,12 +22,12 @@ This feature evolved out of [protected branches](protected_branches.md)
 
 By default:
 
-- To create tags, you must have the [Maintainer role](../permissions.md).
+- To create tags, you must have the Maintainer role.
 - No one can update or delete tags.
 
 ## Configuring protected tags
 
-To protect a tag, you need to have at least the [Maintainer role](../permissions.md).
+To protect a tag, you need to have at least the Maintainer role.
 
 1. Go to the project's **Settings > Repository**.
 

doc/user/project/releases/index.md

@@ -393,7 +393,7 @@ deploy_to_production:
 
 To set a deploy freeze window in the UI, complete these steps:
 
-1. Sign in to GitLab as a user with the [Maintainer role](../../permissions.md).
+1. Sign in to GitLab as a user with the Maintainer role.
 1. On the left sidebar, select **Project information**.
 1. In the left navigation menu, navigate to **Settings > CI/CD**.
 1. Scroll to **Deploy freezes**.
@@ -767,22 +767,22 @@ In the API:
 
 > [Changes were made to the Guest role access](https://gitlab.com/gitlab-org/gitlab/-/issues/335209) in GitLab 14.5.
 
-- Users with the [Reporter role or above](../../../user/permissions.md#project-members-permissions)
+- Users with at least the Reporter role
   have read and download access to the project releases.
-- Users with the [Guest role](../../../user/permissions.md#project-members-permissions)
+- Users with the Guest role
   have read and download access to the project releases.
   This includes associated Git-tag-names, release description, author information of the releases.
   However, other repository-related information, such as [source code](#source-code), [release evidence](#release-evidence) are redacted.
 
 ### Create, update, and delete a release and its assets
 
-- Users with [Developer role or above](../../../user/permissions.md#project-members-permissions)
+- Users with at least the Developer role
   have write access to the project releases and assets.
 - If a release is associated with a [protected tag](../protected_tags.md),
   the user must be [allowed to create the protected tag](../protected_tags.md#configuring-protected-tags) too.
 
 As an example of release permission control, you can allow only
-[Maintainer role or above](../../../user/permissions.md#project-members-permissions)
+users with at least the Maintainer role
 to create, update, and delete releases by protecting the tag with a wildcard (`*`),
 and set **Maintainer** in the **Allowed to create** column.
 

doc/user/project/repository/branches/default.md

@@ -38,7 +38,7 @@ the [Git commands you need](#update-the-default-branch-name-in-your-repository)
 
 To update the default branch name for an individual [project](../../index.md):
 
-1. Sign in to GitLab with at least the [Maintainer](../../../permissions.md) role.
+1. Sign in to GitLab with at least the Maintainer role.
 1. In the left navigation menu, go to **Settings > Repository**.
 1. Expand **Default branch**, and select a new default branch.
 1. Optional. Select the **Auto-close referenced issues on default branch** checkbox to close
@@ -129,7 +129,7 @@ renames a Git repository's (`example`) default branch.
    git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
    ```
 
-1. Sign in to GitLab with at least the [Maintainer](../../../permissions.md)
+1. Sign in to GitLab with at least the Maintainer
    role and follow the instructions to
    [change the default branch for this project](#change-the-default-branch-name-for-a-project).
    Select `main` as your new default branch.

doc/user/project/repository/forking_workflow.md

@@ -27,16 +27,15 @@ To fork an existing project in GitLab:
 1. Select the project to fork to:
 
    - Recommended method. Below **Select a namespace to fork the project**, identify
-     the project you want to fork to, and click **Select**. Only namespaces you have
-     Developer and higher [permissions](../../permissions.md) for are shown.
+     the project you want to fork to, and click **Select**. Only namespaces where you have
+     at least the Developer role for are shown.
 
      ![Choose namespace](img/forking_workflow_choose_namespace_v13_10.png)
 
    - Experimental method. If your GitLab administrator has
      [enabled the experimental fork project form](#enable-or-disable-the-fork-project-form), read
      [Create a fork with the fork project form](#create-a-fork-with-the-fork-project-form).
-     Only namespaces you have at least the Developer
-     [role](../../permissions.md) for are shown.
+     Only namespaces where you have at least the Developer role for are shown.
 
    NOTE:
    The project path must be unique in the namespace.