Re: Proposal: Replace all references to master/slave in GNOME modules

[Daniel Playfair Cal <daniel playfair cal gmail com>]

On "master" as a branch name: Words have multiple meanings and in this case master is meant as a passive reference copy rather than as an active controlling agent (with slaves). However, it is not a coincidence and not irrelevant that the same word carries both meanings. If there are people who are discouraged by the name, then it may be a net positive in terms of fixing bugs or achieving other aims that depend on developer time if less developers are discouraged by arbitrary things like branch names. Besides removing the unwanted connotations, "mainline", "trunk", or "devel" IMO are more descriptive terms for the main development branch than "master". As far as I can tell, it seems like there is value in changing the name, and no detriments other than the cost of doing it.

There's documentation of what needed to be done for Geary in the issue thread - it looks pretty simple to me. Although inconsistency is bad, a test/pilot is also good, because now we have a clearer idea of what would need to be done for a wider change. Is there anything difficult about changing the branch name?

Re the more general issue of socially charged terminology, perhaps a good way forward would be to build a manual/policy about which commonly used terminology is potentially offensive/exclusionary and provide better alternatives. Some like "master/slave" -> "leader/follower" or "blacklist/whitelist" -> "blocklist/allowlist" have good existing solutions, others might need more thought.

On Thu, Apr 25, 2019 at 7:01 PM Bastien Nocera <hadess hadess net> wrote:

On Thu, 2019-04-25 at 11:46 +1000, Michael Gratton wrote:
> Hi all,
>
> I'd like to formally propose as a GNOME Goal that GNOME modules
> replace
> references to the terms "master" and "slave". This is a worthwhile
> thing to do for social inclusiveness[0]. Many FOSS and non-FOSS
> projects, including Django[1], Python[2], and Rust[3] and the
> ISC[4])
> have already implemented similar programmes and it would be good for
> GNOME to do so also. The scope would be to replace occurrences of
> the
> terms appearing in the user interface, web sites, documentation,
> APIs
> (except as deprecated symbols), and git repositories - essentially
> wherever a person using or developing software for GNOME may
> reasonably
> encounter them.
>
> By way of background, I recently did just this for Geary[5] after a
> request via private communication. The work was essentially trivial,
> and it has been a relatively painless transition. A number of people
> have positively commented on the change, and no one has objected to
> the
> UI or API changes, however some feedback has been received about
> renaming the mainline branch, broadly falling into essentially three
> categories: 1) It doesn't matter, 2) it's inconvenient, and 3) it
> should be done project-wide, not piecemeal.
>
> To respond to that feedback, which I imagine will also be raised for
> this proposal, I'd suggest that (1) is clearly not the case - yes it
> doesn't matter to many people, but it does matter to some, and
> that's
> the whole point of making a project more socially inclusive - to
> make
> it better for everyone. The issue raised by (2) is not a new problem
> -
> we already have to remember project names, branch names, file names,
> symbol names, and so on. To make that easier we have tooling support
> (auto-completion in both GUIs and TUIs, the ability to set things as
> defaults, code symbol lookup, etc.). Further, disruption can be
> minimised by carefully choosing replacement names. I deliberately
> chose
> "mainline" for Geary's mainline branch name because it has the same
> auto-complete prefix as "master", for example. Want to check out the
> mainline branch? Just type "git co m<TAB>", just like you always
> have.
> Lastly, if adopted project-wide, then we'd all get used to the new
> names rather quicky. Finally, to respond to (3) I am proposing it
> project-wide now.
>
> To summarise, let's replace the use of these deprecated terms in our
> project as a step towards making GNOME a project that everyone wants
> to
> use and develop for. Who's in?

This email was really difficult to read because of the layout of the
proposal, and how the response to feedback was formatted. I had to scan
it 3 times to find what you wanted to rename the main git branches.

+1 on the sysadmins doing the git changes project-wide
+1 on tracking master/slave usage project-wide and removing it

What your proposal doesn't touch on is what to do when the master/slave
usage is out of our control, and legacy, especially when it comes to
hardware.

I feel that it would be better to not touch those, and come up with a
statement that could be used in documentation to explain their usage.

Cheers

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list