RFC: Conscious language in the Binutils

Joel Sherrill joel.sherrill@gmail.com
Fri Nov 6 15:29:33 GMT 2020


On Fri, Nov 6, 2020 at 8:57 AM Ramana Radhakrishnan via Binutils <
binutils@sourceware.org> wrote:

> On Thu, Nov 5, 2020 at 11:53 AM Nick Clifton via Binutils
> <binutils@sourceware.org> wrote:
> >
> > Hi Guys,
> >
> >   [I am writing this email with my Red Hat on, rather than my FSF hat].
> >
> >   Inside Red Hat there is an initiative to address some of the language
> >   used in open source projects, making it more inclusive:
> >
> >
> https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language
> >
> >   This includes addressing terms used in source code, as well as
> >   documentation and so on.  I would like to offer to make such changes
> >   to the binutils sources.  (See for example the attached patch which
> >   addresses uses of blacklist/whitelist and master/slave).  These
> >   changes would only cover source code maintained by the GNU Binutils
> >   project itself.  Imported sources, eg libiberty, config and zlib,
> >   would not be changed unless these changes happen upstream first.
> >
> >   Before making any alterations however I wanted to see if there were
> >   any comments, concerns or issues regarding this proposal.  Does anyone
> >   have anything that they wish to say ?
> >
>
>
>
> FWIW even though the patch has been dropped, I support this proposal.
>


If the choice of words can bring more technical clarity to the code, then
it can stand on technical merit without even discussing the social nature
of the change. Some of the proposed changes met this criterion IMO
but some of the variable name changes seemed to lose clarity to me.

If this is the beginning of a discussion on lowering the barrier to
contributing to binutils, that would be a good thing. But I suspect
there are other challenges to making the on-ramp less steep.
You'd have to already be pretty involved in binutils to find these
words in the code while doing technical work. How can we make it
easier for someone new to get involved and find those?

Lost in the focus on word choice is the broader question of making
a project inviting, welcoming, and fair at a human level as well as
technically approachable.

Picking on one broad technical point that impacts approachability.
Binutils is the implementation of a LOT of arcane things documented
in dozens, if not hundreds of documents, that are not collected in
a central place AFAIK or always easily accessible. Object formats,
debug formats, the ld language, section naming rules, assembly
languages, CPU model variations, etc, etc.

Binutils is really amazing in the variety of what it supports and the
knowledge that embodies. But that breadth also means that somehow
there has to be an organized way to pass on that information to new
developers.

I'm not opposed to the change if the change improves clarity.
Free software is written once and read many times.

--joel


>
> regards
> Ramana
>
> > Cheers
> >   Nick
> >
>


More information about the Binutils mailing list