Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2505534imm; Thu, 18 Oct 2018 16:09:44 -0700 (PDT) X-Google-Smtp-Source: ACcGV622xsb/QLyOScMVlRnk75EryLJDp2f8IaKs/aZyItZW1xAYq4k8DYg4xwdJqM8AzspksQOd X-Received: by 2002:a63:1555:: with SMTP id 21-v6mr29945232pgv.383.1539904184185; Thu, 18 Oct 2018 16:09:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539904184; cv=none; d=google.com; s=arc-20160816; b=WIpPgbw74Z9wmCmYWhRjcOWJQp2WotTzx6jhqVvBEjBrAoZURQb/xAkuCInOvcvbdK ZzWh3+YUl9TQSirTmanZFswB40y1IseQaUax33Azu1JqdvvSMWEenlWGjyIIReCQPC3F RFUpLd2WYvgewlkCBgxf5hWgjZG0cDRnr7qrQ6aorwSsiSovUi3VVBeWlRU0x+IBzJou /vojYKAvikj98uHGDZ3OkdkcvBuaRkkj+g8ePzuEMk1hb0zTcZZtzk294hnBYdrS0jUf CPAFozPsX9SYL7qjHDH3LrYlLId2NSLlnW/bDQorbfb9Ck3R1ebhQbUrrFOf1CLdEgPp tPCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=6/9qxdhQtj2PyUUTKPga99CxqvsadZpQkwGs+1SaecU=; b=GrLznTIJ1lL0I81L+2SS51oLYvppR3yqjOCtJmEUChknbznnHVptNaSkL0ss8goJp5 UQVU9Fq8/nqT4Vm3BWaVEcTP5YloMWTvMw8bw/JouLLo2Pu2BmKpPuiNyAH+tYlcIno4 KkoJXV3n75t+OuAPn+4CeLidbegPqCPma07zOch1SBMkNOtcrUADh+fTsqInOe2TAcow m3ueGouSjMtLARswqN7rcFkj+0KUld3Io2q6XGoi7EXX+CqA9N9ztiNoByDYd7gXuVr+ 0v+0wAsPnNTn5tLSDPAHQwEj0zmloO9SEjU9i37g66eI+//pHvyOlayj7M00OgPjpzbY djew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YIWpR31d; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u7-v6si434617plz.196.2018.10.18.16.09.28; Thu, 18 Oct 2018 16:09:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=YIWpR31d; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727126AbeJSHKa (ORCPT + 99 others); Fri, 19 Oct 2018 03:10:30 -0400 Received: from mail-pf1-f181.google.com ([209.85.210.181]:35516 "EHLO mail-pf1-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725751AbeJSHKa (ORCPT ); Fri, 19 Oct 2018 03:10:30 -0400 Received: by mail-pf1-f181.google.com with SMTP id l17-v6so15574488pff.2 for ; Thu, 18 Oct 2018 16:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6/9qxdhQtj2PyUUTKPga99CxqvsadZpQkwGs+1SaecU=; b=YIWpR31dBml4PFyjTbQkeXfYDyi3hMibycwRAd0B+2lEbPMzTCmc+KWsSeHDyq6KC+ FX6++EDskIRO1Pd21RvgI48W7GlAjbhfoU78lXiNQfhjiEo6dFHBduWjXyxMFEalw4XJ je9HgdtrwDATcYux3DEtDmZUP0MYMNWxGXuS1sYZUxNBqU5R18nla94XC5Zd98u987QO 0THqvnzIx8YiP5T8N06uvRssRuh/6a0QyglJ8ByL5Kut9/wR32QojazPSZFmvXD8KwAO ocf0KWDs4EfW7k1zkjFZd0rPV5qWD4XpekdPriSmzBpuyKglgIUil86t/xIdiXqYougN 4ZoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6/9qxdhQtj2PyUUTKPga99CxqvsadZpQkwGs+1SaecU=; b=AKxtFuO/PlIWznKjWQC4C5bpfbYEm8dBAB7qRUM+kUUfAoI5kgqP9Vfi+VdUOGbuMw VxvVEi3CIQdKOL1fK64xvkyhrchsjgX72IAD24zdvkg9HGDpMSr0Pi4aHHcS8C0mqMra NZ5vOs2+pVs6p4T3nxzDYueM9kfPLIaSQjJFGGkCfFNYV1Z8gyN01TP3BUh8Y04kDeDO Fz7a8x90zv8uPxqVeaCD/1xpStUb91KAu7oYLW9riN2j4vd60aIqsoV0iX+lEpEEUX5H I/bOtAbKPBBR1d6YXxtiSnftqq/hi/CMz0MeyIvdU3+tcwQ7zh9x0wWAixX/Ry3uSv/3 6rZw== X-Gm-Message-State: ABuFfogLveQAAQ7WI2nReQuGxCr/mPaKwvttrk7GwL2ih5CImXoKZW7l ntMTIB0n0du4Zi52FGfhBeE= X-Received: by 2002:a63:7f0e:: with SMTP id a14-v6mr30279342pgd.296.1539904036201; Thu, 18 Oct 2018 16:07:16 -0700 (PDT) Received: from [192.168.1.70] (c-24-6-192-50.hsd1.ca.comcast.net. [24.6.192.50]) by smtp.gmail.com with ESMTPSA id d2-v6sm24376608pfn.118.2018.10.18.16.07.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 16:07:15 -0700 (PDT) Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses To: James Bottomley , Tim.Bird@sony.com, ksummit-discuss@lists.linuxfoundation.org Cc: linux-kernel@vger.kernel.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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > >