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

Elevate Developer role rule to error level

See merge request gitlab-org/gitlab!65702

doc/.vale/gitlab/SubstitutionWarning.yml

@@ -28,6 +28,3 @@ swap:
   administrator access: the Administrator role
   administrator permission: the Administrator role
   administrator permissions: the Administrator role
-  developer access: the Developer role
-  developer permission: the Developer role
-  developer permissions: the Developer role

doc/.vale/gitlab/Substitutions.yml

@@ -38,3 +38,6 @@ swap:
   can sign-in: can sign in
   x509: X.509
   yaml: YAML
+  developer access: the Developer role
+  developer permission: the Developer role
+  developer permissions: the Developer role

doc/api/access_requests.md

@@ -111,7 +111,7 @@ PUT /projects/:id/access_requests/:user_id/approve
 | -------------- | -------------- | -------- | ----------- |
 | `id`           | integer/string | yes      | The ID or [URL-encoded path of the project](index.md#namespaced-path-encoding) owned by the authenticated user |
 | `user_id`      | integer        | yes      | The user ID of the access requester                                                                             |
-| `access_level` | integer        | no       | A valid access level (defaults: `30`, developer access level)                                                   |
+| `access_level` | integer        | no       | A valid access level (defaults: `30`, the Developer role)                                                   |
 
 Example request:
 

doc/api/group_milestones.md

@@ -114,7 +114,7 @@ Parameters:
 
 ## Delete group milestone
 
-Only for users with Developer access to the group.
+Only for users with the Developer role in the group.
 
 ```plaintext
 DELETE /groups/:id/milestones/:milestone_id

doc/api/invitations.md

@@ -123,7 +123,7 @@ PUT /projects/:id/invitations/:email
 | --------- | ---- | -------- | ----------- |
 | `id`      | integer/string | yes | The ID or [URL-encoded path of the project or group](index.md#namespaced-path-encoding) owned by the authenticated user. |
 | `email`   | string | yes    | The email address to which the invitation was previously sent. |
-| `access_level` | integer | no | A valid access level (defaults: `30`, developer access level). |
+| `access_level` | integer | no | A valid access level (defaults: `30`, the Developer role). |
 | `expires_at` | string | no | A date string in ISO 8601 format (`YYYY-MM-DDTHH:MM:SSZ`). |
 
 ```shell

doc/api/milestones.md

@@ -107,7 +107,7 @@ Parameters:
 
 ## Delete project milestone
 
-Only for users with Developer access to the project.
+Only for users with the Developer role in the project.
 
 ```plaintext
 DELETE /projects/:id/milestones/:milestone_id
@@ -148,7 +148,7 @@ Parameters:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53861) in GitLab 11.9
 
-Only for users with Developer access to the group.
+Only for users with the Developer role in the group.
 
 ```plaintext
 POST /projects/:id/milestones/:milestone_id/promote

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
-[Developer access or above](../../user/permissions.md#project-members-permissions).
+To use the `run` command, you must have the
+[Developer role or higher](../../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 [Developer access or above](../../user/permissions.md#project-members-permissions)
+  slash command has the [Developer role or higher](../../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,7 +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 [Developer permission or higher](../../user/permissions.md#project-members-permissions).
+By default, environments can be modified by any team member that has the
+[Developer role or higher](../../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/ci/environments/protected_environments.md

@@ -39,7 +39,7 @@ To protect an environment:
      - **Maintainers**: Allows access to all maintainers in the project.
      - **Developers**: Allows access to all maintainers and all developers in the project.
    - You can only select groups that are already associated with the project.
-   - Only users that have at least the Developer permission level appear in
+   - Only users that have at least the Developer role appear in
      the **Allowed to Deploy** dropdown menu.
 1. Click the **Protect** button.
 
@@ -112,7 +112,7 @@ protected environments with this method.
 
 ## Deployment branch access
 
-Users with [Developer permissions](../../user/permissions.md) can be granted
+Users with the [Developer role](../../user/permissions.md) can be granted
 access to a protected environment through any of these methods:
 
 - As an individual contributor, through a role.

doc/ci/pipelines/index.md

@@ -222,7 +222,7 @@ to an updated status.
 
 This functionality is only available:
 
-- For users with at least Developer access.
+- For users with at least the Developer role.
 - If the stage contains [manual actions](#add-manual-interaction-to-your-pipeline).
 
 ### Delete a pipeline

doc/ci/review_apps/index.md

@@ -224,7 +224,7 @@ To see Visual reviews in action, see the [Visual Reviews Walk through](https://y
 ### Configure Review Apps for Visual Reviews
 
 The feedback form is served through a script you add to pages in your Review App.
-If you have [Developer permissions](../../user/permissions.md) to the project,
+If you have the [Developer role](../../user/permissions.md) in the project,
 you can access it by clicking the **Review** button in the **Pipeline** section
 of the merge request. The form modal also shows a dropdown for changed pages
 if [route maps](#route-maps) are configured in the project.

doc/development/contributing/issue_workflow.md

@@ -36,7 +36,7 @@ the affected files to find someone.
 We also use [GitLab Triage](https://gitlab.com/gitlab-org/gitlab-triage) to automate
 some triaging policies. This is currently set up as a scheduled pipeline
 (`https://gitlab.com/gitlab-org/quality/triage-ops/pipeline_schedules/10512/editpipeline_schedules/10512/edit`,
-must have at least Developer access to the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
+must have at least the Developer role in the project) running on [quality/triage-ops](https://gitlab.com/gitlab-org/quality/triage-ops)
 project.
 
 ## Labels

doc/development/documentation/workflow.md

@@ -63,7 +63,7 @@ To update GitLab documentation:
 1. Follow the [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines).
 
 NOTE:
-Work in a fork if you do not have Developer access to the GitLab project.
+Work in a fork if you do not have the Developer role in the GitLab project.
 
 ### Ask for help
 

doc/development/i18n/merging_translations.md

@@ -21,7 +21,7 @@ message. This avoids an excessive number of pipelines from running.
 Before merging translations, make sure to trigger a pipeline to validate
 translations. Static analysis validates things CrowdIn doesn't do. Create
 a new pipeline at [`https://gitlab.com/gitlab-org/gitlab/pipelines/new`](https://gitlab.com/gitlab-org/gitlab/pipelines/new)
-(need developer permissions) for the `master-i18n` branch.
+(requires the Developer role) for the `master-i18n` branch.
 
 If there are validation errors, the easiest solution is to disapprove
 the offending string in CrowdIn, leaving a comment with what is

doc/development/testing_guide/end_to_end/index.md

@@ -23,13 +23,13 @@ a black-box testing framework for the API and the UI.
 
 We run scheduled pipelines each night to test nightly builds created by Omnibus.
 You can find these pipelines at <https://gitlab.com/gitlab-org/quality/nightly/pipelines>
-(need Developer access permissions). Results are reported in the `#qa-nightly` Slack channel.
+(requires the Developer role). Results are reported in the `#qa-nightly` Slack channel.
 
 ### Testing staging
 
 We run scheduled pipelines each night to test staging.
 You can find these pipelines at <https://gitlab.com/gitlab-org/quality/staging/pipelines>
-(need Developer access permissions). Results are reported in the `#qa-staging` Slack channel.
+(requires the Developer role). Results are reported in the `#qa-staging` Slack channel.
 
 ### Testing code in merge requests
 

doc/integration/jenkins.md

@@ -65,7 +65,7 @@ Grant a GitLab user access to the select GitLab projects.
 1. Grant the user permission to the GitLab projects.
 
    If you're integrating Jenkins with many GitLab projects, consider granting the user global
-   Administrator permission. Otherwise, add the user to each project, and grant Developer permission.
+   Administrator permission. Otherwise, add the user to each project, and grant the Developer role.
 
 ## Configure GitLab API access
 

doc/operations/incident_management/incidents.md

@@ -56,7 +56,7 @@ With Maintainer or higher [permissions](../../user/permissions.md), you can enab
 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 [Developer permissions](../../user/permissions.md), select
+   with the [Developer role](../../user/permissions.md), select
    **Send a separate email notification to Developers**. Email notifications are
    also sent to users with **Maintainer** and **Owner** permissions.
 1. Click **Save changes**.

doc/user/infrastructure/terraform_state.md

@@ -242,7 +242,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 [developer access](../permissions.md) to the target project
+You need at least the [Developer role](../permissions.md) in the target project
 to read the Terraform state.
 
 ## Migrating to GitLab Managed Terraform state

doc/user/project/file_lock.md

@@ -34,7 +34,7 @@ GitLab supports two different modes of file locking:
 ## Permissions
 
 Locks can be created by any person who has at least
-[Developer permissions](../permissions.md) to the repository.
+[Developer role](../permissions.md) 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,

doc/user/project/issues/managing_issues.md

@@ -333,7 +333,7 @@ of your installation.
 
 ## Change the issue type
 
-Users with [developer permission](../../permissions.md)
+Users with the [Developer role](../../permissions.md)
 can change an issue's type. To do this, edit the issue and select an issue type from the
 **Issue type** selector menu:
 

doc/user/project/merge_requests/authorization_for_merge_requests.md

@@ -17,7 +17,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
-get Developer access.
+get the Developer role.
 
 Maintainers mark the authoritative branches as 'Protected'.
 

doc/user/project/merge_requests/merge_when_pipeline_succeeds.md

@@ -21,7 +21,7 @@ request is updated to show the impending merge. If you can't wait
 for the pipeline to succeed, you can choose **Merge immediately**
 in the dropdown menu on the right of the main button.
 
-The author of the merge request and project members with developer permissions can
+The author of the merge request and project members with the Developer role can
 cancel the automatic merge at any time before the pipeline finishes.
 
 ![Status](img/merge_when_pipeline_succeeds_status.png)

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

@@ -42,7 +42,7 @@ which generates a commit in the merge request authored by the user that suggeste
 After the author applies a suggestion, it's marked with the **Applied** label,
 the thread is automatically resolved, and GitLab creates a new commit
 and pushes the suggested change directly into the codebase in the merge request's
-branch. [Developer permission](../../../permissions.md) is required to do so.
+branch. The [Developer role](../../../permissions.md) is required to do so.
 
 ## Multi-line suggestions
 

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 Developer permissions or higher can create releases.
+Only users with the Developer role or higher 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 Developer permissions or higher can edit releases.
+Only users with the Developer role or higher can edit releases.
 Read more about [Release permissions](#release-permissions).
 
 To edit the details of a release:

doc/user/project/wiki/index.md

@@ -44,7 +44,7 @@ users see when viewing the wiki:
 
 ## Create a new wiki page
 
-Users with Developer [permissions](../../permissions.md) can create new wiki pages:
+Users with the [Developer role](../../permissions.md) can create new wiki pages:
 
 1. Go to your project or group and select **Wiki**.
 1. Select **New page** on this page, or any other wiki page.
@@ -108,7 +108,7 @@ may not be able to check out the wiki locally afterward.
 
 ## Edit a wiki page
 
-You need Developer [permissions](../../permissions.md) or higher to edit a wiki page:
+You need the [Developer role](../../permissions.md) or higher to edit a wiki page:
 
 1. Go to your project or group and select **Wiki**.
 1. Go to the page you want to edit.
@@ -133,7 +133,7 @@ You need the [Maintainer role](../../permissions.md) or higher to delete a wiki
 
 ## Move a wiki page
 
-You need Developer [permissions](../../permissions.md) or higher to move a wiki page:
+You need the [Developer role](../../permissions.md) or higher to move a wiki page:
 
 1. Go to your project or group and select **Wiki**.
 1. Go to the page you want to move.
@@ -234,7 +234,7 @@ wikis, with a few limitations:
 
 For updates, follow [the epic that tracks feature parity with project wikis](https://gitlab.com/groups/gitlab-org/-/epics/2782).
 
-Group wikis can be edited by members with [Developer permissions](../../permissions.md#group-members-permissions)
+Group wikis can be edited by members with the [Developer role](../../permissions.md#group-members-permissions)
 and above. Group wiki repositories can be moved using the
 [Group repository storage moves API](../../../api/group_repository_storage_moves.md).