Replace oppressive terminology with more accurate alternatives

[mossheim]

https://github.com/brianlheim/rfcs/blob/topic/replace-oppressive-terminology/rfcs/0010-replace-oppressive-terminology.md

[Spacechild1]

Replace the oppressive terms “master-slave” with more accurate alternatives.

I don't get it... "master" is not an oppressive term in itself. The metaphor "master/slave" might be seen as problematic by some people (especially in the US), but we don't use the word "slave" in the context of git anywhere... I always thought of the master branch as the master copy, like a "vinyl master".

To be honest, renaming the master branch feels like virtue signalling to me. I'm all for creating inclusive environments, but this is a bit ridiculous. I don't want to start a flame war, just giving my honest opinion :-).

If you decide to go with this, please keep master as an alias, so you don't break existing scripts.

Replace the oppressive terms “blacklist-whitelist” with more accurate alternatives.

Agreed.

Use the neuter “they” as the singular pronoun and

Agreed.

Reflect on our use of metaphors generally.

Agreed.

[patrickdupuis]

This post from the GNOME dev mailing list from 2019 offers an explanation of the origin of gits master` branch: https://mail.gnome.org/archives/desktop-devel-list/2019-May/msg00066.html

It appears that git inherited master from Bitkeeper which names repositories (not branches) master and slave.

[Spacechild1]

I know. But is this really how the term "master" is actually perceived in the context of git? I certainly didn't know it came from master/slave, I just found out today, and so did most people I dare say. Again, git doesn't use the word "slave" anywhere.

[jamshark70]

Tbh, when I was working on my DDW___Clock classes, it did cross my mind, "Why do we call them master and slave? Is that really good?" But I ignored that moment of unease and went with it because it's standard terminology.

So, movements to change standard terminology do make a difference, and I'll go change my quark at some point.

On the question of the master branch -- apart from breaking scripts, it hurts no one to call it "main" or even "stable," whether or not there's a current explicit reference to slavery. I do see Christof's point -- I had never thought of other git branches as slaves -- but I don't see a compelling reason to keep the current term.

I'm not crazy about bandwagoning, but in this case, I did have misgivings about the words in my own work, so I appreciate the nudge.

Edit: Of gender-neutral pronouns, I quite often like to use "she" especially for fields that are traditionally male dominated. It can give male chauvinists an extra moment of cognitive dissonance that they might not feel with "they" and "them."

[clfest]

This is extremely silly, and has a touch of Newspeak in it. The meaning of a word is context driven. You don't get rid of 'bad thoughts' by banning words that are in some way associated with them.

[joshpar]

I support this change. The underlying context of our language on a daily basis informs our and our community's world view. If we make an effort to direct our language towards an inclusive example, that helps move society as a whole in that direction over time.
@clfest - Newspeak is saying one thing, and meaning another. If the purpose was to change to Main but still with the intention of keeping a master / slave relationship, I would agree there is a problem. I think this is a move away from that.

[eleses]

Frankly "master" for a/the git branch is probably inappropriate even on a purely technical level as there's no real sense in which the other branches are "slaves". They're all just refs as far as I understand git... (which is not incredibly well, I admit.)

As for the other uses in SC tree... I'm surprised they are that many in (just in c/cpp/h/hpp/sc/schelp):

Search "master" (126 hits in 35 files)

A bunch of those come from boost and portaudio actually... (The latter uses "master volume" a lot, and so does the wasapi.) But then so does Server.schelp.

Since the IETF draft doesn't seem to discuss what's the best replacement for "master volume" (only "master" in some other contexts), does anyone know what proposed terminology alternatives are in the music/sound world? So that if we replace "master volume" with something less oppressive it would not be a term completely unique to SC...

N.B. the IETF draft proposes these alternatives to "master-slave":

o Primary-secondary
o Leader-follower
o Active-standby
o Primary-replica
o Writer-reader
o Coordinator-worker
o Parent-helper

I guess "primary volume" would be most suitable in a sound context... Opinions?

Surprisingly, I only got one hit for "slave" in my search; that's in SyncSaw.schelp.

It looks like we don't have to do any changes for "blacklist" as there are no occurrences in SC proper (well, there's one in portaudio's source) and likewise for "whitelist".

Also, as far the order of changes goes, I'd suggest starting with the help files as probably the most visible to SC users. The (SC) code internals can be done on a lower priory "pass".

[lnihlen]

While some may not be bothered by master/slave references it's their privilege to not be bothered by that. It costs the dev team literally nothing to adjust our language to be more inclusive. Huge supporter of these practices, and will adjust Scintillator and Hadron structure to suit.

[jamshark70]

The latter uses "master volume" a lot, and so does the wasapi.

Another way to look at it is that the objectionable concept is that of a slave. "Master" as a word has multiple connotations, some of which imply subjugation of human beings (or autonomous agents), others of which do not.

A year or two ago, I was working on networked clock classes, and I did call one the "master clock" and the other, the "slave." That's a direct reference to the idea of one agent subjugating another, and I did have an icky feeling about that (though I didn't act on it at the time -- now I find myself glad that someone is pushing for a change).

To me, a master volume or master channel is quite different. Nothing is enslaved; the source channels have their own automation and effects processing, and they continue working individually. (Yes, it's true that if you turn the master/global volume all the way down, then you hear nothing, but all of the sources are still processing as if the volume were up.)

The intention behind changing the terminology is good. It's also possible to dilute the good effect by misapplying the sensitivity where it may not make sense (such as the incident a few years ago, where a US Representative was called out for using a word that only sounds like an objectionable slur but whose meaning and etymology have exactly nothing to do with the Latin root for "black" -- the objection was well-meaning but misplaced).

[eleses]

@jamshark70 Well, if master by itself is not objectionable, then there isn't much work to do. "slave" only appears in one SC file...

But my understanding of the gnome discussion (linked in a prior comment in this thread) is that "master" in itself is objectionable, even with no mention of "slave".

See also, github as a whole making this change https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/ And discussion in the git developer community itself https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/ (linked from that piece of news)

Interesting technical discussion from there, regarding git proper:

From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 14 Jun 2020 14:06:18 -0700

Konstantin Ryabitsev <konstantin@linuxfoundation.org> writes:

> - having a branch named "master" is already not required, so any 
>   existing software that expects there to always be a "master" branch is 
>   already broken and wouldn't get any more broken by the move away 
>   towards more descriptive terminology

The above is mostly true but not entirely, I have to remind you.

There certainly is the concept of the primary branch in each
repository.  With the current version of Git, it is hardcoded to be
the 'master' branch, and we are going to make it configurable with a
configuration variable [*1*].  There are a few examples that the
primary branch is treated specially:

 - When merging into the primary branch, the auto-generated merge
   message is different from a merge into any other branches.  This
   was because most of the merges, especially in early days of Git,
   were into the primary branch (there weren't many cross-branch
   merges made) and we did not want to see repeated "Merge X into
   'master'", "Merge Y into 'master'", etc.---we just say "Merge X",
   "Merge Y", etc. when merging into the primary branch.

 - "gitk" gives preferencial treatment to 'master' when there are
   too many references it has to choose which ones to make visible.

 - "git fast-export --anonymize" redacts the name of all the
   branches, but the name of the 'master' branch is left intact in
   its anonymized output (which is done in order to make the primary
   line of work identifiable even in the redacted output stream).

There may be others.  Software that assumes that 'master' is special
is *not* broken as you stated (we will break them when we allow
changing the default---that is the cost those of us who are working
on the transition plan thought worth paying).  The concept of "there
is one thing that is special among others" can serve useful purpose.

It of course opens a different can of worms ;-) Even though we can
please master-slave-haters by moving away from the particular word
'master', those who cannot stand the very idea of one thing being
special among others will not be satisfied (and we shouldn't even
try to please them, IMO).



[Footnote]

*1* There is a related but separate concept of the "default name"
for the primary branch in newly created repositories, which also is
hardcoded to be 'master'.  We are going to make it configurable,
too.  This controls the name used by "git init" (possibly we will
also add a command line override "git init -b name" to countermand
the configured default) and "git clone" (which tries to use the
name of the branch pointed at by HEAD of the other side but has to
fall back to something when it cannot figure it out).

[muellmusik]

Do it. The point of inclusive practice is not just about whether something offends us as individuals, but whether it might offend others.

Yes master has multiple meanings, but as has been pointed out for years, its use in sound work is often pretty weird metaphorically, and possibly sexist. (Master tape? Surely it should be mother tape?) Good metaphors also aid understanding.

[jamshark70]

... as has been pointed out for years, its use in sound work is often pretty weird metaphorically, and possibly sexist.

That sounds compelling to me. Though I'll note that this discussion appears at the same time that Peter Kirn writes about the topic in CDM and says essentially the same as I did (which I hadn't noticed on first skimming) -- "The term master on its own you don’t have to worry about. It’s associated with mastery, master classes, master copies, master bedrooms, the antiquated practice of calling young men “masters,” Masters’ degrees, uh… MasterCard. Not one of those terms originated in the practice of slavery. (I checked.)" https://cdm.link/2020/06/lets-dump-master-slave-terms/

Yes to evaluating metaphors on their merits (in particular, thumbs up to "mother tape" but I don't expect specialists to start rebranding themselves as "mothering engineers" anytime soon). "On their merits" may end up concluding that a specific use of a specific word has nothing to do with an objectionable origin, however. ("Master" is admittedly troublesome as the oldest meanings of the word do connote one person with power over another, though. It may not be possible to recuperate that word in every case.)

[eleses]

And I think the notion of "master volume" has lot more to do with a notion of slave (amplifier), than the "master" git branch ever had to do with any notion of slave...

Windows get around this issue by calling it "device volume" https://superuser.com/questions/1202337/how-can-i-sync-all-sources-in-windows-volume-mixer

But in SC that's not quite correct. So maybe just "server volume"?

[muellmusik]

Andra McCartney was writing on this stuff from a feminist perspective already decades ago.

https://muse.jhu.edu/article/585329/summary

[Spacechild1]

@jamshark70 thanks for your nuanced comments! This is the discussion I was hoping for (instead of people just silently downvoting other's comments cough).

For everyone: I'm not against renaming master to main, I just don't see the point. For me, this is just creating unnecessary friction for no apparant gain. But if you decide to do so, please keep it as an alias, so you don't break existing scripts.

On a side note, GitHub advertizing this change feels more like a PR stunt. If they want to do something meaningful, they should officially stop cooperating with ICE... Just my two cents.

[Spacechild1]

N.B. the IETF draft proposes these alternatives to "master-slave":

...
o Leader-follower
...

Now this is funny. As an Austrian I find this metaphor troubling because of our own history. This just shows how much the whole discussion depends on the cultural context. I just think that proposing/imposing a change in language is a very radical act that needs to be considered carefully.

[miguel-negrao]

I agree with the general intention of this RFC. In general I agree that language always evolves and we can change it if we think that is warranted.

I agree with avoiding use of master/slave, that has such a specific meaning, there is no way to avoid the original meaning.

In the case of parts of words which don't have a specific oppressive meaning, but only gain that meaning depending on the context and history of use of the term (such as terms with black or white), I think it would be prudent to investigate the etymology of the word, and also consider if it has been used with an oppressive meaning.

Regarding whitelist and blacklist, I found this article/commentary which suggests that it has a racist origin, so If that is the case I would agree with avoiding it.

Nevertheless it would make language poorer if no words including black and white could be used when also having a specific positive or negative association. For instance, from a quick googling, "whitewash" which has a negative association might come from painting a wall white (which is a common color), therefore rendering invisible the imperfections and cracks that existed before. We should just make sure the words do indeed have a racist connotation, which is not the case of all words containing black and white which have a positive or negative connotation.

Regarding the use of singular they pronoun, had a a quick look at what that is, and to a non-native english speaker it feels extremely confusing. I don't have an issue with people using it here, but I don't think it should be expected that non-native english speakers should be capable of using it. We have something similar in Romance languages for formal treatment (third person singular or second person plural) and non-native speakers really struggle with that.

[eleses]

Regarding pronouns: most of the SC documentation I've looked at is written in 2nd person "you can..., you should..." etc. And the things being referred to in 3rd person are inanimate, so "it", "its" etc. Thus, I don't see a concerted effort being needed on that pronouns angle, but of course any slip-ups should be corrected when found.

(If SC had documentation e.g. in French or some other language with gendered nouns, it would be potentially more work in regard.)

[telephon]

Btw. the term "master" in the context of a repository may well come from production, in particular printing, like of vinyl and CD, where you have a master from which the copies are made. The German word is beautiful: "Druckvorlage". I like this shift of semantics, because we can think of a "master clock" in the same way. That means, good replacements for master are synonyms in that sense: model, prototype, source.

Now that the whole issue is about a pair of terms, the replacement needs to be paired as well. I'm not a native speaker, so I may miss out a good solution. One reasonable possibilty is source vs. sink, another one sender and receiver.

I personally always found that "server - client" has a pretty bad taste, but others may not be similarly inclined?

(As we are at it, and try to become more politically aware, we may also move our repository to gitlab, as to avoid the master silo we are entering ... But this is another issue altogether)

[cianoc]

Blacklist and whitelist aren't racist. Their use comes from England and their origins are in middle English.

I agree with James that replacing the use of 'he'/'his' with 'she'/'hers' etc is a good idea. It reads much better than 'they', is less confusing for non-native speakers and at least makes the documentation more inclusive.

I can see an argument for changing master to main for clarity. I think it makes it harder to understand the decentralized nature of git. As far as oppressive language goes... ¯_(ツ)_/¯

Serious question - what terminology would you use for a MIDI clock slave?

[Spacechild1]

Just to give some more perspectives, here's what some POC developers have to say:

https://news.ycombinator.com/item?id=23505713
https://news.ycombinator.com/item?id=23501861
http://antirez.com/news/122#comment-4084872912

It turns out that some find the GitHub initiative patronizing and insulting... Now what do you do? I just want to point out that things are not as clear cut as some people might believe.

[miguel-negrao]

Serious question - what terminology would you use for a MIDI clock slave?

Parent/child, Writer/reader ?

[muellmusik]

Serious question - what terminology would you use for a MIDI clock slave?

In Utopia there is a simple decentralised clock which uses Conductor/Follower (I think this was Alberto's suggestion). A conductor coordinates, but it's ultimately a collaborative arrangement! (Infamously dictatorial maestros notwithstanding.)

[Spacechild1]

I think parent/child is not too bad. It emphasizes the hierarchical structure of a tree of devices.

[cdbzb]

the MIDI clock must follow - its not collaborative and that's what the term 'slave' captures. I'd suggest the terms 'driving/driven' (from gears) for that one... so 'driving-clock' 'driven-clock'

[cdbzb]

'whitelist' and 'blacklist' are nice English words - it would be nice to replace them with similar words... what about redlist and greenlist like traffic lights?

[cdbzb]

master/copy could be source/clone perhaps

[cianoc]

Do black people complain about the usage of master/slave? I could give you a long list of local black complaints, and while there are symbolic fights (the confederate flag, removing confederate statues), language only comes up when it's used in a deliberately offensive way. For example there was a local politician who used to refer to black men as 'boy'.

[mossheim]

@telephon you made a suggestion yesterday without explaining why, for instance, you thought it would be an improvement, or whether it should augment or replace the existing text. please do that for future suggestions.

[madskjeldgaard]

I support this RFC. Good work @brianlheim !

[telephon]

@telephon you made a suggestion yesterday without explaining why, for instance, you thought it would be an improvement, or whether it should augment or replace the existing text. please do that for future suggestions.

ok, I see what you mean. I suppose this is true not just for me ;)

[brunoruviaro]

I just read the proposal in its entirety, and I wholeheartedly agree with the changes proposed there. Thank you.

[mossheim]

thanks again everyone for the thoughtful and respectful conversation.

i now feel ready to put this RFC into Final Comment Period. the date to merge or reject this RFC is July 12.

[eleses]

Can we have some decision on "master volume"? As I mentioned previously it's by far the most common use of the "master" term that I found in SC itself. (The other things are nice to have been decided in theory, but their practical impact in terms of changes required will be close to zero, except for the git/github branch name issue.)

[mossheim]

@eleses Please, read the RFC before commenting. I have already covered your question in the text:

• Replace terms using 'master' with 'main', for example 'master volume' to 'main volume'.

[eleses]

@brianlheim I missed the update, sorry.

[mossheim]

no worries! I do appreciate that you wanted to follow up on that. :)

[spluta]

I have read and I fully support these changes. Thank you for the opportunity given to discuss this as a community.

[davidgranstrom]

I agree with the RFC and support the proposed changes.

[patrickdupuis]

I also have read the RFC and the linked IETF document. I fully support this RFC and the proposed changes.

[adcxyz]

Hi,
What are the plans for smoothly moving all quarks from "master" to "main" branches?

Currently the Quark and Git classes have "master" hardcoded in 3 places,
and I am wondering how that migration can work:
older SC versions will keep trying to checkout "master" branches;
I assume newer ones will likely look for "main" branches?
If so, are there any smart git ways of aliasing main and master branches
to each other for a transition period?

[mossheim]

@adcxyz good question! i hadn't planned on making any changes to repositories in supercollider-quarks, to be frank because the thought just hadn't crossed my mind. that's my mistake, as RFC author the responsibility for not considering that lies with me. my interpretation is that under this RFC there would be no such migration; i was thinking here only of repositories within github.com/supercollider. but, i would certainly understand if other people feel that this interpretation doesn't match with what they agreed to!

i have updated this RFC to more clearly present my interpretation.

my current feeling is that, as this RFC is mergeable and has already reached a state of agreement, we should merge this, make the changes as detailed here in supercollider org repos, and leave the problem of supercollider-quarks to a future discussion.

i say this for the following reasons:

• changes in supercollider org repositories can be implemented independently of supercollider-quarks
• i suspect some people here also did not consider supercollider-quarks, since there are big technical and human questions to answer there and nobody else seems to have raised or considered them in this discussion, and so trying to decide this problem now, after people have already had their say, risks exhausting discussion participants and even appearing to change the scope while people aren't paying attention
• this brings an entirely new set of technical complications that i am not prepared to address, and i do not want to hold up these more easily achieved changes with that discussion
• supercollider-quarks are fundamentally 3rd-party code, which brings an extra dimension to this problem that i am also not prepared to address

i would like to hear from a few other people. to clarify, my proposal is that we merge this, begin to make changes in the supercollider org only, and at the same time launch a discussion about whether a new RFC is needed to make changes to supercollider-quarks. if people disagree with this, can you please indicate what you think should happen to this RFC instead?

please do not merge this RFC, in the meanwhile.

[mossheim]

to be extra clear, as i see it the options here are:

1. consider this RFC to not address the question regarding supercollider-quarks, and merge it.
2. withdraw this RFC and submit a new one that addresses that question, so that we can attempt to reach a consensus on implications for both supercollider and supercollider-quarks at once.

i will not be emending this RFC to try to address this question, and i will not be seeking a new round of consensus/input on this RFC. it is too late in the process for me to feel comfortable doing that.

[Spacechild1]

I don't want to start a new discussion, but

Currently the Quark and Git classes have "master" hardcoded in 3 places,

My question is: why is "master" hardcoded in the first place? I think Brian's answer regarding the fear of breaking scripts also applies here:

many tools and scripts that interact with GitHub repositories simply use the 'default' branch of the repository and do not specify a branch. this change would be transparent to them. in some ways, this could even be considered good practice.

So why not simply pull the default branch?

[jamshark70]

So why not simply pull the default branch?

That seems entirely reasonable. Individual quark authors would be able to set the branch name on their own. (Unless there's some technical reason why that wouldn't work?)

[mossheim]

hey @jamshark70 @Spacechild1 -- i would really really prefer to just focus on the single question at hand, it's urgent for the future of this RFC and supersedes any other conversation related to it. also, FYI this has been discussed before here (and it appears i'm the reason why this is the case!).

[jamshark70]

Alberto raises the valid point that we can't purge all occurrences of "master" from the SC repository without altering the behavior of quarks. Specifically, if a quark's default branch is not master but the author intends "master" to be the stable branch that users generally install, the choices are: a/ incompletely implement this RFC and keep backward compatibility in this case by keeping "master" in the quarks code; b/ change it and require quark authors using this configuration to update.

It doesn't affect me as I'm not separating development and stable branches in my quarks, and I'm not opposed to either a/ or b/. But I think Alberto is correct that it isn't possible to avoid all decision about this. The decision may well be a/, and I think that would be legitimate and not deeply offensive, and allow significant movement forward. It's worth making that an explicit decision (and commitment to come back to the quarks question later).

[patrickdupuis]

I think what @brianlheim is proposing in this RFC only applies to repositories under the supercollider organization. supercollider-quarks is a separate organization not in scope of this RFC.

It would be best if we can keep the discussion about Quarks for another time.

[mossheim]

alright! since this RFC has broad support in the form where it at least applies to the repositories in the SuperCollider org, and since we've already reached the end of the final comment period, i'll consider it passed with the caveat that more discussion/planning is needed before touching anything in supercollider-quarks. that already gives us quite a bit to implement, and i think is really the core of what this RFC was about to begin with. there are several important ongoing discussions right now on other parts of the project that i'd like to participate in, and we also have a release immanent, and my first RFC still hasn't been fully implemented yet!, so i would like to let those things settle before implementing this.

thank you again to everyone for the engaging and respectful discussion, this has made me very happy to be a part of this project!

[muellmusik]

Thank you @brianlheim for taking this initiative!