Rename the `Master` role to `Maintainer`

Requirements

• Rename Master role to Maintainer.
• Replace the copy below with Allow commits from members who can merge to the target branch.

Original description

Summary

The administrators of a repository are labelled “Master”, which is problematic language, both because of it being gendered, and because of the slavery-related connotations. Alternatives could be “custodian”, “administrator”, ...

Steps to reproduce

Create a repository, be labelled its master.

Example Project

What is the current bug behavior?

Repository administrators are called “masters”.

What is the expected correct behavior?

Use alternative wording.

Output of checks

This bug happens on salsa.debian.org, and likely on gitlab.com too

Possible fixes

Use alternative wording, such as “custodian” or “administrator”.

@gitlab team: Please handle this, soon!

PS: This was initially reported on salsa.debian.org: https://salsa.debian.org/salsa/support/issues/48

@nicoonoclaste Thanks for the feedback and the links to the original issue

@sarrahvesselov Please could you take a look?

added UX label

'Administrator' works for me @markglenfletcher. I don't see any far-reaching repercussions to changing the wording here.

cc/ @victorwu

added Plan [DEPRECATED] label

'Administrator' does clash with our current 'power role' of 'Admin':

@smcgivern @DouweM on impact and alternative naming choices?

@victorwu We'd need to change some code, but this would be mostly a find-replace. As for the name, we can't use "Administrator" as @markglenfletcher points out.

@jramsay @JobV Thoughts?

I can't think of any major impact. I think 'Administrator' isn't a good choice because of the conflict @markglenfletcher mentioned, and 'Master' is currently below 'Owner', so you'd have global admins who were above owners, but group admins who were below them. However, it's the most accurate option.

We could also go for 'Maintainer', like we do for the GitLab project itself: https://about.gitlab.com/handbook/engineering/projects/

EDIT: although a minor problem with that is that some people have the master role on this project, but not a maintainer role on the project according to the page. (Typically because they were a release manager, and needed extra access.)

@smcgivern I like "Maintainer", also in how it relates to the role below it: "Developer".

It also shares the same two initial and trailing letters with the current role, which means if we do change to that, it's easier for people to spot when scanning, according to this incontrovertible evidence: https://en.wikipedia.org/wiki/Typoglycemia

changed title from Rename the “master” role to Rename the {+Master role to Maintainer+}

changed the description

Thanks for surfacing the problem with using "Administrator" @markglenfletcher. I like "Maintainer" as well.

The change sounds good. I'm just curious about the history of Master level access and how we ended up where we are today

added Inclusion label

@smcgivern @DouweM : Is there a preference on whether ~Discussion or ~Platform works on this (or some other team?)

cc @jramsay

@victorwu It's access control related, so it would typically be ~Platform, but ultimately it doesn't matter all too much who does it :)

It's a matter of scheduling at this point, I think.

+1 for Maintainer

changed milestone to %11.0

mentioned in merge request !17395 (merged)

@victorwu any reason this is %11.0 or could it be addressed sooner?

@jramsay : See the discussions here: https://gitlab.slack.com/archives/C389370FL/p1520268155000720. I think we could do it in 10.8. But 11.0 is just right after 10.8 anyways.

One big problem with renaming Master to Maintainer is that it means we are no longer using Maintainer it typical sense, which is the collective name for anyone who has write permissions to the project.

It's important we have a term for the group of masters and developers when describing features like allowing maintainers to push to forks.

Currently: maintainer ⇔ owner ∪ master ∪ developers

I think we should find a different term to replace master.

What about Manager (maintainers ⇔ owner ∪ managers ∪ developers)?

added Deliverable label

added backend label

changed title from Rename the Master role to {-Maintain-}er to Rename the Master role to {+Maintainer Manag+}er

changed title from Rename the Master role to {-Maintainer -}Manager to Rename the Master role to {+Maintainer/+}Manager

changed the description

To counter my own point from a few months back, maybe Maintainer strictly means write permission to master or the main branch (maintainer ⇔ owner ∪ master). Which would mean Maintainer is a good name, maybe

@jramsay : We have at least one place I'm aware of where we already use the term "Maintainer" in the product. I.e. https://docs.gitlab.com/ee/user/project/merge_requests/maintainer_access.html.

So if we go with maintainer, we'd at least have to change the word in that feature. I imagine that would entail just changing that word in the merge request UI right?

my 2 cents: maintainer is better wording as it doesn't get confused with people's own role in a company, like: "why the developer has Manager in the name, and the manager has guest or reporter etc."

@jramsay @victorwu What we call maintainer now, has permissions to push to push to a certain branch, in case of the feature mentioned, that would often be master. So a Manager could be a maintainer, but so could a Developer, if the settings are set to allow that push access.

The role we're talking about has extra permissions that don't relate to the repository: f.e. Managing members.

Imho the name Maintainer reflects more what the user can do on the repository, while Manager incorporates the extra permissions as well.

One way to free the term "Admin" to be used here, is to make the distinction everywhere of the context it is in:

"Project Admin", "Group Admin", "System Admin".

I'd too root in for Maintainer as that's also common term referred for repositories in general.

Given the context of the other permission levels detailed in the docs Manager actually makes sense to me. Towards the bottom of the current Master list, about 7 of the specific abilities have "Manage" in the description.

Other options (based on referencing a thesuarus) could be Controller, Supervisor, or Executive.

@victorwu My first reaction was that I don't want to rename Master to Manager because I want to introduce a new role specifically for managers and product managers, with the assumption that they need more access than Developers, but less than Masters.

Specifically, I find myself, as a product manager, needing more than Developer, but don't want Master, mainly because I don't want "Push to protected branches" permissions. Then again, that can be disabled at the project level...

We might want to delay this so we can pair it with improvements to our permissions system.

There is a suggestion for a manager role in https://gitlab.com/gitlab-org/gitlab-ce/issues/45414, suggestion for creating a new project-owner role in https://gitlab.com/gitlab-org/gitlab-ee/issues/4800#note_69563436 and having the existing owner be more like a creator, and I've opened a UX research proposal in ux-research#62 (closed).

If we targeted those improvements to permissions as the main change in GitLab 12.0 it would make sense to also do this rename at that point.

I was going to say exactly what @jamedjo says above. Just changing a name is confusing and provides little direct benefit. Would be good to roll this up together.

Don't think we'd need a major release for that, though. And it's worthwhile having UX research looking at this as well.

My concern with maintainer is that the master role includes additional permissions that what one would not normally think a maintainer would have. These include ops roles, the ability to edit project settings, etc.

This may introduce confusion if you were expecting it to only have the access rights for pushing to the main branch.

supervisor or superintendent could be used to imply more of the administrative permissions and current project permission hierarchy without conflicting with something like manager. Also they start with super like super user.

Master -> Owner ?

Master -> Owner ?

@nick.thomas We already have Owners which would make that rename quite confusing. In https://about.gitlab.com/handbook/product/#permissions-in-gitlab @dzaporozhets describe Owners as users with additional destructive capabilities. We could rename project Owners to be called Creators, but what would we rename group-owners to?

Can't we go the easy way suggested in https://gitlab.com/gitlab-org/gitlab-ce/issues/42751#note_71072647 for now?

Project Admin doesn't conflict with anything and it's clear immediatly what the purpose of the role is.
If necessary we can reevalute this when other new roles are added, but for now let's keep it simple