Align some topics with the style guide

doc/administration/auth/ldap/ldap_synchronization.md

@@ -127,8 +127,8 @@ following.
 
 1. [Restart GitLab](../../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
-To take advantage of group sync, group owners or maintainers must [create one
-or more LDAP group links](#add-group-links).
+To take advantage of group sync, group Owners or users with the [Maintainer role](../../../user/permissions.md) must
+[create one or more LDAP group links](#add-group-links).
 
 ### Add group links
 

doc/administration/integration/terminal.md

@@ -17,7 +17,7 @@ GitLab uses these credentials to provide access to
 [web terminals](../../ci/environments/index.md#web-terminals-deprecated) for environments.
 
 NOTE:
-Only project maintainers and owners can access web terminals.
+Only users with at least the [Maintainer role](../../user/permissions.md) for the project access web terminals.
 
 ## How it works
 

doc/administration/monitoring/gitlab_self_monitoring_project/index.md

@@ -20,9 +20,8 @@ project called **Monitoring** is created:
 The project is created specifically for visualizing and configuring the monitoring of your GitLab
 instance.
 
-When the project and group are created, all administrators are added as maintainers. As an
-administrator, you can add new members to the group to give them the
-[Maintainer role](../../../user/permissions.md) for the project.
+When the project and group are created, all administrators are given the [Maintainer role](../../../user/permissions.md).
+As an administrator, you can add new members to the group to give them the Maintainer role for the project.
 
 This project can be used to:
 

doc/administration/packages/container_registry.md

@@ -860,7 +860,7 @@ To remove image tags by running the cleanup policy, run the following commands i
 # Numeric ID of the project whose container registry should be cleaned up
 P = <project_id>
 
-# Numeric ID of a developer, maintainer or owner in that project
+# Numeric ID of a user with Developer, Maintainer, or Owner role for the project
 U = <user_id>
 
 # Get required details / objects
@@ -888,7 +888,7 @@ GitLab offers a set of APIs to manipulate the Container Registry and aid the pro
 of removing unused tags. Currently, this is exposed using the API, but in the future,
 these controls should migrate to the GitLab interface.
 
-Project maintainers can
+Users who have the [Maintainer role](../../user/permissions.md) for the project can
 [delete Container Registry tags in bulk](../../api/container_registry.md#delete-registry-repository-tags-in-bulk)
 periodically based on their own criteria, however, this alone does not recycle data,
 it only unlinks tags from manifests and image blobs. To recycle the Container

doc/api/audit_events.md

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

doc/api/deploy_tokens.md

@@ -165,8 +165,8 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" \
 
 ## Group deploy tokens
 
-Group maintainers and owners can list group deploy
-tokens. Only group owners can create and delete group deploy tokens.
+Users with at least the [Maintainer role](../user/permissions.md) for the group can list group deploy
+tokens. Only group Owners can create and delete group deploy tokens.
 
 ### List group deploy tokens
 

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 project maintainers.
+settings for a project. Only for users with [Maintainer role](../user/permissions.md) for the project.
 
 ### Get Error Tracking settings
 
@@ -41,7 +41,8 @@ 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 project maintainers.
+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.
 
 ```plaintext
 PATCH /projects/:id/error_tracking/settings
@@ -73,7 +74,8 @@ 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 project maintainers.
+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.
 
 ### List project client keys
 

doc/api/groups.md

@@ -793,9 +793,9 @@ Parameters:
 | `share_with_group_lock`              | boolean | no       | Prevent sharing a project with another group within this group. |
 | `require_two_factor_authentication`  | boolean | no       | Require all users in this group to setup Two-factor authentication. |
 | `two_factor_grace_period`            | integer | no       | Time before Two-factor authentication is enforced (in hours). |
-| `project_creation_level`             | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (Maintainers), or `developer` (Developers + Maintainers). |
+| `project_creation_level`             | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (users with the Maintainer role), or `developer` (users with the Developer or Maintainer role). |
 | `auto_devops_enabled`                | boolean | no       | Default to Auto DevOps pipeline for all projects within this group. |
-| `subgroup_creation_level`            | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#creating-a-subgroup). Can be `owner` (Owners), or `maintainer` (Maintainers). |
+| `subgroup_creation_level`            | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#creating-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
 | `emails_disabled`                    | boolean | no       | Disable email notifications |
 | `avatar`                             | mixed   | no       | Image file for avatar of the group. [Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/36681) |
 | `mentions_disabled`                  | boolean | no       | Disable the capability of a group from getting mentioned |
@@ -808,13 +808,13 @@ Parameters:
 
 ### Options for `default_branch_protection`
 
-The `default_branch_protection` attribute determines whether developers and maintainers 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](../user/permissions.md) can push to the applicable [default branch](../user/project/repository/branches/default.md), as described in the following table:
 
 | Value | Description |
 |-------|-------------------------------------------------------------------------------------------------------------|
-| `0`   | No protection. Developers and maintainers can:  <br>- Push new commits<br>- Force push changes<br>- Delete the branch |
-| `1`   | Partial protection. Developers and maintainers can:  <br>- Push new commits |
-| `2`   | Full protection. Only maintainers can:  <br>- Push new commits |
+| `0`   | No protection. Users with the Developer or Maintainer role can:  <br>- Push new commits<br>- Force push changes<br>- Delete the branch |
+| `1`   | Partial protection. Users with the Developer or Maintainer role can:  <br>- Push new commits |
+| `2`   | Full protection. Only users with the Maintainer role can:  <br>- Push new commits |
 
 ## New Subgroup
 
@@ -869,9 +869,9 @@ PUT /groups/:id
 | `visibility`                               | string  | no       | The visibility level of the group. Can be `private`, `internal`, or `public`. |
 | `require_two_factor_authentication`        | boolean | no       | Require all users in this group to setup Two-factor authentication. |
 | `two_factor_grace_period`                  | integer | no       | Time before Two-factor authentication is enforced (in hours). |
-| `project_creation_level`                   | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (Maintainers), or `developer` (Developers + Maintainers). |
+| `project_creation_level`                   | string  | no       | Determine if developers can create projects in the group. Can be `noone` (No one), `maintainer` (users with the Maintainer role), or `developer` (users with the Developer or Maintainer role). |
 | `auto_devops_enabled`                      | boolean | no       | Default to Auto DevOps pipeline for all projects within this group. |
-| `subgroup_creation_level`                  | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#creating-a-subgroup). Can be `owner` (Owners), or `maintainer` (Maintainers). |
+| `subgroup_creation_level`                  | string  | no       | Allowed to [create subgroups](../user/group/subgroups/index.md#creating-a-subgroup). Can be `owner` (Owners), or `maintainer` (users with the Maintainer role). |
 | `emails_disabled`                          | boolean | no       | Disable email notifications |
 | `avatar`                                   | mixed   | no       | Image file for avatar of the group. [Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/-/issues/36681) |
 | `mentions_disabled`                        | boolean | no       | Disable the capability of a group from getting mentioned |

doc/api/projects.md

@@ -1419,7 +1419,7 @@ Supported attributes:
 | `packages_enabled`                                          | boolean        | **{dotted-circle}** No | Enable or disable packages repository feature. |
 | `pages_access_level`                                        | string         | **{dotted-circle}** No | One of `disabled`, `private`, `enabled`, or `public`. |
 | `requirements_access_level`                                 | string         | **{dotted-circle}** No | One of `disabled`, `private`, `enabled` or `public` |
-| `restrict_user_defined_variables`                           | boolean        | **{dotted-circle}** No | Allow only maintainers 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](../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. |
 | `path`                                                      | string         | **{dotted-circle}** No | Custom repository name for the project. By default generated based on name. |
 | `public_builds`                                             | boolean        | **{dotted-circle}** No | If `true`, jobs can be viewed by non-project members. |
 | `remove_source_branch_after_merge`                          | boolean        | **{dotted-circle}** No | Enable `Delete source branch` option by default for all new merge requests. |

doc/api/settings.md

@@ -248,7 +248,7 @@ listed in the descriptions of the relevant settings.
 | `deactivate_dormant_users`               | boolean          | no                                   | Enable [automatic deactivation of dormant users](../user/admin_area/moderate_users.md#automatically-deactivate-dormant-users). |
 | `default_artifacts_expire_in`            | string           | no                                   | Set the default expiration time for each job's artifacts. |
 | `default_branch_name`                    | string           | no                                   | [Instance-level custom initial branch name](../user/project/repository/branches/default.md#instance-level-custom-initial-branch-name) ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225258) in GitLab 13.2). |
-| `default_branch_protection`              | integer          | no                                   | Determine if developers can push to the default branch. Can take: `0` _(not protected, both developers and maintainers can push new commits and force push)_, `1` _(partially protected, developers and maintainers can push new commits, but cannot force push)_ or `2` _(fully protected, developers cannot push new commits, but maintainers can; no one can force push)_ as a parameter. Default is `2`. |
+| `default_branch_protection`              | integer          | no                                   | Determine if developers can push to the default branch. Can take: `0` _(not protected, both users with the Developer role or Maintainer role can push new commits and force push)_, `1` _(partially protected, users with the Developer role or Maintainer role can push new commits, but cannot force push)_ or `2` _(fully protected, users with the Developer or Maintainer role cannot push new commits, but users with the Developer or Maintainer role can; no one can force push)_ as a parameter. Default is `2`. |
 | `default_ci_config_path`                  | string           | no                                   | Default CI/CD configuration file and path for new projects (`.gitlab-ci.yml` if not set). |
 | `default_group_visibility`               | string           | no                                   | What visibility level new groups receive. Can take `private`, `internal` and `public` as a parameter. Default is `private`. |
 | `default_project_creation`               | integer          | no                                   | Default project creation protection. Can take: `0` _(No one)_, `1` _(Maintainers)_ or `2` _(Developers + Maintainers)_|

doc/ci/environments/deployment_safety.md

@@ -119,17 +119,17 @@ 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 maintainers from reading the secrets and makes sure that the runner only runs on
-protected branches.
+This prevents other users with the [Maintainer role](../../user/permissions.md) 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).
 
 ## Separate project for deployments
 
-All project maintainers have access to production secrets. If you need to limit the number of users
+All users with the Maintainer role for the project have access to production secrets. If you need to limit the number of users
 that can deploy to a production environment, you can create a separate project and configure a new
 permission model that isolates the CD permissions from the original project and prevents the
-original project's maintainers from accessing the production secret and CD configuration. You can
+original users with the Maintainer role for the project from accessing the production secret and CD configuration. You can
 connect the CD project to your development projects by using [multi-project pipelines](../pipelines/multi_project_pipelines.md).
 
 ## Protect `gitlab-ci.yml` from change

doc/ci/environments/protected_environments.md

@@ -194,16 +194,15 @@ 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 added as a
-maintainer to a new project. Group-level protected environments can be a solution
-in this situation.
+might gain privileged access to a higher environment when they are given the [Maintainer role](../../user/permissions.md)
+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 assigned the [maintainer role](../../user/permissions.md)
-  (or above) to the top-level group. They can maintain CI/CD configurations for
+- Operators should be given at least the [Maintainer role](../../user/permissions.md)
+  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,
   [group-level runners](../runners/runners_scope.md#group-runners), and
@@ -211,9 +210,9 @@ 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 assigned the [developer role](../../user/permissions.md)
-  (or below) at the top-level group, or explicitly assigned to a child project
-  as maintainers. They do *NOT* have access to the CI/CD configurations in the
+- 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
+  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.
 - For sub-groups and child projects:
@@ -225,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 to tune their lower environments (such
+    safely assigned the [Maintainer role](../../user/permissions.md) to tune their lower environments (such
     as `testing`).
 
 Having this configuration in place: