Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3985833imm; Mon, 8 Oct 2018 12:51:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV62syCWEGSvoVFQvoBIzwcBTzzaANbt3h+dRVmgIkxAaDp5JbjUrgcPYUeFw/DScLYYoTOuz X-Received: by 2002:a63:e943:: with SMTP id q3-v6mr22296509pgj.42.1539028267320; Mon, 08 Oct 2018 12:51:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539028267; cv=none; d=google.com; s=arc-20160816; b=bHxHdTdV/XYIVp1XpQOZj8PCi+vmRY8EYftGsCJcGlmkLOkW7MxfEZYW00BS0TOtX2 In8zQ5P1nph6n2ZxD9MZDKtB1kTQEPiQig9xQL4w8Jne8hcOFSSc8lkc7rkDwILC3+ux n3jJD8osZEIfcjRuTZ9ZadOuj4S6eIXKVnTlrZxeNf/V87VNfQMyZQ9mgyUNUKxquAkf c2NigTu4HRXu2Izhl5C2m1fvuZdten0tc/SQnr0UewnfdFRhdHwzLEJARGRV48ccIz1G YeqsRcOF4UzIPGV9FqTn8jA6Rb8zPvn/8rzbOIoFWvwcbexaD2MRYDAEunPxr4nNKCjl Vd0g== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=WG7Dk5OPpOMO1UTYw/FTHl05v5IkuVTYd6nps4K8U1s=; b=mMvMNlCj1y+aMsPWtz30nxqz2/779aN94aPot6osyW6zPAgt3fYMHJb85uW3F6tQBl TFLFtOYttYRjXlLXyOhAcXQqE4gtGXY2noif4jUrmy5VLvYw9fRE8IrxZIdz9FeQQNvK qyfBvT5sRepS0tRPDuoV+81TPbG/mIFdrP1UHTLy8ot+yeViOuy6X4KOlYG0Xx+PVvxX rd2dxrceWxtgpsvVsyVrCnM5mfM9U+TwxGpWIyEye6xfPls88y9cVKcGPwo4e22Koqjq YsFP66JjqnWTXC/kyG+6LAJlYqWD62weIIOQNytnPBiwMaU+rSobT14DDRjiF758WBY+ s54A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=Nzx3q2Gv; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s136-v6si15689409pgc.7.2018.10.08.12.50.52; Mon, 08 Oct 2018 12:51:07 -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=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=Nzx3q2Gv; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726717AbeJIDDS (ORCPT + 99 others); Mon, 8 Oct 2018 23:03:18 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:34920 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726427AbeJIDDS (ORCPT ); Mon, 8 Oct 2018 23:03:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WG7Dk5OPpOMO1UTYw/FTHl05v5IkuVTYd6nps4K8U1s=; b=Nzx3q2Gvo94fMji9maSz2OJYl /yh3mQn8Z+AlpGC+IrmHMY4QqtyhGWpMFr9gAmR8I3VO5VI7VuV/POZDuzi2XApfyttNRQCyfX/go 9qwVRp4l+LHFVfqQDy0WdHq8UWCVGGJDhE5dkq/bDULujXy1DZHkZw2Q7FnLTbwNDyAxJA+xW4MgW um52ldaqFhomc7c41SwZOQH7Ch9pH8U/erwZnGZQHhrIlLR1uPIg/0geCz4ZpiV1sso6RqoF/FhDF gshsI9niBU6VZZ9jaHSvLlzSnheVbmzFgYB26viweFTsd9oSPStYeQCIuk8hwqTfgWDcifMae76Qf WnqhGDpKQ==; Received: from [179.183.98.126] (helo=coco.lan) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1g9bXN-00074m-Fv; Mon, 08 Oct 2018 19:49:53 +0000 Date: Mon, 8 Oct 2018 16:49:50 -0300 From: Mauro Carvalho Chehab To: James Bottomley Cc: Daniel Vetter , Linux Kernel Mailing List , ksummit Subject: Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses Message-ID: <20181008164950.71793583@coco.lan> In-Reply-To: <1538926141.4115.2.camel@HansenPartnership.com> References: <1538861738.4088.5.camel@HansenPartnership.com> <1538861799.4088.6.camel@HansenPartnership.com> <1538926141.4115.2.camel@HansenPartnership.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Sun, 07 Oct 2018 08:29:01 -0700 James Bottomley escreveu: > On Sun, 2018-10-07 at 11:04 +0200, Daniel Vetter wrote: > > On Sat, Oct 6, 2018 at 11:36 PM James Bottomley > > wrote: =20 > > >=20 > > > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 > > > 2001 > > > From: James Bottomley > > > Date: Sat, 6 Oct 2018 14:21:56 -0700 > > > Subject: [PATCH 1/2] code-of-conduct: Fix the ambiguity about > > > collecting email > > > =C2=A0addresses > > >=20 > > > The current code of conduct has an ambiguity in the it considers > > > publishing private information such as email addresses unacceptable > > > behaviour.=C2=A0=C2=A0Since the Linux kernel collects and publishes e= mail > > > addresses as part of the patch process, add an exception clause for > > > email addresses ordinarily collected by the project to correct this > > > ambiguity. > > >=20 > > > Signed-off-by: James Bottomley > > om> =20 > > > --- > > > =C2=A0Documentation/process/code-of-conduct.rst | 2 +- > > > =C2=A01 file changed, 1 insertion(+), 1 deletion(-) > > >=20 > > > 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: > > > =C2=A0* Trolling, insulting/derogatory comments, and personal or > > > political attacks > > > =C2=A0* Public or private harassment > > > =C2=A0* Publishing others=E2=80=99 private information, such as a phy= sical or > > > electronic > > > -=C2=A0=C2=A0address, without explicit permission > > > +=C2=A0=C2=A0address not ordinarily collected by the project, without > > > explicit permission > > > =C2=A0* Other conduct which could reasonably be considered inappropri= ate > > > in a > > > =C2=A0=C2=A0=C2=A0professional setting =20 > >=20 > > We've discussed this a bit with freedesktop.org people a while ago, > > both from a CoC and privacy regulations pov, and we concluded that > > attaching random people's emails in Reported-by: and similar lines, > > without their consent, is indeed a problem. Bugzilla is rather > > problematic in this way, since it looks like it's protecting your > > email address and keeping it private, but then you can still just > > grab it from the bugzilla emails without first asking for permission. > > That's one of the reasons why fd.o admins want to retire Bugzilla in > > favour of gitlab issues (where this is handled a lot more strictly). =20 >=20 > This is a code of conduct example of a violation. While I agree we > should exercise sensitivity in reporter expectations I don't think a > maintainer getting it wrong should be equated to doxxing. >=20 > In many ways, this is why having examples sections in quasi legal > documents is a bad thing to do because it's arguable (as you have done) > that if some behaviour isn't explicitly mentioned in the unacceptable > examples it must be acceptable. >=20 > Look at it this way: if a maintainer screws up and adds a reported by > from someone who didn't expect their email to be published should that > be treated as an immediate code of conduct violation by whatever > enforcement process we come up with? I think most maintainers would > answer "no" to this.=20 Agreed.=20 I'd say more: what happens if someone adds a diff inside a bug report? Not adding the author can be problematic too. People should assume that, when reporting a bug, replying to a patch, etc, his e-mail will be visible by people, and it can be used when a fixup patch is produced. If someone doesn't want that, it should *explicitly* say otherwise. The text changes suggested by James reflects that: an e-mail sent in private, with an explicit message saying to not use the personal address is not an "electronic address not ordinarily collected by the project". Of course, it is up to the maintainer/developer that receives such e-mails to either use its content, anonimizing the submitter as requested (and eventually taking associated risks with regards to GPL - if the email contains a patch) or to just ignore it. Anyway, such "special cases" are the kind of thing that makes sense on a FAQ, and not at the letter of the document itself. Thanks, Mauro