From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) by mx.groups.io with SMTP id smtpd.web11.8433.1635320525427482288 for ; Wed, 27 Oct 2021 00:42:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@posteo.de header.s=2017 header.b=DJNgal47; spf=pass (domain: posteo.de, ip: 185.67.36.65, mailfrom: mhaeuser@posteo.de) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 97557240027 for ; Wed, 27 Oct 2021 09:42:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1635320521; bh=vOE3tG/q0P/5Tn1+4E4DRYoTwre2hChhEhCki9cvT7E=; h=Date:Subject:To:From:From; b=DJNgal47rfc1H3fyMNA/x2o3Gl+iEhntksZEnpAVxOpsAHHAGehOkbi39yFk/p9KM o3aD7hr3DE50mlzQm5MmiK92jfaRLRjL/IFNcJi5ekZiktILsKpVJ7o5bDkeY6iFvc yCASI13J7MZLvM5+irc561z8XJQ8xqT4mPOwAcEJHKrtZoYrE+Z54d/KUmpIz/sfFg JxIbGjByy5TZ7Zz79K+sToFlLlHbEtv0Si+WMGJpQa3BaeGVEmyRCbdrLHn+VM4FsY M0oejS44AEC6RIXzFpKwLuy89QFpfSk9puk6lMDtic/ijk8LVvNQBNvdPLWufqbNkm PFrjFBLwZDD1A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4HfLHX52XDz6tmL; Wed, 27 Oct 2021 09:42:00 +0200 (CEST) Message-ID: <7e69ee30-e465-8ae7-149f-3e9d2622e813@posteo.de> Date: Wed, 27 Oct 2021 07:42:00 +0000 MIME-Version: 1.0 Subject: Re: [edk2-rfc] Inclusive Language RFC To: rfc@edk2.groups.io, Lynn.L.Teng@Intel.com, "devel@edk2.groups.io" , "discuss@edk2.groups.io" References: From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= In-Reply-To: Content-Language: en-GB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hey, On 25.10.21 20:47, Teng, Lynn L wrote: > Hello all, > > Please provide your feedback and comments to the Inclusive Language Plan below over the next two weeks (10/25-11/05). Thank you in advance for your contributions. > > > *** > > ## Overview > > To promote a more inclusive and open ecosystem, TianoCore is dedicated to removing archaic terminology that holds negative connotation. > In collaboration with UEFI, we will be following the same [Inclusive Language Implementation Guidelines](https://uefi.org/sites/default/files/resources/UEFI_Inclusive%20Language.pdf) as stated on [UEFI.org](https://uefi.org/). > > > ## Plan > > 1. Announcement of intent, and all check-ins from here onwards will need to abide by Inclusive Language Implementation Guidelines > 2. Scrubbing of all comments, documentation, and Wiki pages > 3. Scrubbing all non-legacy code > 3.1. Integrate open-source commit hook that will warn submitter of violations > 4. Working with UEFI to scrub legacy code > 4.1. Update commit hook to block submissions with violations > > > ## Implementation Guidelines > > ### Master/Slave to not be used together nor alone. > Alternatives: > Master | Slave > -------|------- > Main | Secondary, Subordinate > Primary | Secondary, Replica > Host | Target > Leader | Follower > Orchestrator | Worker > Initiator | Responder Some of these combinations sound very awkward because they are not strictly or strongly related language-wise. Examples: - In my opinion, a replica can very well be a main, it just cannot be an original. - "Responder" is very generic - "slave" conveys work, not just any sort of reaction - "Primary" and "secondary" are clearly related, "main" and "secondary" are not. ... The combination "leader"/"follower" could be interpreted politically if you just try hard enough, who knows what language revision proposals may look like in 10 years from now. Maybe drop it entirely. :) > Or similar descriptive terminology > > ### Blacklist/Whitelist to not be used together nor alone. > Alternatives: > Blacklist | Whitelist > ----------|---------- > Blocklist | Passlist > Denylist | Allowlist > Refused, Denied | Permitted I think this should be made stricter to "refused"/"permitted" and "granted"/"denied" to stay consistent with common usage. My biggest issues with such proposals is they tell me which words to not use, but not which to use instead. Yes, there are plenty of alternatives given, but when do I use which? E.g. "host" / "target" already is a very common combination for debugging, but nobody would think of naming their main git branch "host". If you deprecate widely conventional terminology, in my opinion you should also provide clear and detailed guidelines for which sub-areas they are deprecated by which exact alternatives (e.g. "version control - main; debugging - host"). I don't think a terminology zoo where everybody picks their preference by gut feeling is in anyone's best interest. Thanks! Best regards, Marvin > > Or similar descriptive terminology > > > > >