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”.
@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.
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.
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.)
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
12
Victor Wuchanged title from Rename the “master” role to Rename the {+Master role to Maintainer+}
changed title from Rename the “master” role to Rename the {+Master role to Maintainer+}
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.
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
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.
Given the context of the other permission levels detailed in the docsManager 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...
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.
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
Is there a user-visible distinction between master and owner? I know they differ in the code, but it's not clear to me that they represent distinct permission sets to the user?
I had a conversation recently with @jramsay. We agreed on Maintainer name as the best alternative so far.
We don't do Manager because there is a proposal to have a manager as separate role https://gitlab.com/gitlab-org/gitlab-ce/issues/45414 and we don't do administrator because master does not have destructive permissions.
We should do it in the major release so %11.0 fits perfectly.
Thanks @lulalala for the reminder. Let's consider the docs update separately when we get closer (and should be based on the wording we choose for the in-product copy).
@lulalala : Yes, I think that is fine because Maintainer now refers to a role. We can improve the documentation later. But I think what you have is great for the purpose of this issue.
@victorwu I don't know, we don't really have versioning for webhooks. I think we should just call that out in the release post, and then if we need to add another field for compatibility, we can.
I don't understand how the word Master is in any way offensive. It derives from the Latin word magister which means head, chief, superior - generally someone with an elevated rank.
Its opposite is minister, which translates to a person with less rank.
Maintainer is a person who has power over you, in other words 'holds on you his hands' which implies a not only physical relation but a more dependent one.
In the end of the day, I don't really care which words are used for what, but keep in mind that when looking at the use history and etymology of a word, one can always find a time period when it was used in a context which a person from another time or background finds offensive.
Controlling word use and the lack of consistency bothers me however - I can but wonder, what master branches will be renamed to.
Additionally it's quite ironic to strive for conformity in a product which's name derives from the word git.
I applaud you for your social awareness and sense of social responsibility and I agree with you that we should all be considerate and inclusive. However, I am not a fan of this change having been put in GitLab EE 11.0 because it is a breaking change for us and other companies that have documentation, practices, training, culture, AD groups, etc all wrapped around the the Gitlab product and specifically the roles as they were before you made the change.
Did you get any consensus from the user community, especially EE community?
Were a lot of customers complaining or asking for this change?
Did you consider all of the things in a customer's environment that might break if we deploy the new version with this change in it?
My opinion is that GitLab is THE BEST product on the market in this tech space and I am happy to tell that to any technologists that care to listen. Those of you at GitLab that know me also know how highly I speak of the product and the company. But I do not think this change should have been implemented without a lot more careful consideration and consensus gathering.
In the future, I hope you will give more consideration to the blast radius of a change like this.In the very near future, I hope you change it back to the way it was before you made the change. Then you can give your customers the ability to rename the roles if they want to, but don't dictate to them how those roles should be renamed. If you cant give that ability then please revert the change and leave it like it was, at least until you have done a lot more vetting and prep on it.
It might look like a trend, but it's not. If you look carefully, the same guy brought this mud to Couch DB, harassing developers until they obeyed and then went to Redis with something like "Hey, CouchDB made a similar change, you have to catch up!" like it's none of his business. Please, don't get misled in the heat of the moment by people that simply push their own agenda and most probably don't even care about your product.
I think there is a big difference between SPECIFIC words (eg "Auschwitz", "Holocaust" ) that have a specific known negative context and GENERAL words (eg "master") that have many different meanings and even more different contexts. The SPECIFIC word is generally assumed to be derogatory in nature, where the more GENERAL word could derive its positivity or its negativity from its context. In that situation we should be careful to assume that all uses of the general word were intended to refer to the specific negative context which, if we are at all analytical and attempting to be fair about it, we would need to at least allow for the possibility that the user of the word did not have intentions of conveying the negative context. If we are claiming to be tolerant and inclusive, then shouldn't we also refrain from judging other peoples intentions and assuming that all uses of the general word are as of now and will always be in the future, intrinsically evil in nature? How can we claim to be socially responsible and tolerant and inclusive by essentially becoming intolerant of certain words based on our (biased?) judgement of what the person really meant when they used it? I agree we should be socially responsible and not use words that have specific negative contexts, but do we really think that we can purge all of our society, our technology, everything of all words that have general meanings and multiple contexts (ie "master: meaning highly skilled") ? Would there ever be an end to that kind of effort? How could we possibly have stable technology if that was our goal? Specifically, how will GitLab ever have a stable and dependable product if they follow such a course?
regarding the person who originally authored this issue.... is that person a real GitLab user who is actively trying to engage with the community of Gitlab users? or just someone who as @kapusha said, has a personal agenda? As I questioned in post above... was there a mass of Gitlab community users/customers that raised this issue? Or was it one person who happened to show up here, doesn't use the product, but came by to tell this community and GitLab that the product and the community has a defect that should in his opinion be corrected? Does the issue author have a work history in the industry where they have engaged with development teams and actually really built software products and had to get along with the people they work with? Is the issue author a thought leader in the industry?... meaning is anyone following them? Do they speak at conferences or write books or anything that can verify that they have become in influencer in our industry? Or is their showing up here their effort to build such a personal brand? Try to Google the author and see what you find. I don't mean to demean or diminish the author's opinion, he is entitled to have it, but is GitLab and this community obligated to follow his opinion? If you follow the opinion of the one person who isn't part of the community and in so doing, you force the real rest of the community to adopt his change, are you not then "disenfranchising" all of your customers who are actually the people that buy the product and keep the lights turned on at Gitlab? OR, another possibility, did GitLab have the agenda to start with and this guy just came along and provided them the opportunity to escalate the agenda at this time?
I am a GitLab user and a Gitlab customer. I love using the product and I have a high degree of respect and admiration for the company and all the people at GitLab that I have had the pleasure of dealing with over the last few years. In my personal and my employed use of the Gitlab product, I depend on YOU, the GitLab company, to always be advancing the technical abilities of the GitLab platform.... but I also need YOU to provide stability in that platform. Until this change, I have never been unhappy with GitLab. I have enjoyed an exemplorary experience with the product and the people in the company. I will always be available to to share my positive story with any one considering to use/purchase Gitlab. I need YOU Gitlab to be there for me as well and you can do that by reverting this change and properly vetting changes in the future so that I/we your users have a stable and dependable platform.
... and rename the all Masters Degree programs for all universities everywhere all around the world.... and anyone who has a Masters Degree should be given a new diploma and all the resumes all over the world that have Masters Degrees have to be changed to Maintainer Degrees ... also definitely rename the Masters Golf Tournament... and rename anything anywhere in the world that uses the word "master"......blah blah blah.
A few people have made a decision that they want to force the rest of us to believe what they believe and speak like they do ... that the rest of us cant use a certain word because they believe it can only have one meaning. Geez! I guess they want us to be their thought-slaves... if we dont believe like them then they will silence us and change the names of things that we use. The whole is issue a mess.
I still love the GitLab product, but IMO this change is a mistake and you should not have made it without considering the opinions of a lot more people..... uh... and maybe include some of your customers too. I think GitLab owes their community an apology and they should admit the mistake and fix it.
Sorry for the rant, but the way that this issue was very poorly vetted and then forced on me .... I just dont agree that GitLab handled it properly. I dont like the decision or the outcome.... and I dont like the precedent that it sets for the future.
So GitLab - I still love your product. But I have lost some confidence in you.