[oe] [OE-core] Inclusive Language Proposal for YP/OE


Alexander Kanavin
 

On Fri, 4 Feb 2022 at 14:21, Enrico Scholz via lists.openembedded.org <enrico.scholz=sigma-chemnitz.de@...> wrote:
"Jon Mason" <jdmason@...> writes:

> For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
> become "HALT, NO_NEW_TASKS and "WARN".

I am not an native english speaker, but for "HALT" I will have to think
twice whether it will pause the operation or abort it.  I would stay at
"ABORT" because it makes much more clear what happens.

I'm not taking a stand here, but just providing the context for where the push for avoidance of 'abort' comes from:

Keep in mind that for non-native english speakers none of these words are emotionally charged; they're just terms. Not so for native speakers.
 
> BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
> BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
> BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
> MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED

The new variable names sound like boolean flags, not like lists.

I'd say the context should make it clear that they are lists (e.g. either the initialization, or usage via iteration).

Alex


Enrico Scholz
 

Alexander Kanavin <alex.kanavin@...> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN" would
become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to
think twice whether it will pause the operation or abort it. I would
stay at "ABORT" because it makes much more clear what happens.
I'm not taking a stand here, but just providing the context for where
the push for avoidance of 'abort' comes from:
https://inclusivenaming.org/word-lists/tier-1/

Keep in mind that for non-native english speakers none of these words
are emotionally charged; they're just terms.
Yes; these are terms. But it should be possible to understand the
meaning of these terms without using a special "inclusivenaming"
dictionary. Else, we could just use "A", "B" and "C" for the actions
above and explain these "terms" in some documentation later.


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.
I'd say the context should make it clear that they are lists
It is bad when a context is required to understand the meaning of a
variable.

And where do you see a context when local.conf contains

| BB_HASHCONFIG_IGNORE_VARS = "true"



Enrico


Bryan Evenson
 

Enrico,

-----Original Message-----
From: openembedded-core@... <openembedded-
core@...> On Behalf Of Enrico Scholz via
lists.openembedded.org
Sent: Friday, February 4, 2022 9:16 AM
To: Alexander Kanavin <alex.kanavin@...>
Cc: Jon Mason <jdmason@...>; Yocto-mailing-list
<yocto@...>; Patches and discussions about the oe-core
layer <openembedded-core@...>; OpenEmbedded
Devel List <openembedded-devel@...>
Subject: Re: [oe] [OE-core] Inclusive Language Proposal for YP/OE

Alexander Kanavin <alex.kanavin@...> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN"
would
become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to
think twice whether it will pause the operation or abort it. I would
stay at "ABORT" because it makes much more clear what happens.
I'm not taking a stand here, but just providing the context for where
the push for avoidance of 'abort' comes from:
https://inclusivenaming.org/word-lists/tier-1/

Keep in mind that for non-native english speakers none of these words
are emotionally charged; they're just terms.
Yes; these are terms. But it should be possible to understand the meaning of
these terms without using a special "inclusivenaming"
dictionary. Else, we could just use "A", "B" and "C" for the actions above and
explain these "terms" in some documentation later.
Would CANCEL be clearer to you than HALT?


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST ->
BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.
I'd say the context should make it clear that they are lists
It is bad when a context is required to understand the meaning of a variable.

And where do you see a context when local.conf contains

| BB_HASHCONFIG_IGNORE_VARS = "true"
Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more sense to you?

Bryan



Enrico


Enrico Scholz
 

Bryan Evenson <bevenson@...> writes:

For BB_DISKMON_DIRS, the actions "ABORT, STOPTASKS and WARN"
would become "HALT, NO_NEW_TASKS and "WARN".
I am not an native english speaker, but for "HALT" I will have to
think twice whether it will pause the operation or abort it. I would
stay at "ABORT" because it makes much more clear what happens.
Would CANCEL be clearer to you than HALT?
mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.

I do not know how this can be described without using "abort" or some
extensively long terms.


BB_HASHCONFIG_WHITELIST -> BB_HASHCONFIG_IGNORE_VARS
BB_SETSCENE_ENFORCE_WHITELIST -> BB_SETSCENE_ENFORCE_IGNORE_TASKS
BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS
MULTI_PROVIDER_WHITELIST -> BB_MULTI_PROVIDER_ALLOWED
The new variable names sound like boolean flags, not like lists.
Would BB_HASHCONFIG_IGNORELIST or BB_HASHCONFIG_ALLOWEDLIST make more
sense to you?
yes; it is much better. But should it be an "IGNORELIST" or an
"IGNORE*D*LIST"?



Enrico
[who is irritated how people and especially developer can waste their
(and other developers) time in trying to change something which was
completely fine before]


Alexander Kanavin
 

On Fri, 4 Feb 2022 at 19:39, Enrico Scholz <enrico.scholz@...> wrote:
> Would CANCEL be clearer to you than HALT?

mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.

Cancel is the same as abort: a request to immediately stop the operation (or not even start it) without reaching the originally requested outcome.

Halt implies the operation is not going to continue (Alan Turing was as English as it gets, just to remind you).

I don't think any of this is remotely confusing.

Alex


Enrico Scholz
 

Alexander Kanavin <alex.kanavin@...> writes:

Would CANCEL be clearer to you than HALT?
mmmh.... for me as a developer (and non-native english speaker), "cancel"
means some ordered ending of an operation.

But the condition above causes an emergency abort.
Cancel is the same as abort: a request to immediately stop the operation
(or not even start it) without reaching the originally requested
outcome.
https://english.stackexchange.com/questions/535153/what-is-the-difference-between-cancel-and-abort

| Cancel implies the action is rescinded before it implements...
|
| Abort is an emergency procedure to interrupt...


Halt implies the operation is not going to continue
Really?

https://translate.google.com/?sl=en&tl=de&text=halt&op=translate says

| a suspension of movement or activity, typically a temporary one.

Examples in

https://dictionary.cambridge.org/de/worterbuch/englisch/halt

sound like there is a chance to continue after the "halt" (show the
permit, resolve the pay dispute).


When we want to continue this inclusion BS, then "halt" seems to be
offending to some people because it can mean

| ... having a physical disability.



Enrico