On Wed, Jul 15, 2020 at 12:03 PM Eil?s N? Fhlannag?in
<[email protected]> wrote:
>
> On Wed, Jul 15, 2020 at 6:31 AM Trevor Woerner <[email protected]> wrote:
> >
> > Hi,
> >
> > As most are aware, there are efforts in many open-source/free-software
> > communities to adjust the language that is used throughout a given project
> > to be more inclusive.
> >
> > We discussed this briefly at the most recent YP Technical Team/Engineering
> > Sync Meeting. Many good points were raised. I'd like to start a discussion 
> > on
> > this topic via email in order to enumerate and keep track of these efforts.
> >
> > 1. As a project we need to decide whether or not to undertake this work. Not
> > all projects have decided to make any changes. The discussions we had at the
> > last meeting made it feel as though it was a forgone conclusion by those who
> > spoke up that we would take on this work. Is that the consensus? Silence
> > represents agreement?
>
> A note here, as I was talking with Paul Barker about this last week.
>
> We've already done this in part of YP, in the now retired autobuilder
> code base (about 6 years ago), removing master/slave terminology. So
> there is precedent. I think it should be done, as much as it can be
> done. Certainly WHITELIST/BLACKLIST type terminology at minimum.

If people find the terms whitelist/blacklist offensive I encourage
them to communicate this to the community. Other than the obvious
(which seems may be a coincidence?) I don't understand these words to
have racial connotations based on my interpretation of the etymology.

See this upvoted reply:
https://www.reddit.com/r/AskHistorians/comments/866ynp/what_are_the_origins_of_the_words_blacklist_and/

If this is incorrect or incomplete information I encourage others to
provide information which might help me broaden my understanding.

I guess this brings up another philosophical question. Should
terminology be changed to prevent people from possibly being offended
(due to misunderstanding) even if the words weren't used in an
offensive context or have an offensive origin?

>
> >
> > 2. Scope Creep. From the dawn of the OE project, there have been 
> > "discussions"
> > around variable/function names. In order to keep this work sane and 
> > concise, I
> > must insist that the scope of this work is "inclusive language" not "PN is 
> > too
> > cryptic for beginners, we should expand it to PACKAGENAME"
>
> Agreed.
>
> >
> > 3. Deprecation Plan. Given the layered nature of the ecosystem, inevitably
> > there will be not-so-frequently-used layers out there that could stop 
> > working
> > entirely depending on how this work is implemented. Do we continue to 
> > support
> > the "old" language indefinitely? Do we have a flag day where everything
> > changes at once? Do we give warnings for X releases then have a cut off?
>
> I think we need to do this responsibly, so yes, I'd be in favour of a
> "here is our ideal, here is our deadline" and communicating that out
> to all layer maintainers in layers.openembedded.org as well as the
> mailing lists with a clearly defined set of goals and dates and doing
> the things we can do to minimize build breakage between now and that
> point.
>
> -b
>
> >
> > 4. What will be affected? Branch names, variable names, function names,
> > fetchers, patch file names, documentation… Given the fact we build code from
> > upstream projects, if we currently build from an upstream's master branch 
> > and
> > that upstream project never changes the name of their main branch away from
> > "master", I don't think there's anything we can do in those cases.
> >
> > 5. Backports. How far back do we make changes?
> >
> > 6. Terminology. The Linux kernel project has put out some recommendations:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb
> >
> > To start the discussion, can we please get a consensus on item #1? If
> > positive, can we then work on whether we agree with the list of items (have 
> > I
> > forgotten anything, are there things to add to the list, or things to remove
> > from the list)? THEN can we please focus on each of the items from the list 
> > we
> > create?
> >
> > I think that would be a more sane approach rather than trying to do 
> > everything
> > at once.
> >
> > Best regards,
> >         Trevor
> >
> 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#1137): 
https://lists.openembedded.org/g/openembedded-architecture/message/1137
Mute This Topic: https://lists.openembedded.org/mt/75515261/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to