diversity-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Russell <apache....@gmail.com>
Subject Re: Conscious Language Checker at the ASF
Date Fri, 10 Sep 2021 00:48:31 GMT
Hi Christofer,

I don't know plc4x well, but have some generic ideas. 

You cannot unilaterally change what you depend on but you can control how users see your interface.
So your interface could use inclusive words like primary/secondary and the interface maps
these terms into the underlying APIs that might use non-inclusive words.

Perhaps you are already doing this anyway. But if you are required to use terms that are part
of the underlying APIs you can "ignore" them in the CLC tool.

So the tool can still be useful in highlighting your API's use of the terms.

Is there any point in raising these questions to "industry standards" groups that your underlying
platforms are members of?

HTH,
Craig

> On Sep 9, 2021, at 1:03 PM, Christofer Dutz <christofer.dutz@c-ware.de> wrote:
> 
> Hi all,
> 
> I just took the question about the CLC to the PLC4X project. There we very quickly noticed
that we would be stuck in a dilemma:
> 
> We're implementing drivers for protocols that use pretty un-inclusive terms ... A Modbus
Master is simply called that, same as A Modbus Slave. A PROFINET Master also simply is called
that way. We could now decide to call it something different, but that would definitiely confuse
people. 
> 
> What are your thoughts on this?
> 
> Chris
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Rich Bowen <rbowen@rcbowen.com> 
> Gesendet: Dienstag, 7. September 2021 14:40
> An: dev@diversity.apache.org; Łukasz Dywicki <luke@code-house.org>; private@karaf.apache.org
> Betreff: Re: Conscious Language Checker at the ASF
> 
> 
> 
> On 9/5/21 6:03 PM, Łukasz Dywicki wrote:
>> My feeling is close to Christian's in this regard.
>> 
>> Writing docs is usually harder than writing code, especially for for 
>> non-native speakers. Similar thing applies to non-native readers of it.
>> Try writing up a piece of PKI description without using "Alice and Bob"
>> and correlated his/her phrases.
>> 
>> While I understand that many society groups been going through various 
>> troubles now and in the past, I do believe that changing of vocabulary 
>> will simply not fix their issues. To be fair I don't know how to write 
>> that to not step on somebody's else sensitive toe.
> 
> You'll get no disagreement from me on that - anyone who thinks that changing vocabulary
will fix everything is fooling themselves. Nope, this is one step out of many. But it's an
important step, because it causes us to *think* about how words affect others. And that, in
my experience, leads us to think about how *everything* affects others. 
> Compassion and empathy start with small gestures. Small steps become larger steps. Thinking
that the small step is the entire solution is a mistake. Worse yet, deciding not to take the
small step because it's not the entire solution, causes the larger steps to never be considered.
> 
>> On 02.09.2021 20:18, Christian Schneider wrote:
>>> When there is a list of "bad" words and a tool that highlights them 
>>> then this is exactly how it feels.
>>> 
>>> Christian
>>> 
>>> Am Do., 2. Sept. 2021 um 20:05 Uhr schrieb Rich Bowen <rbowen@rcbowen.com>:
>>> 
>>>> 
>>>> 
>>>> On 9/2/21 1:52 PM, Christian Schneider wrote:
>>>>> I do not like this effort. Banning words and pointing them out is 
>>>>> the
>>>> wrong
>>>>> way to achieve an inclusive environment.
>>>>> Also I think words like he or she must not be banned. They are 
>>>>> neutral words that are totally acceptable in many cases.
>>>>> Avoiding them in most documentation might be fine but having them 
>>>>> on a
>>>> bad
>>>>> word list feels extremely wrong to me.
>>>>> 
>>>>> In our well meant effort to be woke we sometimes go too far.
>>>> 
>>>> You have misunderstood this initiative. Nothing is banned, 
>>>> forbidden, struck from the language, or otherwise removed from use.
>>>> 
>>>> If you agree that avoiding these words in documentation might be 
>>>> fine, then we're on the same page.
>>>> 
>>>> Please don't make this into something it's not. Nobody has the 
>>>> authority, or even the desire, to forbid you using certain words. 
>>>> This tool is only intended to point out places where there *might* 
>>>> be a better word choice.
>>>> 
>>>> --
>>>> Rich Bowen - rbowen@rcbowen.com
>>>> @rbowen
>>>> 
>>> 
>>> 
> 
> --
> Rich Bowen - rbowen@rcbowen.com
> @rbowen

Craig L Russell
clr@apache.org


Mime
View raw message