Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses

From: Frank Rowand
Date: Thu Oct 18 2018 - 19:07:19 EST


On 10/18/18 12:57, James Bottomley wrote:
> On Thu, 2018-10-18 at 19:49 +0000, Tim.Bird@xxxxxxxx wrote:
>>> -----Original Message-----
>>> From: Frank Rowand
>>>
>>> On 10/18/18 07:56, James Bottomley wrote:
>>>> On Wed, 2018-10-17 at 12:53 -0700, Frank Rowand wrote:
>>>>> On 10/17/18 12:08, James Bottomley wrote:
>>>>
>>>> [...]
>>>>>>> Trying to understand how you are understanding my comment
>>>>>>> vs what
>>>>>>> I intended to communicate, it seems to me that you are
>>>>>>> focused on
>>>>>>> the "where allowed" and I am focused on the "which email
>>>>>>> addresses".
>>>>>>>
>>>>>>> More clear? Or am I still not communicating well enough?
>>>>>>
>>>>>> I think the crux of the disagreement is that you think the
>>>>>> carve
>>>>>> out equates to a permission which is not specific enough and
>>>>>> I
>>>>>> think it
>>>>>
>>>>> Nope. That is a big place where I was not transferring my
>>>>> thoughts
>>>>> to clear communication. I agree that what I wrote should have
>>>>> been
>>>>> written in terms of carve out instead of permission.
>>>>>
>>>>>
>>>>>> doesn't equate to a permission at all, which is why there's
>>>>>> no need
>>>>>> to make it more explicit. Is that a fair characterisation?
>>>>>
>>>>> Nope. My concern is "which email addresses".
>>>>
>>>> The idea here was because it's a carve out that doesn't give
>>>> permission
>>>> and because the permission is ruled by the project contribution
>>>> documents, the carve out should be broad enough to cover anything
>>>> they
>>>> might say hence "email addresses not ordinarily collected by the
>>>> project" are still included as unacceptable behaviour.
>>>>
>>>> Perhaps if you propose the wording you'd like to see it would
>>>> help
>>>> because there still looks to be some subtlety I'm not getting.
>>>
>>>
>>> From the beginning of the thread:
>>>
>>> > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by
>>> participants
>>> include:
>>> > * Trolling, insulting/derogatory comments, and personal or
>>> political
>>> attacks
>>> > * Public or private harassment
>>> > * Publishing othersâ private information, such as a physical
>>> or electronic
>>> > - address, without explicit permission
>>> > + address not ordinarily collected by the project, without
>>> explicit
>>> permission
>>> > * Other conduct which could reasonably be considered
>>> inappropriate in a
>>> > professional setting
>>>
>>>
>>> Alternative (and I'm sure someone else can probably clean this up a
>>> little bit):
>>>
>>> + address that has been provided in a public space for the project,
>>> without explicit permission
>>
>> This ends up reading like so:
>>
>> ----
>> Examples of unacceptable behavior by participants include:
>> ...
>> * Publishing othersâ private information, such as a physical or
>> electronic
>> address that has been provided in a public space for the project,
>> without
>> explicit permission.
>> ----
>>

>> I think that in context, you want a 'not' in there. That is:

Yes, thank you.


>> unacceptable behavior includes publishing others' private
>> information... that has *not* been provided in a public space. So, I
>> think the suggested text needs some fixing, IMHO.
>
> You beat me to this one. However, there is another issue that I did
> touch on but perhaps not in this subthread: For those of us who live in
> the US, our addresses (that's physical and sometimes email) are
> actually provided in a public space because they're available in the
> public property records. That's actually why I chose "not ordinarily
> collected by the project" as opposed to "not previously provided in the
> public space" or an equivalent because doxxing in the US is mostly
> finding this information from public sources and broadcasting it.

That clarification helps a _lot_ in understanding what you have said
previously in this thread. Thanks. :-)


>> I looked at this issue upstream, and decided to leave the wording in
>> the CoC itself alone - favoring instead to add a clarifying addition
>> to the upstream CoC FAQ, about some email addresses not being
>> private information.
>>
>> The reason I took that approach, rather than try to change the
>> wording inside the CoC, is that the current wording seems to me to be
>> sufficient. The thing that is unacceptable is publishing private
>> information. The "such as..." clause is intended to convey examples
>> of the types of thing that might usually be considered private
>> information. But it is not exhaustive, nor is it necessarily
>> correct, depending on the circumstances. In particular, email
>> addresses are sometimes private information and sometimes not.
>> In the context of kernel development, many email addresses are not
>> private.
>>
>> I am sympathetic to the argument that we use emails as public
>> information so much in kernel development processes, that it makes
>> sense to omit this or qualify it more.
>
> I think that's the sense of the people who acked this, yes. Personally
> I'm happy with a separate clarification in another document, but I can
> also see the argument that we do need our single CoC to be consistent
> with our operational method, which is why I proposed the patch.
>
>> My own views are that:
>> 1) if we change this line at all, we should simply omit the "such
>> as..." part of the phrase, and leave it at:
>>
>> * Publishing othersâ private information without explicit permission
>
> This looks OK to me too ... the problem with the original is that the
> additional qualification overlaps our normal project method of
> operation, this solves the issue as well.

Looks good to me.

-Frank

>
> James
>
>
>> but also
>> 2) I'm OK with leaving the phrase as is and handling the concerns
>> in an clarifying document.
>>
>> Just my 2 cents.
>> -- Tim
>>
>>
>>
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@xxxxxxxxxxxxxxxxxxxxxxxxx
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
>