Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1073255imm; Wed, 17 Oct 2018 12:54:38 -0700 (PDT) X-Google-Smtp-Source: ACcGV61i9MU/PMAJbHmVUevJFAqmGcFIIMGhOdjgVZNigZKc+zDM4jmrYHlGOI9sw4j4MkwSEoSt X-Received: by 2002:a63:cb51:: with SMTP id m17-v6mr24863757pgi.105.1539806078651; Wed, 17 Oct 2018 12:54:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539806078; cv=none; d=google.com; s=arc-20160816; b=P+TibLQt6d4J5JarL4ar/8jIQUERFhJcVm8RD9hk5VYEpMhwBk7NcdimIgDeiv3ZJV ds1Nv6siMBdCzz9GykBzS3Ps9jrEUC2mcAtpOv5ziB+fTaLj1p1pc66ax6rQZr0BqqUm jntBmuDRgM6VzxeZRak+StDNkJu2gEPvDYNNK11w29MK61lnhywQ+qf4jf/65EuFxfjl Amzkm8lgBSFo/fOBxujexpgtZRDlDq1u51MjEJX1ufg9ZTLcFQRhaQduVuCN0EMdTpUf ADjP3ZTzS64URWyLO85q/jlUtlOo3Hj401/e9cGtWqniKxqegGR2GQAKrsadbqoj2XZp E1pw== 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=x6OaPB+36JBdWhkZ++BX81AZlRsiJSO6bUvHIW4LpB4=; b=ScEaaP5+uEfZqfgFpVdIg9Fyxyijh22/kS7UocJxeeqrRfFyfE3sgg3E1f+1US3UVo WgmCRUpEE3HZeFl/4FOJ+NEP4g20UC7UGtvypTxAnT0LGnSPaJ9vpFZAKD695AIIg1qf nz2OstGsIdFQvEy7c9Ojb5FCOI1D4hDCllgqPMXhGbc6nuif/SKDe3W1kbp0ure7Gypz VT6TKNzwUZBAnrCR1xaEet50r5W13kOkLyaAdUQlNLbqgWpua/CBG9iPwdFzbSQCWnJT tmATIqth7OGdt8IDA7tCEy1pUSJLlWJq8/wJFaAmsK7gIupQseGppm8k3CQuzaxL8GVT y7xQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=NpJzU6Em; 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 t11-v6si17545804plq.280.2018.10.17.12.54.22; Wed, 17 Oct 2018 12:54:38 -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=NpJzU6Em; 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 S1727943AbeJRDvP (ORCPT + 99 others); Wed, 17 Oct 2018 23:51:15 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:43838 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727108AbeJRDvP (ORCPT ); Wed, 17 Oct 2018 23:51:15 -0400 Received: by mail-pg1-f193.google.com with SMTP id d8-v6so1804049pgv.10 for ; Wed, 17 Oct 2018 12:54:00 -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=x6OaPB+36JBdWhkZ++BX81AZlRsiJSO6bUvHIW4LpB4=; b=NpJzU6EmmPaKmHBxYryq5Dl9zA8MR6rWSzW6K9WedtO/m99IWFhQInQ5gspGkTMvy3 tS6mvPdyJa5JkaJK1gFD2FPDjQXxbRyLYmkAq6we0glpgNk4N1Epx/lXrQsXtO9m4Ssc qZECUcbeutXEAZi8TQ4J/BHWB1rDw2LvTo+Gs5c3kln4wWpuUQk5h9Jrwbqmg16DJRpw mfYs1juvYZ9yt4h+Rx7go7ikBG6ff0hJeG8SPUAokwq+Xflup78xmvJesPN1pqfc9Pmv 3iMOQAKsr9lyrZmnhcX4TLtnFJjkFmSgsevVK4rxtjVwlUxRnFcRiRhsVyrmI60H/dAs 8bNA== 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=x6OaPB+36JBdWhkZ++BX81AZlRsiJSO6bUvHIW4LpB4=; b=BXV5TdD99+d9CZ2hmaNWrhHWmq5hl4bVKkxDbITpcJlMpqonwKNkqKeHq5SNyU3x2h vLb5EFsxD53vpdG2xUM5EkiNca4Id+O7N4Qi0utppJMhnYsQ/CGqXc8fZUH8hPA3+MSo rZa6G1EBOoIYNIj4Y/H9s2biaRXeV9aVBIp/AU5puo/P334o0DOHS1/vqt7/1QsEW67B ltbBkgVqNOMY1IIiqrsVk+NnKM2BeXrxUCKk/CHXpJXRt9avMUqlMMZh6Wfl0HGjQIL/ gtpPF6fAYmaEP8oFZQL+rtXvXjbM5fHyG04+iIfCQlwd2JZ/ZCYV41RmIC5TguGDIkWt l3zw== X-Gm-Message-State: ABuFfoi+ktX0+4nRJA40A6B+HV8sm3c/QPa64DMTut+f/lGzTwylhmiP 7Y2qKAYbNv2WAV3/adt89Hs= X-Received: by 2002:a65:40c2:: with SMTP id u2-v6mr25680649pgp.123.1539806039738; Wed, 17 Oct 2018 12:53:59 -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 m20-v6sm19232009pgv.93.2018.10.17.12.53.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Oct 2018 12:53:59 -0700 (PDT) Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses To: James Bottomley , ksummit-discuss@lists.linuxfoundation.org Cc: linux-kernel 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> From: Frank Rowand Message-ID: Date: Wed, 17 Oct 2018 12:53:57 -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: <1539803331.3769.62.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/17/18 12:08, James Bottomley wrote: > On Wed, 2018-10-17 at 11:49 -0700, Frank Rowand wrote: >> On 10/16/18 19:41, James Bottomley wrote: >>> On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote: > [...] >>>> 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. > > No, that's not my desired goal. The section is not about giving > permission it's about making sure listed unacceptable behaviours don't > overlap what we normally do. The goal is to exclude email the project > ordinarily collects from immediate sanction under the unacceptable > behaviours clause. I deliberately didn't add anything about permission > because that's up to the project to define in its more standard > contribution documents. OK. I am fine with the goal of wording that excludes certain things from unacceptable behavior instead providing permissions for certain things. I think me phrasing as permission instead of carve out is creating a lot of the miscommunication. Please re-read my comments, but in every place where I state things in a way of providing permissions, re-state it in your mind as the same sentence _except_ phrased as excluding from unacceptable behavior. (I started to do that explicitly, but it looked like I was just going to create a whole lot of distracting text.) >> 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. > > I agree, but, as I said, my goal wasn't to provide explicit permission > (because the list is too long and too dependent on the way the project > operates) it was to carve out an exclusion from sanction for stuff the > kernel normally does. The carve out doesn't translate into explicit > permission because the project can define other standards for the way > email addresses are added to the tags. > >> 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". -Frank > James > >