Message-ID: <ECADFF3FD767C149AD96A924E7EA6EAF805271E5@USCULXMSG01.am.sony.com>
Date:   Thu, 18 Oct 2018 19:49:54 +0000
From:   <Tim.Bird@...y.com>
To:     <frowand.list@...il.com>, <James.Bottomley@...senPartnership.com>,
        <ksummit-discuss@...ts.linuxfoundation.org>
CC:     <linux-kernel@...r.kernel.org>
Subject: RE: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the
 ambiguity about collecting email addresses



> -----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: 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.

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.

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

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

Powered by blists - more mailing lists