Merge branch 'eread/elevate-maintainer-owner-role-rule-to-error' into 'master'

Elevate the Maintainer and Owner role rules to error level

See merge request gitlab-org/gitlab!65792

doc/.vale/gitlab/SubstitutionWarning.yml

@@ -19,12 +19,6 @@ swap:
   info: information
   repo: repository
   utilize: use
-  owner access: the Owner role
-  owner permission: the Owner role
-  owner permissions: the Owner role
-  maintainer access: the Maintainer role
-  maintainer permission: the Maintainer role
-  maintainer permissions: the Maintainer role
   administrator access: the Administrator role
   administrator permission: the Administrator role
   administrator permissions: the Administrator role

doc/.vale/gitlab/Substitutions.yml

@@ -41,3 +41,9 @@ swap:
   developer access: the Developer role
   developer permission: the Developer role
   developer permissions: the Developer role
+  maintainer access: the Maintainer role
+  maintainer permission: the Maintainer role
+  maintainer permissions: the Maintainer role
+  owner access: the Owner role
+  owner permission: the Owner role
+  owner permissions: the Owner role

doc/api/runners.md

@@ -164,7 +164,7 @@ Example response:
 
 Get details of a runner.
 
-The [Maintainer role or higher](../user/permissions.md) is required to get runner details at the
+At least the [Maintainer role](../user/permissions.md) 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/ci/chatops/index.md

