Re: Identifying and removing potentially divisive language

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Well... Your examples are contradicting: the "master/slave" relation used in electronics or psychology are re-using the slavery concepts too... This doesn't make it right :-)
That depends on the etymology and history, not an expert on this.
I think there's a mild root, but still this require some technical language explanation.
They can contradict only if they came from 2 separate roots, if this is true is means the there are multiple concepts involved not only one.
Now I'm not working in electronics or psychology, so I'm not going to try and change their wording.

Regarding changing it now rather than waiting: Daniel is mentioning two hints - git, or github. As our code is hosted in gitlab, I would add that one too :)
The idea being that if they choose a new word, it will become the new default, and we could align with them for consistency, rather than arguing among us and picking a potentially different name
It makes sense, but more at Gitlab level, not a world global de-facto for me
This doesn't prevent us from changing words that are in our code (like blacklist/whitelist?). I think there's not a lot of them.

Regards,
Julien


Le jeu. 2 juil. 2020 à 16:09, Frediano Ziglio <fziglio@xxxxxxxxxx> a écrit :

> On Wed, Jul 01, 2020 at 04:15:07PM +0200, Victor Toso wrote:
> > Hi,
> >
> > On Wed, Jul 01, 2020 at 10:03:10AM +0200, Kevin Pouget wrote:
> > > Hello SPICE community,
> > >
> > > following Chris Wright (Red Hat CTO) blog post on "Making open
> > > source more inclusive by eradicating problematic language" [1],
> > > I would like to suggest that we have a look at SPICE source
> > > code to find out if/where such language is used and how to
> > > remove it.
> > >
> > > To illustrate the motivations of this move, consider the phrase
> > > "the final solution". I am quite sure you would agree that
> > > these words cannot be used inside a project. You would agree
> > > because the WWII events are still in minds and not so ancient
> > > yet.  Git "master", or the "master/slave" pattern may not
> > > trigger similar thoughts if your ancestors didn't suffer
> > > slavery; "whitelist/blacklist" neither, if the color of your
> > > skin doesn't get you into trouble (white=allow, black=deny).
> > > Overall, I would advise, when thinking about these questions,
> > > not to forget on which side your history/country/skin
> > > color/sexual orientation sits you. If it's the oppressor side,
> > > you're not at the right place to say it's not relevant.
> > >
> > > ---
> > >
> > > I had a quick `grep` look at SPICE code base, searching for
> > > `blacklist/whitelist/slave` and I could only find very few
> > > occurrences of these words, which is nice. Can you find other
> > > problem words?
> > >
> > > `master` is used for git default's branch, but not much
> > > elsewhere. Let's discuss if we could get rid of this one, for
> > > instance changing it to `main` (just a suggestion). I don't
> > > think that it can break that many things (only the CI comes to
> > > my mind, where the `master` branch may be treated differently)
> > > as git name default branch's name is often omitted in the usual
> > > workflows.
> > >
> > > Please share your thoughts about this
> >
> > Not a native english speaker but I've read a few discussions
> > around the user of master as git as in master copy instead of
> > master/slave. Another examples of the use of master from native
> > speakers included master as in school teacher or someone that is
> > in charge of something (the offense being where the subject of
> > control is the slave).
> >
> > Still, I don't really mind to changing it to main, even more if
> > there are people that feel this can really be offensive in some
> > way..
>
> I think the primary downside in changing the branch name is if we
> end up with different branch names chosen by each project. There is
> value in the fact that essentially every project uses the same
> branch name for their latest development branch, as it gives end
> users consistent expectations.
>
> I'm in favour of changing the branch name, but my inclination is
> to wait and see a little longer, in order to identify what the
> new defacto standard ends up being. "main" is a good bet as a new
> standard, but it would be nice to see it "in action".
>
> I'd be looking for two possible signs
>
> Whether the Git maintainers themselves decide to standardize
> on a new term.
>
> What GitHub actually decide upon & roll out.
>
> Either of those two decisions will set a defacto standard across a
> vast number of projects, and thus it will be beneficial to have
> alignment with those decisisons.
>
> Regards,
> Daniel

Hi,
   I have different feeling about these changes. On one side I agree with
Michal that these changes appears positive but they are potentially
aggravating the real issue just hiding the problem.
About the words I think "master" have multiple meaning, removing blindly
because some meaning could remember some bad memories looks excessive.
And even if this word is used in the "master&slave" reference hinting
human slavery there are on the other side many uses (like master&slave
relationship in electronic circuit or master&slave used in communication
or in psychology) were this is far from human slavery.
"blacklist" is very similar, it's used in a lot of places without negative
references, "black" is simply a color which, being usually associated
with no light is seen negative, not for race discrimination (like yin
and yang concept). I checked multiple dictionaries and hardly find
races references for "blacklist". For the same reasons we should remove
wording like "dark", "white", "yellow", "black".

About the "master" branch technically can be changed easily. I won't
wait a "de-facto" change, if all project would wait a "de-facto" change
the only name would be "master"! So if most of the group agree to change
and like "main" I would just rename to "main".

Regards,
  Frediano

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel



--

Julien ROPÉ

Senior Software Engineer - SPICE

jrope@xxxxxxxxxx



_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel

[Index of Archives]     [Linux Virtualization]     [Linux Virtualization]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]