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

[Frank Rowand]

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@xxxxxxxxxxxxxx>
>>> Acked-by: Shuah Khan <shuah@xxxxxxxxxx>
>>> Acked-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>>> Reviewed-by: Alan Cox <alan@xxxxxxxxxxxxxxxx>
>>> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@xxxxxxxxxx>
>>> Acked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
>>> Acked-by: Kees Cook <keescook@xxxxxxxxxxxx>
>>> Signed-off-by: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxx
>>> 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).
  - (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
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@xxxxxxxxxxxxxxxxxxxxxxxxx
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 
>