@@ -40,8 +40,8 @@ job completes:
 - If the job completes in *more than 30 minutes*, the job must use the
   [Slack API](https://api.slack.com/) to send data to the channel.
 
-To use the `run` command, you must have the
-[Developer role or higher](../../user/permissions.md#project-members-permissions).
+To use the `run` command, you must have at least the
+[Developer role](../../user/permissions.md#project-members-permissions).
 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
@@ -53,7 +53,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 the [Developer role or higher](../../user/permissions.md#project-members-permissions)
+  slash command has at least the [Developer role](../../user/permissions.md#project-members-permissions)
   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_safety.md

@@ -25,8 +25,8 @@ 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 the
-[Developer role or higher](../../user/permissions.md#project-members-permissions).
+By default, environments can be modified by any team member that has at least the
+[Developer role](../../user/permissions.md#project-members-permissions).
 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).
 

doc/development/documentation/styleguide/word_list.md

@@ -42,8 +42,13 @@ Do not use when talking about the product or its features. The documentation des
 
 ## Developer
 
-When writing about the Developer role, use a capital "D." Do not use the phrase, "if you are a developer"
-to mean someone who is assigned the Developer role. Instead, write it out. "If you are assigned the Developer role..."
+When writing about the Developer role:
+
+- Use a capital "D."
+- Do not use the phrase, "if you are a developer" to mean someone who is assigned the Developer
+  role. Instead, write it out. "If you are assigned the Developer role..."
+- To describe a situation where the Developer role is the minimum required, use the phrase "at least
+  the Developer role..."
 
 Do not use "Developer permissions." A user who is assigned the Developer role has a set of associated permissions.
 
@@ -79,8 +84,13 @@ Do not make possessive (GitLab's). This guidance follows [GitLab Brand Guideline
 
 ## Guest
 
-When writing about the Guest role, use a capital "G." Do not use the phrase, "if you are a guest"
-to mean someone who is assigned the Guest role. Instead, write it out. "If you are assigned the Guest role..."
+When writing about the Guest role:
+
+- Use a capital "G."
+- Do not use the phrase, "if you are a guest" to mean someone who is assigned the Guest role.
+  Instead, write it out. "If you are assigned the Guest role..."
+- To describe a situation where the Guest role is the minimum required, use the phrase "at
+  least the Guest role..."
 
 Do not use "Guest permissions." A user who is assigned the Guest role has a set of associated permissions.
 
@@ -102,8 +112,13 @@ Do not use Latin abbreviations. Use **that is** instead. ([Vale](../testing.md#v
 
 ## Maintainer
 
-When writing about the Maintainer role, use a capital "M." Do not use the phrase, "if you are a maintainer"
-to mean someone who is assigned the Maintainer role. Instead, write it out. "If you are assigned the Maintainer role..."
+When writing about the Maintainer role:
+
+- Use a capital "M."
+- Do not use the phrase, "if you are a maintainer" to mean someone who is assigned the Maintainer
+  role. Instead, write it out. "If you are assigned the Maintainer role..."
+- To describe a situation where the Maintainer role is the minimum required, use the phrase "at
+  least the Maintainer role..."
 
 Do not use "Maintainer permissions." A user who is assigned the Maintainer role has a set of associated permissions.
 
@@ -133,8 +148,11 @@ Lowercase. If you use **MR** as the acronym, spell it out on first use.
 
 ## Owner
 
-When writing about the Owner role, use a capital "O." Do not use the phrase, "if you are an owner"
-to mean someone who is assigned the Owner role. Instead, write it out. "If you are assigned the Owner role..."
+When writing about the Owner role:
+
+- Use a capital "O."
+- Do not use the phrase, "if you are an owner" to mean someone who is assigned the Owner role.
+  Instead, write it out. "If you are assigned the Owner role..."
 
 Do not use "Owner permissions." A user who is assigned the Owner role has a set of associated permissions.
 

doc/operations/incident_management/integrations.md

@@ -18,8 +18,8 @@ to use this endpoint.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/245331) in GitLab Free 13.5.
 
-With the [Maintainer role or higher](../../user/permissions.md),
-you can view the list of configured alerts integrations by navigating to **Settings > Monitor**
+With at least the [Maintainer role](../../user/permissions.md), 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):
 

doc/user/discussions/index.md

@@ -239,8 +239,8 @@ When you do, only project members can add and edit comments.
 
 Prerequisite:
 
-- In merge requests, you must have the Developer role or higher.
-- In issues, you must have the Reporter role or higher.
+- In merge requests, you must have at least the Developer role.
+- In issues, you must have at least the Reporter role.
 
 1. On the right sidebar, next to **Lock issue** or **Lock merge request**, select **Edit**.
 1. On the confirmation dialog, select **Lock**.
@@ -261,7 +261,7 @@ WARNING:
 This feature might not be available to you. Check the **version history** note above for details.
 
 You can make a comment confidential, so that it is visible only to project members
-who have the Reporter role or higher.
+who have at least the Reporter role.
 
 1. Below the comment, select the **Make this comment confidential** checkbox.
 1. Select **Comment**.

doc/user/group/import/index.md

@@ -119,13 +119,13 @@ on an existing group's page.
 ### Selecting which groups to import
 
 After you have authorized access to the GitLab instance, you are redirected to the GitLab Group
-Migration importer page. Your remote GitLab groups, which you have Owner access to, are listed.
+Migration importer page. Listed are the remote GitLab groups to which you have the Owner role.
 
 1. By default, the proposed group namespaces match the names as they exist in remote instance, but based on your permissions, you can choose to edit these names before you proceed to import any of them.
 
 1. Select the **Import** button next to any number of groups.
 
-1. The **Status** column shows the import status of each group. You can choose to leave the page open and it will update in real-time.
+1. The **Status** column shows the import status of each group. You can choose to leave the page open and it updates in real-time.
 
 1. Once a group has been imported, click its GitLab path to open its GitLab URL.
 

doc/user/infrastructure/clusters/connect/new_gke_cluster.md

@@ -19,8 +19,8 @@ You can then modify the project files according to your needs.
 **Prerequisites:**
 
 - A GitLab group.
-- A GitLab user with maintainer permissions to the group.
-- A [GitLab personal access token](../../../profile/personal_access_tokens.md) with `api` access, created by a user with maintainer permissions to the group.
+- A GitLab user with the Maintainer role in the group.
+- A [GitLab personal access token](../../../profile/personal_access_tokens.md) with `api` access, created by a user with at least the Maintainer role in the group.
 - A [Google Cloud Platform (GCP) service account](https://cloud.google.com/docs/authentication/getting-started).
 
 **Steps:**

doc/user/project/clusters/add_existing_cluster.md

@@ -19,7 +19,7 @@ To add any cluster to GitLab, you need:
 
 - Either a GitLab.com account or an account for a self-managed installation
 running GitLab 12.5 or later.
-- Maintainer permissions for group-level and project-level clusters.
+- The Maintainer role for group-level and project-level clusters.
 - Access to the Admin area for instance-level clusters. **(FREE SELF)**
 - A Kubernetes cluster.
 - Cluster administration access to the cluster with `kubectl`.

doc/user/project/deploy_keys/index.md

@@ -28,7 +28,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 the [Maintainer role or higher](../../permissions.md)
+and make sure that the allowed users have at least the [Maintainer role](../../permissions.md)
 in the GitLab project.
 
 If this security implication is a concern for your organization,

doc/user/project/releases/index.md

@@ -62,7 +62,7 @@ You can create a release in the user interface, or by using the
 We recommend using the API to create releases as one of the last steps in your
 CI/CD pipeline.
 
-Only users with the Developer role or higher can create releases.
+Only users with at least the Developer role can create releases.
 Read more about [Release permissions](#release-permissions).
 
 To create a new release through the GitLab UI:
@@ -102,7 +102,7 @@ release tag. When the `released_at` date and time has passed, the badge is autom
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26016) in GitLab 12.6. Asset link editing was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9427) in GitLab 12.10.
 
-Only users with the Developer role or higher can edit releases.
+Only users with at least the Developer can edit releases.
 Read more about [Release permissions](#release-permissions).
 
 To edit the details of a release: