Merge branch '42751-rename-master-to-maintainer-ee' into 'master'

Resolve "Rename the `Master` role to `Maintainer`"

See merge request gitlab-org/gitlab-ee!5948

app/models/concerns/protected_ref_access.rb

@@ -9,8 +9,8 @@ module ProtectedRefAccess
   ].freeze
 
   HUMAN_ACCESS_LEVELS = {
-    Gitlab::Access::MASTER => "Masters".freeze,
-    Gitlab::Access::DEVELOPER => "Developers + Masters".freeze,
+    Gitlab::Access::MASTER => "Maintainers".freeze,
+    Gitlab::Access::DEVELOPER => "Developers + Maintainers".freeze,
     Gitlab::Access::NO_ACCESS => "No one".freeze
   }.freeze
 

app/models/protected_branch.rb

@@ -7,7 +7,7 @@ class ProtectedBranch < ActiveRecord::Base
   protected_ref_access_levels :merge, :push
 
   def self.protected_ref_accessible_to?(ref, user, project:, action:, protected_refs: nil)
-    # Masters, owners and admins are allowed to create the default branch
+    # Maintainers, owners and admins are allowed to create the default branch
     if default_branch_protected? && project.empty_repo?
       return true if user.admin? || project.team.max_member_access(user.id) > Gitlab::Access::DEVELOPER
     end

app/policies/project_policy.rb

@@ -46,7 +46,7 @@ class ProjectPolicy < BasePolicy
   desc "User has developer access"
   condition(:developer) { team_access_level >= Gitlab::Access::DEVELOPER }
 
-  desc "User has master access"
+  desc "User has maintainer access"
   condition(:master) { team_access_level >= Gitlab::Access::MASTER }
 
   desc "Project is public"

app/services/lfs/unlock_file_service.rb

@@ -26,7 +26,7 @@ module Lfs
 
         success(lock: lock, http_status: :ok)
       elsif forced
-        error(_('You must have master access to force delete a lock'), 403)
+        error(_('You must have maintainer access to force delete a lock'), 403)
       else
         error(_("%{lock_path} is locked by GitLab User %{lock_user_id}") % { lock_path: lock.path, lock_user_id: lock.user_id }, 403)
       end

app/views/projects/branches/_branch.html.haml

@@ -77,7 +77,7 @@
         - else
           %button{ class: "btn btn-remove remove-row js-ajax-loading-spinner has-tooltip disabled",
             disabled: true,
-            title: s_('Branches|Only a project master or owner can delete a protected branch') }
+            title: s_('Branches|Only a project maintainer or owner can delete a protected branch') }
             = icon("trash-o")
       - else
         = link_to project_branch_path(@project, branch.name),

app/views/projects/project_members/index.html.haml

@@ -11,7 +11,7 @@
       - else
         %p
           Members can be added by project
-          %i Masters
+          %i Maintainers
           or
           %i Owners
 

app/views/projects/protected_branches/shared/_index.html.haml

@@ -12,8 +12,8 @@
     %p
       By default, protected branches are designed to:
       %ul
-        %li prevent their creation, if not already created, from everybody except Masters
-        %li prevent pushes from everybody except Masters
+        %li prevent their creation, if not already created, from everybody except Maintainers
+        %li prevent pushes from everybody except Maintainers
         %li prevent <strong>anyone</strong> from force pushing to the branch
         %li prevent <strong>anyone</strong> from deleting the branch
       %p Read more about #{link_to "protected branches", help_page_path("user/project/protected_branches")} and #{link_to "project permissions", help_page_path("user/permissions")}.

app/views/projects/protected_tags/shared/_index.html.haml

@@ -12,7 +12,7 @@
     %p
       By default, protected tags are designed to:
       %ul
-        %li Prevent tag creation by everybody except Masters
+        %li Prevent tag creation by everybody except Maintainers
         %li Prevent <strong>anyone</strong> from updating the tag
         %li Prevent <strong>anyone</strong> from deleting the tag
 

app/views/projects/runners/_group_runners.html.haml

@@ -26,9 +26,9 @@
 
   - if can?(current_user, :admin_pipeline, @project.group)
     - group_link = link_to _('Group CI/CD settings'), group_settings_ci_cd_path(@project.group)
-    = _('Group masters can register group runners in the %{link}').html_safe % { link: group_link }
+    = _('Group maintainers can register group runners in the %{link}').html_safe % { link: group_link }
   - else
-    = _('Ask your group master to setup a group Runner.')
+    = _('Ask your group maintainer to setup a group Runner.')
 
 - else
   %h4.underlined-title

changelogs/unreleased/42751-rename-master-to-maintainer.yml

+---
+title: Rename the Master role to Maintainer
+merge_request: 19080
+author:
+type: changed

doc/README.md

@@ -215,7 +215,7 @@ instant how code changes impact your production environment.
 - [User account](user/profile/index.md): Manage your account
   - [Authentication](topics/authentication/index.md): Account security with two-factor authentication, setup your ssh keys and deploy keys for secure access to your projects.
   - [Profile settings](user/profile/index.md#profile-settings): Manage your profile settings, two factor authentication and more.
-- [User permissions](user/permissions.md): Learn what each role in a project (external/guest/reporter/developer/master/owner) can do.
+- [User permissions](user/permissions.md): Learn what each role in a project (external/guest/reporter/developer/maintainer/owner) can do.
 
 ### Git and GitLab
 

doc/administration/integration/terminal.md

@@ -2,7 +2,7 @@
 
 >
 [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7690)
-in GitLab 8.15. Only project masters and owners can access web terminals.
+in GitLab 8.15. Only project maintainers and owners can access web terminals.
 
 With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
 GitLab gained the ability to store and use credentials for a Kubernetes cluster.

doc/api/access_requests.md

@@ -10,7 +10,7 @@
 10 => Guest access
 20 => Reporter access
 30 => Developer access
-40 => Master access
+40 => Maintainer access
 50 => Owner access # Only valid for groups
 ```
 

doc/api/members.md

@@ -8,7 +8,7 @@ The access levels are defined in the `Gitlab::Access` module. Currently, these l
 10 => Guest access
 20 => Reporter access
 30 => Developer access
-40 => Master access
+40 => Maintainer access
 50 => Owner access # Only valid for groups
 ```
 

doc/api/namespaces.md

@@ -55,7 +55,7 @@ Example response:
 ]
 ```
 
-**Note**: `members_count_with_descendants` and `plan` are presented only for group masters/owners.
+**Note**: `members_count_with_descendants` and `plan` are presented only for group maintainers/owners.
 
 ## Search for namespace
 

doc/api/protected_branches.md

@@ -8,7 +8,7 @@ The access levels are defined in the `ProtectedRefAccess::ALLOWED_ACCESS_LEVELS`
 ```
 0  => No access
 30 => Developer access
