Message-ID: <998bffa8-d280-8779-e567-c758f27b7b7b@infradead.org>
Date:   Wed, 17 Oct 2018 12:07:33 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Frank Rowand <frowand.list@...il.com>,
        James Bottomley <James.Bottomley@...senPartnership.com>,
        ksummit-discuss@...ts.linuxfoundation.org
Cc:     linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the
 ambiguity about collecting email addresses

On 10/17/18 11:49 AM, Frank Rowand wrote:
> On 10/16/18 19:41, James Bottomley wrote:
>> On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote:
>>> On 10/16/18 07:58, James Bottomley wrote:
>>>> The current code of conduct has an ambiguity in the it considers
>>>> publishing
>>>> private information such as email addresses unacceptable
>>>> behaviour.  Since
>>>> the Linux kernel collects and publishes email addresses as part of
>>>> the patch
>>>> process, add an exception clause for email addresses ordinarily
>>>> collected by
>>>> the project to correct this ambiguity.
>>>>
>>>> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
>>>> Acked-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>>> Acked-by: Shuah Khan <shuah@...nel.org>
>>>> Acked-by: Guenter Roeck <linux@...ck-us.net>
>>>> Reviewed-by: Alan Cox <alan@...yncelyn.cymru>
>>>> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@...nel.org>
>>>> Acked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>>>> Acked-by: Kees Cook <keescook@...omium.org>
>>>> Signed-off-by: James Bottomley <James.Bottomley@...senPartnership.c
>>>> om>
>>>> ---
>>>>  Documentation/process/code-of-conduct.rst | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/Documentation/process/code-of-conduct.rst
>>>> b/Documentation/process/code-of-conduct.rst
>>>> index ab7c24b5478c..aa40e34e7785 100644
>>>> --- a/Documentation/process/code-of-conduct.rst
>>>> +++ b/Documentation/process/code-of-conduct.rst
>>>> @@ -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
>>>>  
>>>>
>>>
> 
> There seems to be a disconnect between what I am trying to
> communicate and what I perceive you to have understood.
> 
> I'll add comments below to try to make more clear what I'm trying to
> say.
> 
> But first a general statement.  I understand that the intent of the
> patch wording is to allow use of email addresses in the tags of a patch
> submittal or git commit without being an unacceptable behavior.  I do
> not think that the words in the patch accomplish that goal.
> 
> 
>>> Repeating my comment on version 1:
>>>
>>> My understanding of the concern behind this change is that we should
>>> be able to use an email address for the current development
>>> practices, such as Reported-by, Suggested-by, etc tags when the email
>>> address was provided in what is a public space for the project.  The
>>> public space is visible to anyone in the world who desires to access
>>> it.
>>>
>>> I do not understand how "ordinarily collected by the project" is
>>> equivalent to "an email address that was provided in a public space
>>> for the project".
>>
>> I don't think it is ... or should be.  This section is specifically
>> enumerating unacceptable behaviours.  The carve out "email address not
>> ordinarily collected by the project" means that adding someone's email
>> address in a tag isn't immediately sanctionable in the code of conduct
>> as unacceptable behaviour if a question about whether you asked
>> explicit permission arises.  Equally, a carve out from unacceptable
>> behaviours doesn't make the action always acceptable, so it's not a
>> licence to publish someone's email address regardless of context.
> 
> The patch says "Publishing ... electronic address not ordinarily
> collected by the project, without explicit permission".  (I think it
> is fair to abstract here with "...".)  This phrase specifies which
> email addresses can be published.  It does not specify in what cases
> the email address can be published.  The desired goal is to be able to
> publish email addresses in patch and commit tags.
> 
> Which email addresses are allowed to be published?  (This is the point
> of my original comment.)  To me, the patch wording is describing how
> I can determine whether I can put a specific email address in a tag
> in a patch that I submit or commit.  I can put an email address in a
> tag _if_ it is "ordinarily collected by the project".
> 
> This then leads my mental process down the path of the disclosures (from
> all of the companies that I do business with) that tell me what they
> are going to do with my personal information, such as my address.  (They
> usually plan to share it with the world for their financial benefit.)
> In that context, my personal information is not _public_, but it is
> _ordinarily collected_ by the company.  I hope this provides some
> insight into what I am reading into "ordinarily collected by the project".
> 
> My original comment was trying to provide the concept behind a way to
> create an alternate wording in the patch to define "which email
> addresses".
> 
> Where are email addresses allowed to be published?  I do not understand
> the patch wording to address this at all.
> 
> 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?
> 
> 
>>> Ordinarily collected could include activities that can be expected to
>>> be private and not visible to any arbitrary person in the world.
>>
>> It's not a blanket permission, it's an exclusion from being considered
>> unacceptable behaviour.  I would be interested to know what information
>> we ordinarily collect in the course of building linux that should be
>> considered private because I might have missed something about the
>> implications here.
> 
> Permission vs exclusion is orthogonal to my comments.
> 
> "building linux" is not the patch wording.  "ordinarily collected by the
> project" is a much broader universe.
> 
> A very simplistic definition of public _could_ be:
> 
>   - Visible on a project mail list that any one can subscribe to
>   - Visible on a project mail list whose archive is available via
>     the public internet
>   - Visible on an interactive communication ("chat") platform that
>     is open to the public internet
>   - Published on a web page intended for public access (for example
>     this could cover opt-in conference attendee lists and emails
>     that conference presenters voluntarily place in their slides).

does that include bugzilla.kernel.org, or should we think of those email
addresses (of bug submitters) as private?  They look public to me.

>   - (I am guessing the above covers 97% or more of possible public
>     sources, but maybe there are some more common sources.)
> 
> I'm sure that the professionals that deal with information privacy
> could provide better wording for the above list.  I am but an
> amateur in that field.
> 
> Anything else collected by the project would not be considered public.
> For example, an email address provided in an email sent to me and not
> copied to any mail list would not be public.
> 
> -Frank
> 
>>
>> James
>>
>>> My issue is with the word choice.  I agree with the underlying
>>> concept.
>>>
>>> -Frank


-- 
~Randy

Powered by blists - more mailing lists