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

From: Frank Rowand <frowand.list@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Tim.Bird@sony.com, ksummit-discuss@lists.linuxfoundation.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Date: Thu, 18 Oct 2018 16:07:14 -0700	[thread overview]
Message-ID: <2adf5ac1-f837-a598-433d-db43459028db@gmail.com> (raw)
In-Reply-To: <1539892678.18970.30.camel@HansenPartnership.com>

On 10/18/18 12:57, James Bottomley wrote:
> On Thu, 2018-10-18 at 19:49 +0000, Tim.Bird@sony.com 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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 
> 