-40 => Master access
+40 => Maintainer access
 60 => Admin access
 ```
 
@@ -39,7 +39,7 @@ Example response:
         "access_level": 40,
         "user_id": null,
         "group_id": null,
-        "access_level_description": "Masters"
+        "access_level_description": "Maintainers"
       }
     ],
     "merge_access_levels": [
@@ -82,7 +82,7 @@ Example response:
       "access_level": 40,
       "user_id": null,
       "group_id": null,
-      "access_level_description": "Masters"
+      "access_level_description": "Maintainers"
     }
   ],
   "merge_access_levels": [
@@ -113,9 +113,9 @@ curl --request POST --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" 'https://gitl
 | --------- | ---- | -------- | ----------- |
 | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
 | `name` | string | yes | The name of the branch or wildcard |
-| `push_access_level` | string | no | Access levels allowed to push (defaults: `40`, master access level) |
-| `merge_access_level` | string | no | Access levels allowed to merge (defaults: `40`, master access level) |
-| `unprotect_access_level` | string | no | Access levels allowed to unprotect (defaults: `40`, master access level) |
+| `push_access_level` | string | no | Access levels allowed to push (defaults: `40`, maintainer access level) |
+| `merge_access_level` | string | no | Access levels allowed to merge (defaults: `40`, maintainer access level) |
+| `unprotect_access_level` | string | no | Access levels allowed to unprotect (defaults: `40`, maintainer access level) |
 | `allowed_to_push` | array | no | Array of access levels allowed to push, with each described by a hash |
 | `allowed_to_merge` | array | no | Array of access levels allowed to merge, with each described by a hash |
 | `allowed_to_unprotect` | array | no | Array of access levels allowed to unprotect, with each described by a hash |
@@ -131,7 +131,7 @@ Example response:
       "access_level": 30,
       "user_id": null,
       "group_id": null,
-      "access_level_description": "Developers + Masters"
+      "access_level_description": "Developers + Maintainers"
     }
   ],
   "merge_access_levels": [
@@ -139,14 +139,14 @@ Example response:
       "access_level": 30,
       "user_id": null,
       "group_id": null,
-      "access_level_description": "Developers + Masters"
+      "access_level_description": "Developers + Maintainers"
   ],
   "unprotect_access_levels": [
     {
       "access_level": 40,
       "user_id": null,
       "group_id": null,
-      "access_level_description": "Masters"
+      "access_level_description": "Maintainers"
     }
   ]
 }
@@ -179,14 +179,14 @@ Example response:
       "access_level":40,
       "user_id":null,
       "group_id":null,
-      "access_level_description":"Masters"
+      "access_level_description":"Maintainers"
   ],
   "unprotect_access_levels": [
     {
       "access_level":40,
       "user_id":null,
       "group_id":null,
-      "access_level_description":"Masters"
+      "access_level_description":"Maintainers"
     }
   ]
 }

doc/api/services.md

 # Services API
 
->**Note:** This API requires an access token with Master or Owner permissions
+>**Note:** This API requires an access token with Maintainer or Owner permissions
 
 ## Asana
 

doc/api/settings.md

@@ -83,7 +83,7 @@ PUT /application/settings
 | `clientside_sentry_enabled`              | boolean          | no                                            | Enable Sentry error reporting for the client side                                                                                                                                                                                                                                                                                                                                                                                                         |
 | `container_registry_token_expire_delay`  | integer          | no                                            | Container Registry token duration in minutes                                                                                                                                                                                                                                                                                                                                                                                                              |
 | `default_artifacts_expire_in`            | string           | no                                            | Set the default expiration time for each job's artifacts                                                                                                                                                                                                                                                                                                                                                                                                  |
-| `default_branch_protection`              | integer          | no                                            | Determine if developers can push to master. Can take `0` _(not protected, both developers and masters can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and masters can push new commits, but cannot force push or delete the branch)_ or `2` _(fully protected, developers cannot push new commits, but masters can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. |
+| `default_branch_protection`              | integer          | no                                            | Determine if developers can push to master. Can take `0` _(not protected, both developers and maintainers can push new commits, force push, or delete the branch)_, `1` _(partially protected, developers and maintainers can push new commits, but cannot force push or delete the branch)_ or `2` _(fully protected, developers cannot push new commits, but maintainers can; no-one can force push or delete the branch)_ as a parameter. Default is `2`. |
 | `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_visibility`             | string           | no                                            | What visibility level new projects receive. Can take `private`, `internal` and `public` as a parameter. Default is `private`.                                                                                                                                                                                                                                                                                                                             |
 | `default_projects_limit`                 | integer          | no                                            | Project limit per user. Default is `100000`                                                                                                                                                                                                                                                                                                                                                                                                               |

doc/ci/environments.md

@@ -593,7 +593,7 @@ version of the app, all without leaving GitLab.
 
 >**Note:**
 Web terminals were added in GitLab 8.15 and are only available to project
-masters and owners.
+maintainers and owners.
 
 If you deploy to your environments with the help of a deployment service (e.g.,
 the [Kubernetes integration][kube]), GitLab can open

doc/ci/runners/README.md

@@ -84,7 +84,7 @@ visit the project you want to make the Runner work for in GitLab:
 
 ## Registering a group Runner
 
-Creating a group Runner requires Master permissions for the group. To create a
+Creating a group Runner requires Maintainer permissions for the group. To create a
 group Runner visit the group you want to make the Runner work for in GitLab:
 
 1. Go to **Settings > CI/CD** to obtain the token
@@ -120,9 +120,9 @@ To lock/unlock a Runner:
 
 ## Assigning a Runner to another project
 
-If you are Master on a project where a specific Runner is assigned to, and the
+If you are Maintainer on a project where a specific Runner is assigned to, and the
 Runner is not [locked only to that project](#locking-a-specific-runner-from-being-enabled-for-other-projects),
-you can enable the Runner also on any other project where you have Master permissions.
+you can enable the Runner also on any other project where you have Maintainer permissions.
 
 To enable/disable a Runner in your project:
 
@@ -132,7 +132,7 @@ To enable/disable a Runner in your project:
 
 > **Note**:
 Consider that if you don't lock your specific Runner to a specific project, any
-user with Master role in you project can assign your Runner to another arbitrary
+user with Maintainer role in you project can assign your Runner to another arbitrary
 project without requiring your authorization, so use it with caution.
 
 An admin can enable/disable a specific Runner for projects:

doc/development/documentation/index.md

@@ -327,7 +327,7 @@ this [development guide](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/R
 
 If you want to preview the doc changes of your merge request live, you can use
 the manual `review-docs-deploy` job in your merge request. You will need at
-least Master permissions to be able to run it and is currently enabled for the
+least Maintainer permissions to be able to run it and is currently enabled for the
 following projects:
 
 - https://gitlab.com/gitlab-org/gitlab-ce

doc/security/information_exclusivity.md

@@ -2,7 +2,7 @@
 
 Git is a distributed version control system (DVCS).
 This means that everyone that works with the source code has a local copy of the complete repository.
-In GitLab every project member that is not a guest (so reporters, developers and masters) can clone the repository to get a local copy.
+In GitLab every project member that is not a guest (so reporters, developers and maintainers) can clone the repository to get a local copy.
 After obtaining this local copy the user can upload the full repository anywhere, including another project under their control or another server.
 The consequence is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code.
 This is an inherent feature of a DVCS and all git management systems have this limitation.

doc/security/webhooks.md

@@ -2,7 +2,7 @@
 
 If you have non-GitLab web services running on your GitLab server or within its local network, these may be vulnerable to exploitation via Webhooks.
 
-With [Webhooks](../user/project/integrations/webhooks.md), you and your project masters and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way.
+With [Webhooks](../user/project/integrations/webhooks.md), you and your project maintainers and owners can set up URLs to be triggered when specific things happen to projects. Normally, these requests are sent to external web services specifically set up for this purpose, that process the request and its attached data in some appropriate way.
 
 Things get hairy, however, when a Webhook is set up with a URL that doesn't point to an external, but to an internal service, that may do something completely unintended when the webhook is triggered and the POST request is sent.
 

doc/ssh/README.md

@@ -171,7 +171,7 @@ This is really useful for cloning repositories to your Continuous
 Integration (CI) server. By using deploy keys, you don't have to set up a
 dummy user account.
 
-If you are a project master or owner, you can add a deploy key in the
+If you are a project maintainer or owner, you can add a deploy key in the
 project settings under the section 'Repository'. Specify a title for the new
 deploy key and paste a public SSH key. After this, the machine that uses
 the corresponding private SSH key has read-only or read-write (if enabled)
@@ -196,7 +196,7 @@ This is really useful for integrating repositories to secured, shared Continuous
 Integration (CI) services or other shared services. 
 GitLab administrators can set up the Global Shared Deploy key in GitLab and 
 add the private key to any shared systems.  Individual repositories opt into
-exposing their repository using these keys when a project masters (or higher)
+exposing their repository using these keys when a project maintainers (or higher)
 authorizes a Global Shared Deploy key to be used with their project. 
 
 Global Shared Keys can provide greater security compared to Per-Project Deploy
@@ -205,7 +205,7 @@ who needs to know and configure the private key.
 
 GitLab administrators set up Global Deploy keys in the Admin area under the
 section **Deploy Keys**. Ensure keys have a meaningful title as that will be
-the primary way for project masters and owners to identify the correct Global
+the primary way for project maintainers and owners to identify the correct Global
 Deploy key to add.  For instance, if the key gives access to a SaaS CI instance,
 use the name of that service in the key name if that is all it is used for.
 When creating Global Shared Deploy keys, give some thought to the granularity
@@ -213,7 +213,7 @@ of keys - they could be of very narrow usage such as just a specific service or
 of broader usage for something like "Anywhere you need to give read access to 
 your repository".
 
-Once a GitLab administrator adds the Global Deployment key, project masters 
+Once a GitLab administrator adds the Global Deployment key, project maintainers 
 and owners can add it in project's **Settings > Repository** section by expanding the 
 **Deploy Key** section and clicking **Enable** next to the appropriate key listed 
 under **Public deploy keys available to any project**.

doc/system_hooks/system_hooks.md

@@ -138,7 +138,7 @@ Please refer to `group_rename` and `user_rename` for that case.
                   "created_at": "2012-07-21T07:30:56Z",
                   "updated_at": "2012-07-21T07:38:22Z",
                   "event_name": "user_add_to_team",
-                "access_level": "Master",
+                "access_level": "Maintainer",
                   "project_id": 74,
                 "project_name": "StoreCloud",
                 "project_path": "storecloud",
@@ -158,7 +158,7 @@ Please refer to `group_rename` and `user_rename` for that case.
                   "created_at": "2012-07-21T07:30:56Z",
                   "updated_at": "2012-07-21T07:38:22Z",
                   "event_name": "user_remove_from_team",
-              "project_access": "Master",
+              "project_access": "Maintainer",
                   "project_id": 74,
                 "project_name": "StoreCloud",
                 "project_path": "storecloud",
@@ -318,7 +318,7 @@ If the user is blocked via LDAP, `state` will be `ldap_blocked`.
     "created_at": "2012-07-21T07:30:56Z",
     "updated_at": "2012-07-21T07:38:22Z",
     "event_name": "user_add_to_group",
-  "group_access": "Master",
+  "group_access": "Maintainer",
       "group_id": 78,
     "group_name": "StoreCloud",
     "group_path": "storecloud",
@@ -335,7 +335,7 @@ If the user is blocked via LDAP, `state` will be `ldap_blocked`.
     "created_at": "2012-07-21T07:30:56Z",
     "updated_at": "2012-07-21T07:38:22Z",
     "event_name": "user_remove_from_group",
-  "group_access": "Master",
+  "group_access": "Maintainer",
       "group_id": 78,
     "group_name": "StoreCloud",
     "group_path": "storecloud",

doc/user/discussions/index.md

@@ -11,7 +11,7 @@ You can leave a comment in the following places:
 - commit diffs
 
 The comment area supports [Markdown] and [quick actions]. One can edit their
-own comment at any time, and anyone with [Master access level][permissions] or
+own comment at any time, and anyone with [Maintainer access level][permissions] or
 higher can also edit a comment made by someone else.
 
 You could also reply to the notification email in order to reply to a comment,
@@ -253,7 +253,7 @@ to newer issues or merge requests.
 - The people participating in the discussion are trolling, abusive, or otherwise
 being unproductive.
 
-In these cases, a user with Master permissions or higher in the project can lock (and unlock)
+In these cases, a user with Maintainer permissions or higher in the project can lock (and unlock)
 an issue or a merge request, using the "Lock" section in the sidebar:
 
 | Unlock | Lock |

doc/user/group/index.md

@@ -125,7 +125,7 @@ side of your screen.
 
 ---
 
-Group owners and masters will be notified of your request and will be able to approve or
+Group owners and maintainers will be notified of your request and will be able to approve or
 decline it on the members page.
 
 ![Manage access requests](img/access_requests_management.png)
@@ -160,12 +160,12 @@ There are two different ways to add a new project to a group:
 Group owners or administrators can set an option that will give users with the
 Developer role the ability to create projects under groups.
 
-By default, `Developers` and `Masters` are allowed to create projects under a
+By default, `Developers` and `Maintainers` are allowed to create projects under a
 group, but this can be changed either within the group settings for a group, or
 be set globally by a GitLab administrator in the Admin area
 (**Settings > Visibility and Access Controls**).
 
-The setting can set to "None", "Masters", or "Developers + Masters".
+The setting can set to "None", "Maintainers", or "Developers + Maintainers".
 
 ## Transfer projects into groups
 

doc/user/group/subgroups/index.md

@@ -145,8 +145,8 @@ permissions.
 
 For example, if User0 was first added to group `group-1/group-1-1` with Developer
 permissions, then they will inherit those permissions in every other subgroup
-of `group-1/group-1-1`. To give them Master access to `group-1/group-1-1/group1-1-1`,
-you would add them again in that group as Master. Removing them from that group,
+of `group-1/group-1-1`. To give them Maintainer access to `group-1/group-1-1/group1-1-1`,
+you would add them again in that group as Maintainer. Removing them from that group,
 the permissions will fallback to those of the ancestor group.
 
 ## Mentioning subgroups

doc/user/index.md

@@ -111,7 +111,7 @@ personal access tokens, authorized applications, etc.
 - [Authentication](../topics/authentication/index.md): Read through the authentication
 methods available in GitLab.
 - [Permissions](permissions.md): Learn the different set of permissions levels for each
-user type (guest, reporter, developer, master, owner).
+user type (guest, reporter, developer, maintainer, owner).
 - [Feature highlight](feature_highlight.md): Learn more about the little blue dots
 around the app that explain certain features
 

doc/user/permissions.md

@@ -27,7 +27,7 @@ See our [product handbook on permissions](https://about.gitlab.com/handbook/prod
 
 The following table depicts the various user permission levels in a project.
 
-| Action                                | Guest   | Reporter   | Developer   | Master   | Owner  |
+| Action                                | Guest   | Reporter   | Developer   |Maintainer| Owner  |
 |---------------------------------------|---------|------------|-------------|----------|--------|
 | Create new issue                      | ✓ [^1]  | ✓          | ✓           | ✓        | ✓      |
 | Create confidential issue             | ✓ [^1]  | ✓          | ✓           | ✓        | ✓      |
@@ -113,7 +113,7 @@ review, we've created protected branches. Read through the documentation on
 [protected branches](project/protected_branches.md)
 to learn more.
 
-Additionally, you can allow or forbid users with Master and/or
+Additionally, you can allow or forbid users with Maintainer and/or
 Developer permissions to push to a protected branch. Read through the documentation on
 [Allowed to Merge and Allowed to Push settings](project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
 to learn more.
@@ -149,7 +149,7 @@ Any user can remove themselves from a group, unless they are the last Owner of
 the group. The following table depicts the various user permission levels in a
 group.
 
-| Action                  | Guest | Reporter | Developer | Master | Owner |
+| Action                  | Guest | Reporter | Developer | Maintainer | Owner |
 |-------------------------|-------|----------|-----------|--------|-------|
 | Browse group            | ✓     | ✓        | ✓         | ✓      | ✓     |
 | Edit group              |       |          |           |        | ✓     |
@@ -223,7 +223,7 @@ GitLab CI/CD permissions rely on the role the user has in GitLab. There are four
 permission levels in total:
 
 - admin
-- master
+- maintainer
 - developer
 - guest/reporter
 
@@ -231,7 +231,7 @@ The admin user can perform any action on GitLab CI/CD in scope of the GitLab
 instance and project. In addition, all admins can use the admin interface under
 `/admin/runners`.
 
-| Action                                | Guest, Reporter | Developer   | Master   | Admin  |
+| Action                                | Guest, Reporter | Developer   |Maintainer| Admin  |
 |---------------------------------------|-----------------|-------------|----------|--------|
 | See commits and jobs                  | ✓               | ✓           | ✓        | ✓      |
 | Retry or cancel job                   |                 | ✓           | ✓        | ✓      |
@@ -253,7 +253,7 @@ Read all about the [new model and its implications][new-mod].
 This table shows granted privileges for jobs triggered by specific types of
 users:
 
-| Action                                      | Guest, Reporter | Developer   | Master   | Admin  |
+| Action                                      | Guest, Reporter | Developer   |Maintainer| Admin  |
 |---------------------------------------------|-----------------|-------------|----------|--------|
 | Run CI job                                  |                 | ✓           | ✓        | ✓      |
 | Clone source and LFS from current project   |                 | ✓           | ✓        | ✓      |
@@ -296,7 +296,7 @@ with the permissions described on the documentation on [auditor users permission
 [^1]: On public and internal projects, all users are able to perform this action
 [^2]: Guest users can only view the confidential issues they created themselves
 [^3]: If **Public pipelines** is enabled in **Project Settings > CI/CD**
-[^4]: Not allowed for Guest, Reporter, Developer, Master, or Owner
+[^4]: Not allowed for Guest, Reporter, Developer, Maintainer, or Owner
 [^5]: Only if the job was triggered by the user
 [^6]: Only if user is not external one
 [^7]: Only if user is a member of the project

doc/user/project/clusters/index.md

@@ -19,7 +19,7 @@ or provide the credentials to an [existing Kubernetes cluster](#adding-an-existi
 ## Adding and creating a new GKE cluster via GitLab
 
 NOTE: **Note:**
-You need Master [permissions] and above to access the Kubernetes page.
+You need Maintainer [permissions] and above to access the Kubernetes page.
 
 Before proceeding, make sure the following requirements are met:
 
@@ -30,7 +30,7 @@ Before proceeding, make sure the following requirements are met:
   clusters on GKE. That would mean that a [billing
   account](https://cloud.google.com/billing/docs/how-to/manage-billing-account)
   must be set up and that you have to have permissions to access it.
-- You must have Master [permissions] in order to be able to access the
+- You must have Maintainer [permissions] in order to be able to access the
   **Kubernetes** page.
 - You must have [Cloud Billing API](https://cloud.google.com/billing/) enabled
 - You must have [Resource Manager
@@ -66,7 +66,7 @@ enable the Cluster integration.
 ## Adding an existing Kubernetes cluster
 
 NOTE: **Note:**
-You need Master [permissions] and above to access the Kubernetes page.
+You need Maintainer [permissions] and above to access the Kubernetes page.
 
 To add an existing Kubernetes cluster to your project:
 
@@ -333,7 +333,7 @@ To disable the Kubernetes cluster integration, follow the same procedure.
 ## Removing the Kubernetes cluster integration
 
 NOTE: **Note:**
-You need Master [permissions] and above to remove a Kubernetes cluster integration.
+You need Maintainer [permissions] and above to remove a Kubernetes cluster integration.
 
 NOTE: **Note:**
 When you remove a cluster, you only remove its relation to GitLab, not the
@@ -386,7 +386,7 @@ you will need the Kubernetes project integration enabled.
 ### Web terminals
 
 NOTE: **Note:**
-Introduced in GitLab 8.15. You must be the project owner or have `master` permissions
+Introduced in GitLab 8.15. You must be the project owner or have `maintainer` permissions
 to use terminals. Support is limited to the first container in the
 first pod of your environment.
 

doc/user/project/deploy_tokens/index.md

@@ -5,7 +5,7 @@
 Deploy tokens allow to download (through `git clone`), or read the container registry images of a project without the need of having a user and a password.
 
 Please note, that the expiration of deploy tokens happens on the date you define,
-at midnight UTC and that they can be only managed by [masters](https://docs.gitlab.com/ee/user/permissions.html).
+at midnight UTC and that they can be only managed by [maintainers](https://docs.gitlab.com/ee/user/permissions.html).
 
 ## Creating a Deploy Token
 

doc/user/project/integrations/index.md

@@ -2,7 +2,7 @@
 
 You can find the available integrations under your project's
 **Settings ➔ Integrations** page. You need to have at least
-[master permission][permissions] on the project.
+[maintainer permission][permissions] on the project.
 
 ## Project services
 

doc/user/project/issues/confidential_issues.md

@@ -71,10 +71,10 @@ least [Reporter access][permissions]. 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 Master and Guest access sees in the
+For example, here's what a user with Maintainer and Guest access sees in the
 project's search results respectively.
 
-| Master access | Guest access |
+| Maintainer access | Guest access |
 | :-----------: | :----------: |
 | ![Confidential issues search master](img/confidential_issues_search_master.png) | ![Confidential issues search guest](img/confidential_issues_search_guest.png) |
 

doc/user/project/members/index.md

@@ -4,7 +4,7 @@ You can manage the groups and users and their access levels in all of your
 projects. You can also personalize the access level you give each user,
 per-project.
 
-You should have `master` or `owner` [permissions](../../permissions.md) to add
+You should have Maintainer or Owner [permissions](../../permissions.md) to add
 or import a new user to your project.
 
 To view, edit, add, and remove project's members, go to your
@@ -43,7 +43,7 @@ level to the project.
 You can import another project's users in your own project by hitting the
 **Import members** button on the upper right corner of the **Members** menu.
 
-In the dropdown menu, you can see only the projects you are Master on.
+In the dropdown menu, you can see only the projects you are Maintainer on.
 
 ![Import members from another project](img/add_user_import_members_from_another_project.png)
 
@@ -99,7 +99,7 @@ side of your screen.
 
 ---
 
-Project owners & masters will be notified of your request and will be able to approve or
+Project owners & maintainers will be notified of your request and will be able to approve or
 decline it on the members page.
 
 ![Manage access requests](img/access_requests_management.png)

doc/user/project/members/share_project_with_groups.md

@@ -42,7 +42,7 @@ Admins are able to share projects with any group in the system.
 
 ## Maximum access level
 
-In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Master' or 'Owner') will only have 'Developer' access to 'Project Acme'.
+In the example above, the maximum access level of 'Developer' for members from 'Engineering' means that users with higher access levels in 'Engineering' ('Maintainer' or 'Owner') will only have 'Developer' access to 'Project Acme'.
 
 ## Share project with group lock
 

doc/user/project/merge_requests/authorization_for_merge_requests.md

@@ -9,7 +9,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 Master access and the regular developers get
+The project maintainers get Maintainer access and the regular developers get
 Developer access.
 
 The maintainers mark the authoritative branches as 'Protected'.
@@ -18,7 +18,7 @@ The 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 Master access can merge changes into a protected
+By default, only users with Maintainer access can merge changes into a protected
 branch.
 
 **Advantages**
@@ -32,7 +32,7 @@ branch.
 
 ## Forking workflow
 
-With the forking workflow the maintainers get Master access and the regular
+With the forking workflow the maintainers get Maintainer access and the regular
 developers get Reporter access to the authoritative repository, which prohibits
 them from pushing any changes to it.
 

doc/user/project/merge_requests/index.md

@@ -92,7 +92,7 @@ request is merged.
 
 This option is also visible in an existing merge request next to the merge
 request button and can be selected/deselected before merging. It's only visible
-to users with [Master permissions](../../permissions.md) in the source project.
+to users with [Maintainer permissions](../../permissions.md) in the source project.
 
 If the user viewing the merge request does not have the correct permissions to
 remove the source branch and the source branch is set for removal, the merge

doc/user/project/protected_branches.md

@@ -10,8 +10,8 @@ created protected branches.
 By default, a protected branch does four simple things:
 
 - it prevents its creation, if not already created, from everybody except users
-  with Master permission
-- it prevents pushes from everybody except users with Master permission
+  with Maintainer permission
+- it prevents pushes from everybody except users with Maintainer permission
 - it prevents **anyone** from force pushing to the branch
 - it prevents **anyone** from deleting the branch
 
@@ -22,7 +22,7 @@ See the [Changelog](#changelog) section for changes over time.
 
 ## Configuring protected branches
 
-To protect a branch, you need to have at least Master permission level. Note
+To protect a branch, you need to have at least Maintainer permission level. Note
 that the `master` branch is protected by default.
 
 1. Navigate to your project's **Settings ➔ Repository**
@@ -43,19 +43,19 @@ that the `master` branch is protected by default.
 Since GitLab 8.11, we added another layer of branch protection which provides
 more granular management of protected branches. The "Developers can push"
 option was replaced by an "Allowed to push" setting which can be set to
-allow/prohibit Masters and/or Developers to push to a protected branch.
+allow/prohibit Maintainers and/or Developers to push to a protected branch.
 
 Using the "Allowed to push" and "Allowed to merge" settings, you can control
 the actions that different roles can perform with the protected branch.
 For example, you could set "Allowed to push" to "No one", and "Allowed to merge"
-to "Developers + Masters", to require _everyone_ to submit a merge request for
+to "Developers + Maintainers", to require _everyone_ to submit a merge request for
 changes going into the protected branch. This is compatible with workflows like
 the [GitLab workflow](../../workflow/gitlab_flow.md).
 
 However, there are workflows where that is not needed, and only protecting from
 force pushes and branch removal is useful. For those workflows, you can allow
 everyone with write access to push to a protected branch by setting
-"Allowed to push" to "Developers + Masters".
+"Allowed to push" to "Developers + Maintainers".
 
 You can set the "Allowed to push" and "Allowed to merge" options while creating
 a protected branch or afterwards by selecting the option you want from the
@@ -64,14 +64,14 @@ dropdown list in the "Already protected" area.
 ![Developers can push](img/protected_branches_devs_can_push.png)
 
 If you don't choose any of those options while creating a protected branch,
-they are set to "Masters" by default.
+they are set to "Maintainers" by default.
 
 ## Restricting push and merge access to certain users **[STARTER]**
 
 > This feature was [introduced][ce-5081] in [GitLab Starter][ee] 8.11.
 
 With GitLab Enterprise Edition you can restrict access to protected branches
-by choosing a role (Masters, Developers) as well as certain users. From the
+by choosing a role (Maintainers, Developers) as well as certain users. From the
 dropdown menu select the role and/or the users you want to have merge or push
 access.
 
@@ -114,7 +114,7 @@ all matching branches:
 From time to time, it may be required to delete or clean up branches that are
 protected.
 
-User with [Master permissions][perm] and up can manually delete protected
+User with [Maintainer permissions][perm] and up can manually delete protected
 branches via GitLab's web interface:
 
 1. Visit **Repository > Branches**

doc/user/project/protected_tags.md

@@ -8,12 +8,12 @@ This feature evolved out of [Protected Branches](protected_branches.md)
 
 ## Overview
 
-Protected tags will prevent anyone from updating or deleting the tag, as and will prevent creation of matching tags based on the permissions you have selected. By default, anyone without Master permission will be prevented from creating tags.
+Protected tags will prevent anyone from updating or deleting the tag, as and will prevent creation of matching tags based on the permissions you have selected. By default, anyone without Maintainer permission will be prevented from creating tags.
 
 
 ## Configuring protected tags
 
-To protect a tag, you need to have at least Master permission level.
+To protect a tag, you need to have at least Maintainer permission level.
 
 1. Navigate to the project's Settings -> Repository page
 

doc/user/project/settings/import_export.md

@@ -19,7 +19,7 @@
 >  - The exports are stored in a temporary [shared directory][tmp] and are deleted
 >    every 24 hours by a specific worker.
 >  - Group members will get exported as project members, as long as the user has
->    master or admin access to the group where the exported project lives. An admin
+>    maintainer or admin access to the group where the exported project lives. An admin
 >    in the import side is required to map the users, based on email or username.
 >    Otherwise, a supplementary comment is left to mention the original author and
 >    the MRs, notes or issues will be owned by the importer.

doc/user/project/settings/index.md

 # Project settings
 
 NOTE: **Note:**
-Only project Masters and Admin users have the [permissions] to access a project
+Only project Maintainers and Admin users have the [permissions] to access a project
 settings.
 
 You can adjust your [project](../index.md) settings by navigating
@@ -74,7 +74,7 @@ To archive a project:
 #### Renaming a repository
 
 NOTE: **Note:**
-Only project Masters and Admin users have the [permissions] to rename a
+Only project Maintainers and Admin users have the [permissions] to rename a
 repository. Not to be confused with a project's name where it can also be
 changed from the [general project settings](#general-project-settings).
 
@@ -98,7 +98,7 @@ Only project Owners and Admin users have the [permissions] to transfer a project
 
 You can transfer an existing project into a [group](../../group/index.md) if:
 
-1. you have at least **Master** [permissions] to that group
+1. you have at least **Maintainer** [permissions] to that group
 1. you are an **Owner** of the project.
 
 Similarly, if you are an owner of a group, you can transfer any of its projects

doc/workflow/gitlab_flow.md

@@ -131,7 +131,7 @@ There is room for more feedback and after the assigned person feels comfortable
 If the assigned person does not feel comfortable they can close the merge request without merging.
 
 In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers [can't modify these protected branches](http://docs.gitlab.com/ce/permissions/permissions.html).
-So if you want to merge it into a protected branch you assign it to someone with master authorizations.
+So if you want to merge it into a protected branch you assign it to someone with maintainer authorizations.
 
 ## Issue tracking with GitLab flow
 

doc/workflow/lfs/manage_large_binaries_with_git_lfs.md

@@ -144,7 +144,7 @@ git lfs unlock --id=123
 ```
 
 If for some reason you need to unlock a file that was not locked by you,
