Re: [PATCH v2] convert-variables: Script for Inclusive Language variable renames


Enrico Scholz
 

Richard Purdie <richard.purdie@...> writes:

This script searches for a list of variable that have been renamed
and converts them to their more descriptive names.
s/descriptive/politically correct/
We did try and make some of the names better describe what the variables
do and make the variables more consistent.

For example, a reference to HASHBASE was changed to BASEHASH which
better matches every other reference to that thing in the code.
When you really feel that this Yoda style naming must be fixed; then ok.
But for me, the gain would not be large enough to break the api.


The BB_ENV variables were also traditionally very confusing. Once you
know, you know but for new users they weren't great.
The new naming is much more confusing. While this kind of operation
(exclude or include something) was previously named by "whitelist" +
"blacklist" more or less consistently, it is scattered around across
multiple variants now.

Especially for the hash related lists, searching for "whitelist" or
"blacklist" in the sources revealed often the right way how to do
things.


Also see the discussion about the license variable issues. I'm very
consciously blocking the "simple" change as I want to see things
improve.

Variable names were perfectly readable. A change should make things
better, not worse.
See above, there are at least some changes which do. I'm sad you don't
agree.
ok; some changes are ok. E.g.

| "PNBLACKLIST":"SKIP_RECIPE",

because former name is misleading (it is not really a list/set but has
some specially addressing by varflags).


Why is the rename done at all? It makes the product just worse due to a
less usable api and because it causes a lot of work for the users of the
api (I shudder when I think about updating my CI to work with new and
old branches).
For better or worse some of the terminology we have is offensive to
some people.
Is there any real-world evidence that this is really the case? Especially
the embedded sector is filled with blacklisted terms (i2c master/slave,
spi mosi/miso) so I do not think that somebody is really offended.

In the opposite, I feel offended when such changes are labeled as
(technical) improvements ("more descriptive names").


Obviously (and sadly) there will probably always be some element of
something which someone could be offended by but these issues have
come under a particular spotlight. People with far more experience of
this than us have produced guidelines on the key issues,
In my experience, such people have too much spare time and invented a
problem only to come up with a solution later.


We do have people wanting to try and improve things. Projects do
need to be open to and able to change. If we don't try and take this
input and help those people make such changes where appropriate,
we'll just alienate and frustrate more users even if those users
were not personally offended by the language, a kind of "rot" can
set in to our community. I do not want to see that
I see a much higher risk when significant changes are done due to
political reasons rather than technical ones.


I have advised caution all the way through this. Should the project
get this wrong, the potential for negative social media feedback
against the project is huge.
Does such negative social media feedback really exist resp. does it
exist in channels that are relevant to us?

Linux kernel has not "cleaned" its api either and just said that future
development should avoid certain terms. I can not remember any negative
feedback.

Just do the same here: avoid some terms in future development and when
there are really technical reasons to touch existing variables, then
rename them.


For me personally, there is also a huge risk should I "misstep" in
handling this. The potential to break things for users is also really
high, I realise that. I have done a lot of work to try and make sure
issues are at least clearly reported to users with some idea of how
to resolve them so the transition is less painful. I do have some
experience of making changes to the project and am trying my best to
use that to our benefit.
You are doing a great job, but the project evolved beautiful over the
last >15 years with the old identifier and I can not remember any
complaints about them.



Enrico

Join openembedded-core@lists.openembedded.org to automatically receive all group messages.