ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Frank Rowand <frowand.list@gmail.com>,
	ksummit-discuss@lists.linuxfoundation.org
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Date: Wed, 17 Oct 2018 12:08:51 -0700	[thread overview]
Message-ID: <1539803331.3769.62.camel@HansenPartnership.com> (raw)
In-Reply-To: <16a20416-0045-dfe6-d937-63f2f0cff269@gmail.com>

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.

> 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
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?

James

  parent reply	other threads:[~2018-10-17 19:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16 14:57 [Ksummit-discuss] [PATCH v3 0/3] code of conduct fixes James Bottomley
2018-10-16 14:58 ` [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses James Bottomley
2018-10-17  2:10   ` Frank Rowand
2018-10-17  2:41     ` James Bottomley
2018-10-17 18:49       ` Frank Rowand
2018-10-17 19:07         ` Randy Dunlap
2018-10-17 19:08         ` James Bottomley [this message]
2018-10-17 19:53           ` Frank Rowand
2018-10-18 14:56             ` James Bottomley
2018-10-18 19:22               ` Frank Rowand
2018-10-18 19:49                 ` Tim.Bird
2018-10-18 19:57                   ` James Bottomley
2018-10-18 23:07                     ` Frank Rowand
2018-10-17 19:26         ` Alexandre Belloni
2018-10-16 14:59 ` [Ksummit-discuss] [PATCH v3 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion James Bottomley
2018-10-16 15:00 ` [Ksummit-discuss] [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point James Bottomley
2018-10-17 15:32   ` Shuah Khan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1539803331.3769.62.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=frowand.list@gmail.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox