Doc update

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/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
 ```
 
 ## List protected branches
@@ -36,13 +36,13 @@ Example response:
     "push_access_levels": [
       {
         "access_level": 40,
-        "access_level_description": "Masters"
+        "access_level_description": "Maintainers"
       }
     ],
     "merge_access_levels": [
       {
         "access_level": 40,
-        "access_level_description": "Masters"
+        "access_level_description": "Maintainers"
       }
     ]
   },
@@ -75,13 +75,13 @@ Example response:
   "push_access_levels": [
     {
       "access_level": 40,
-      "access_level_description": "Masters"
+      "access_level_description": "Maintainers"
     }
   ],
   "merge_access_levels": [
     {
       "access_level": 40,
-      "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/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/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",
-              "project_access": "Master",
+              "project_access": "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/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/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]  | ✓          | ✓           | ✓        | ✓      |
@@ -109,7 +109,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.
@@ -150,7 +150,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              |       |          |           |        | ✓     |
@@ -208,7 +208,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                   |                 | ✓           | ✓        | ✓      |
@@ -230,7 +230,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   |                 | ✓           | ✓        | ✓      |
@@ -276,7 +276,7 @@ only.
 [^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:
 
@@ -325,7 +325,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

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

@@ -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)
 

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

@@ -85,7 +85,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
 
@@ -24,7 +24,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**
@@ -45,7 +45,7 @@ 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.
@@ -66,7 +66,7 @@ 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.
 
 ## Wildcard protected branches
 
@@ -101,7 +101,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/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