Topics

Inclusive Language summary from the OE TSC


Richard Purdie
 

The OE TSC recognises there are issues related to inclusive language
which the project needs to address and that we need a plan for doing so
moving forward. It is unclear how much change the project members wish
to see or can cope with at this point in time, nor how much help is
available to make changes. It is noted that whilst steps were proposed
in the email thread discussion, those have as yet not been acted upon.

There are some steps the TSC believes the project can take:

a) Going forward all new code and new variables should use inclusive
language. We will rely on the usual peer review process of changes to
help catch issues and request the communities help in doing so but this
becomes standard policy with immediate effect.

b) We defer any potential "master" branch name change until upstream
git's direction becomes clearer. This is one of the most invasive
potential changes and if we do change it, we need to get it right and
make a decision based upon tooling support and general wider community
consensus.

c) We start looking at the function names and patch filenames for
problematic language and accept patches to change those straight away.
This area is much less invasive and lower risk.

d) We create a list of the potentially problematic variable names on
the wiki so we can understand scope and what kinds of work is needed to
form a better plan, including understanding the potential migration
paths for changes.

e) We decide not to port any of these changes to the current LTS and
focus on these changes for the next project releases and future LTS due
to limited resources and for current LTS stability.

f) We aim to ensure the OE and YP TSCs are aligned on our approach to
address this and changes in OE and YP match

This is intended as an initial response/path forward and may need to
adapt over time as circumstances dictate. It gives us a place to start
from and move forward.

Richard on behalf of:

OpenEmbedded TSC

This was also discussed and agreed by:

Yocto Project TSC
OpenEmbedded Board


akuster
 

On 7/27/20 6:09 AM, Richard Purdie wrote:
The OE TSC recognises there are issues related to inclusive language
which the project needs to address and that we need a plan for doing so
moving forward. It is unclear how much change the project members wish
to see or can cope with at this point in time, nor how much help is
available to make changes. It is noted that whilst steps were proposed
in the email thread discussion, those have as yet not been acted upon.

There are some steps the TSC believes the project can take:

a) Going forward all new code and new variables should use inclusive
language. We will rely on the usual peer review process of changes to
help catch issues and request the communities help in doing so but this
becomes standard policy with immediate effect.

b) We defer any potential "master" branch name change until upstream
git's direction becomes clearer. This is one of the most invasive
potential changes and if we do change it, we need to get it right and
make a decision based upon tooling support and general wider community
consensus.

c) We start looking at the function names and patch filenames for
problematic language and accept patches to change those straight away.
This area is much less invasive and lower risk.

d) We create a list of the potentially problematic variable names on
the wiki so we can understand scope and what kinds of work is needed to
form a better plan, including understanding the potential migration
paths for changes.
Where do we stand on a plan? I noticed a patch already got applied to
change names. The name change in that patch, is that "wording" change we
should adopt?

-armin

e) We decide not to port any of these changes to the current LTS and
focus on these changes for the next project releases and future LTS due
to limited resources and for current LTS stability.

f) We aim to ensure the OE and YP TSCs are aligned on our approach to
address this and changes in OE and YP match

This is intended as an initial response/path forward and may need to
adapt over time as circumstances dictate. It gives us a place to start
from and move forward.

Richard on behalf of:

OpenEmbedded TSC

This was also discussed and agreed by:

Yocto Project TSC
OpenEmbedded Board







Richard Purdie
 

On Wed, 2020-09-16 at 14:13 -0700, akuster808 wrote:

On 7/27/20 6:09 AM, Richard Purdie wrote:
The OE TSC recognises there are issues related to inclusive
language
which the project needs to address and that we need a plan for
doing so
moving forward. It is unclear how much change the project members
wish
to see or can cope with at this point in time, nor how much help is
available to make changes. It is noted that whilst steps were
proposed
in the email thread discussion, those have as yet not been acted
upon.

There are some steps the TSC believes the project can take:

a) Going forward all new code and new variables should use
inclusive
language. We will rely on the usual peer review process of changes
to
help catch issues and request the communities help in doing so but
this
becomes standard policy with immediate effect.

b) We defer any potential "master" branch name change until
upstream
git's direction becomes clearer. This is one of the most invasive
potential changes and if we do change it, we need to get it right
and
make a decision based upon tooling support and general wider
community
consensus.

c) We start looking at the function names and patch filenames for
problematic language and accept patches to change those straight
away.
This area is much less invasive and lower risk.

d) We create a list of the potentially problematic variable names
on
the wiki so we can understand scope and what kinds of work is
needed to
form a better plan, including understanding the potential migration
paths for changes.
Where do we stand on a plan? I noticed a patch already got applied to
change names. The name change in that patch, is that "wording" change
we should adopt?
Was there a patch applied?

Cheers,

Richard