From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7331F516 for ; Thu, 18 Oct 2018 23:07:17 +0000 (UTC) Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EF437E9 for ; Thu, 18 Oct 2018 23:07:16 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id l81-v6so15575994pfg.3 for ; Thu, 18 Oct 2018 16:07:16 -0700 (PDT) To: James Bottomley , Tim.Bird@sony.com, ksummit-discuss@lists.linuxfoundation.org References: <1539701820.2805.6.camel@HansenPartnership.com> <1539701896.2805.7.camel@HansenPartnership.com> <1539744091.2805.108.camel@HansenPartnership.com> <16a20416-0045-dfe6-d937-63f2f0cff269@gmail.com> <1539803331.3769.62.camel@HansenPartnership.com> <1539874609.2845.5.camel@HansenPartnership.com> <1539892678.18970.30.camel@HansenPartnership.com> From: Frank Rowand Message-ID: <2adf5ac1-f837-a598-433d-db43459028db@gmail.com> Date: Thu, 18 Oct 2018 16:07:14 -0700 MIME-Version: 1.0 In-Reply-To: <1539892678.18970.30.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Cc: linux-kernel@vger.kernel.org Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 > >