-you can use the `--force` flag as long as you have a `master` access on
+you can use the `--force` flag as long as you have a `maintainer` access on
 the project:
 
 ```bash

ee/app/views/shared/promotions/_promote_repository_features.html.haml

@@ -26,6 +26,6 @@
             %li
               = link_to 'Better Protected Branches', help_page_path('user/project/protected_branches.html'), target: '_blank'
               %p
-                You can restrict access to protected branches by choosing a role (Masters, Developers) as well as certain users.
+                You can restrict access to protected branches by choosing a role (Maintainers, Developers) as well as certain users.
 
         = render 'shared/promotions/promotion_link_project'

ee/lib/ee/gitlab/access.rb

@@ -16,8 +16,8 @@ module EE
       def project_creation_options
         {
           s_('ProjectCreationLevel|No one') => NO_ONE_PROJECT_ACCESS,
-          s_('ProjectCreationLevel|Masters') => MASTER_PROJECT_ACCESS,
-          s_('ProjectCreationLevel|Developers + Masters') => DEVELOPER_MASTER_PROJECT_ACCESS
+          s_('ProjectCreationLevel|Maintainers') => MASTER_PROJECT_ACCESS,
+          s_('ProjectCreationLevel|Developers + Maintainers') => DEVELOPER_MASTER_PROJECT_ACCESS
         }
       end
     end

ee/spec/features/groups/audit_events_spec.rb

@@ -45,7 +45,7 @@ feature 'Groups > Audit Events', :js do
 
       page.within "#group_member_#{group_member.id}" do
         click_button 'Developer'
-        click_link 'Master'
+        click_link 'Maintainer'
       end
 
       find(:link, text: 'Settings').click
@@ -53,7 +53,7 @@ feature 'Groups > Audit Events', :js do
       click_link 'Audit Events'
 
       page.within('table#audits') do
-        expect(page).to have_content 'Change access level from developer to master'
+        expect(page).to have_content 'Change access level from developer to maintainer'
         expect(page).to have_content(user.name)
         expect(page).to have_content('Pete')
       end

ee/spec/features/projects/audit_events_spec.rb

@@ -98,7 +98,7 @@ feature 'Projects > Audit Events', :js do
 
       page.within "#project_member_#{project_member.id}" do
         click_button 'Developer'
-        click_link 'Master'
+        click_link 'Maintainer'
       end
 
       find(:link, text: 'Settings').click
@@ -106,7 +106,7 @@ feature 'Projects > Audit Events', :js do
       click_link 'Audit Events'
 
       page.within('table#audits') do
-        expect(page).to have_content 'Change access level from developer to master'
+        expect(page).to have_content 'Change access level from developer to maintainer'
         expect(page).to have_content(project.owner.name)
         expect(page).to have_content('Pete')
       end

ee/spec/support/helpers/ee/protected_branch_helpers.rb

 module EE
   module ProtectedBranchHelpers
-    def set_allowed_to(operation, option = 'Masters', form: '.js-new-protected-branch')
+    def set_allowed_to(operation, option = 'Maintainers', form: '.js-new-protected-branch')
       within form do
         find(".js-allowed-to-#{operation}").click
         wait_for_requests

lib/api/protected_branches.rb

@@ -41,13 +41,13 @@ module API
         requires :name, type: String, desc: 'The name of the protected branch'
         optional :push_access_level, type: Integer,
                                      values: ProtectedRefAccess::ALLOWED_ACCESS_LEVELS,
-                                     desc: 'Access levels allowed to push (defaults: `40`, master access level)'
+                                     desc: 'Access levels allowed to push (defaults: `40`, maintainer access level)'
         optional :merge_access_level, type: Integer,
                                       values: ProtectedRefAccess::ALLOWED_ACCESS_LEVELS,
-                                      desc: 'Access levels allowed to merge (defaults: `40`, master access level)'
+                                      desc: 'Access levels allowed to merge (defaults: `40`, maintainer access level)'
         optional :unprotect_access_level, type: Integer,
                                           values: ProtectedRefAccess::ALLOWED_ACCESS_LEVELS,
-                                          desc: 'Access levels allowed to unprotect (defaults: `40`, master access level)'
+                                          desc: 'Access levels allowed to unprotect (defaults: `40`, maintainer access level)'
         optional :allowed_to_push, type: Array, desc: 'An array of users/groups allowed to push' do
           optional :access_level, type: Integer, values: ProtectedRefAccess::ALLOWED_ACCESS_LEVELS
           optional :user_id, type: Integer

lib/gitlab/access.rb

@@ -32,10 +32,10 @@ module Gitlab
 
       def options
         {
-          "Guest"     => GUEST,
-          "Reporter"  => REPORTER,
-          "Developer" => DEVELOPER,
-          "Master"    => MASTER
+          "Guest"      => GUEST,
+          "Reporter"   => REPORTER,
+          "Developer"  => DEVELOPER,
+          "Maintainer" => MASTER
         }
       end
 
@@ -60,10 +60,10 @@ module Gitlab
 
       def protection_options
         {
-          "Not protected: Both developers and masters can push new commits, force push, or delete the branch." => PROTECTION_NONE,
-          "Protected against pushes: Developers cannot push new commits, but are allowed to accept merge requests to the branch. Masters can push to the branch." => PROTECTION_DEV_CAN_MERGE,
-          "Partially protected: Both developers and masters can push new commits, but cannot force push or delete the branch." => PROTECTION_DEV_CAN_PUSH,
-          "Fully protected: Developers cannot push new commits, but masters can. No-one can force push or delete the branch." => PROTECTION_FULL
+          "Not protected: Both developers and maintainers can push new commits, force push, or delete the branch." => PROTECTION_NONE,
+          "Protected against pushes: Developers cannot push new commits, but are allowed to accept merge requests to the branch. Maintainers can push to the branch." => PROTECTION_DEV_CAN_MERGE,
+          "Partially protected: Both developers and maintainers can push new commits, but cannot force push or delete the branch." => PROTECTION_DEV_CAN_PUSH,
+          "Fully protected: Developers cannot push new commits, but maintainers can. No-one can force push or delete the branch." => PROTECTION_FULL
         }
       end
 

lib/gitlab/checks/change_access.rb

@@ -7,7 +7,7 @@ module Gitlab
         push_code: 'You are not allowed to push code to this project.',
         delete_default_branch: 'The default branch of a project cannot be deleted.',
         force_push_protected_branch: 'You are not allowed to force push code to a protected branch on this project.',
-        non_master_delete_protected_branch: 'You are not allowed to delete protected branches from this project. Only a project master or owner can delete a protected branch.',
+        non_master_delete_protected_branch: 'You are not allowed to delete protected branches from this project. Only a project maintainer or owner can delete a protected branch.',
         non_web_delete_protected_branch: 'You can only delete protected branches using the web interface.',
         merge_protected_branch: 'You are not allowed to merge code into protected branches on this project.',
         push_protected_branch: 'You are not allowed to push code to protected branches on this project.',

locale/gitlab.pot

@@ -519,7 +519,7 @@ msgstr ""
 msgid "Ascending"
 msgstr ""
 
-msgid "Ask your group master to setup a group Runner."
+msgid "Ask your group maintainer to setup a group Runner."
 msgstr ""
 
 msgid "Assertion consumer service URL"
@@ -833,7 +833,7 @@ msgstr ""
 msgid "Branches|Once you confirm and press %{delete_protected_branch}, it cannot be undone or recovered."
 msgstr ""
 
-msgid "Branches|Only a project master or owner can delete a protected branch"
+msgid "Branches|Only a project maintainer or owner can delete a protected branch"
 msgstr ""
 
 msgid "Branches|Overview"
@@ -2758,7 +2758,7 @@ msgstr ""
 msgid "Group Runners"
 msgstr ""
 
-msgid "Group masters can register group runners in the %{link}"
+msgid "Group maintainers can register group runners in the %{link}"
 msgstr ""
 
 msgid "GroupRoadmap|From %{dateWord}"
@@ -5815,7 +5815,7 @@ msgstr ""
 msgid "You have reached your project limit"
 msgstr ""
 
-msgid "You must have master access to force delete a lock"
+msgid "You must have maintainer access to force delete a lock"
 msgstr ""
 
 msgid "You must sign in to star a project"

qa/qa/page/project/settings/protected_branches.rb

@@ -43,7 +43,7 @@ module QA
           end
 
           def allow_devs_and_masters_to_push
-            click_allow(:push, 'Developers + Masters')
+            click_allow(:push, 'Developers + Maintainers')
           end
 
           def allow_no_one_to_merge
@@ -51,7 +51,7 @@ module QA
           end
 
           def allow_devs_and_masters_to_merge
-            click_allow(:merge, 'Developers + Masters')
+            click_allow(:merge, 'Developers + Maintainers')
           end
 
           def protect_branch

qa/qa/specs/features/repository/protected_branches_spec.rb

@@ -35,7 +35,7 @@ module QA
       end
 
       expect(protected_branch.name).to have_content(branch_name)
-      expect(protected_branch.push_allowance).to have_content('Developers + Masters')
+      expect(protected_branch.push_allowance).to have_content('Developers + Maintainers')
     end
 
     scenario 'users without authorization cannot push to protected branch' do

spec/features/projects/settings/user_manages_group_links_spec.rb

@@ -30,7 +30,7 @@ describe 'Projects > Settings > User manages group links' do
     click_link('Share with group')
 
     select2(group_market.id, from: '#link_group_id')
-    select('Master', from: 'link_group_access')
+    select('Maintainer', from: 'link_group_access')
 
     click_button('Share')
 

spec/features/projects/settings/user_manages_project_members_spec.rb

@@ -62,7 +62,7 @@ describe 'Projects > Settings > User manages project members' do
 
     page.within('.project-members-groups') do
       expect(page).to have_content('OpenSource')
-      expect(first('.group_member')).to have_content('Master')
+      expect(first('.group_member')).to have_content('Maintainer')
     end
   end
 end

spec/features/protected_branches_spec.rb

@@ -74,7 +74,7 @@ feature 'Protected Branches', :js do
           click_link 'No one'
           find(".js-allowed-to-push").click
           wait_for_requests
-          click_link 'Developers + Masters'
+          click_link 'Developers + Maintainers'
         end
 
         visit project_protected_branches_path(project)
@@ -84,7 +84,7 @@ feature 'Protected Branches', :js do
             expect(page.find(".dropdown-toggle-text")).to have_content("No one")
           end
           page.within(".js-allowed-to-push") do
-            expect(page.find(".dropdown-toggle-text")).to have_content("Developers + Masters")
+            expect(page.find(".dropdown-toggle-text")).to have_content("Developers + Maintainers")
           end
         end
       end

spec/features/protected_tags_spec.rb

@@ -8,7 +8,7 @@ feature 'Protected Tags', :js do
     sign_in(user)
   end
 
-  def set_allowed_to(operation, option = 'Masters', form: '.new-protected-tag')
+  def set_allowed_to(operation, option = 'Maintainers', form: '.new-protected-tag')
     within form do
       find(".js-allowed-to-#{operation}").click
       wait_for_requests

spec/features/runners_spec.rb

@@ -184,7 +184,7 @@ feature 'Runners' do
 
     given(:group) { create :group }
 
-    context 'as project and group master' do
+    context 'as project and group maintainer' do
       background do
         group.add_master(user)
       end
@@ -197,13 +197,13 @@ feature 'Runners' do
 
           expect(page).to have_content 'This group does not provide any group Runners yet'
 
-          expect(page).to have_content 'Group masters can register group runners in the Group CI/CD settings'
-          expect(page).not_to have_content 'Ask your group master to setup a group Runner'
+          expect(page).to have_content 'Group maintainers can register group runners in the Group CI/CD settings'
+          expect(page).not_to have_content 'Ask your group maintainer to setup a group Runner'
         end
       end
     end
 
-    context 'as project master' do
+    context 'as project maintainer' do
       context 'project without a group' do
         given(:project) { create :project }
 
@@ -223,8 +223,8 @@ feature 'Runners' do
 
           expect(page).to have_content 'This group does not provide any group Runners yet.'
 
-          expect(page).not_to have_content 'Group masters can register group runners in the Group CI/CD settings'
-          expect(page).to have_content 'Ask your group master to setup a group Runner.'
+          expect(page).not_to have_content 'Group maintainers can register group runners in the Group CI/CD settings'
+          expect(page).to have_content 'Ask your group maintainer to setup a group Runner.'
         end
       end
 

spec/javascripts/notes/components/note_actions_spec.js

@@ -20,7 +20,7 @@ describe('issue_note_actions component', () => {
 
     beforeEach(() => {
       props = {
-        accessLevel: 'Master',
+        accessLevel: 'Maintainer',
         authorId: 26,
         canDelete: true,
         canEdit: true,
@@ -67,7 +67,7 @@ describe('issue_note_actions component', () => {
     beforeEach(() => {
       store.dispatch('setUserData', {});
       props = {
-        accessLevel: 'Master',
+        accessLevel: 'Maintainer',
         authorId: 26,
         canDelete: false,
         canEdit: false,

spec/lib/gitlab/checks/change_access_spec.rb

@@ -52,7 +52,7 @@ describe Gitlab::Checks::ChangeAccess do
       context 'with protected tag' do
         let!(:protected_tag) { create(:protected_tag, project: project, name: 'v*') }
 
-        context 'as master' do
+        context 'as maintainer' do
           before do
             project.add_master(user)
           end
@@ -138,7 +138,7 @@ describe Gitlab::Checks::ChangeAccess do
 
           context 'if the user is not allowed to delete protected branches' do
             it 'raises an error' do
-              expect { subject.exec }.to raise_error(Gitlab::GitAccess::UnauthorizedError, 'You are not allowed to delete protected branches from this project. Only a project master or owner can delete a protected branch.')
+              expect { subject.exec }.to raise_error(Gitlab::GitAccess::UnauthorizedError, 'You are not allowed to delete protected branches from this project. Only a project maintainer or owner can delete a protected branch.')
             end
           end
 

spec/models/project_team_spec.rb

@@ -203,14 +203,14 @@ describe ProjectTeam do
   end
 
   describe "#human_max_access" do
-    it 'returns Master role' do
+    it 'returns Maintainer role' do
       user = create(:user)
       group = create(:group)
       project = create(:project, namespace: group)
 
       group.add_master(user)
 
-      expect(project.team.human_max_access(user.id)).to eq 'Master'
+      expect(project.team.human_max_access(user.id)).to eq 'Maintainer'
     end
 
     it 'returns Owner role' do

spec/services/lfs/unlock_file_service_spec.rb

@@ -80,12 +80,12 @@ describe Lfs::UnlockFileService do
             result = subject.execute
 
             expect(result[:status]).to eq(:error)
-            expect(result[:message]).to match(/You must have master access/)
+            expect(result[:message]).to match(/You must have maintainer access/)
             expect(result[:http_status]).to eq(403)
           end
         end
 
-        context 'by a master user' do
+        context 'by a maintainer user' do
           let(:current_user) { master }
           let(:params) do
             { id: lock.id,