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
