From: Randy Dunlap <rdunlap@infradead.org>
To: Frank Rowand <frowand.list@gmail.com>,
James Bottomley <James.Bottomley@HansenPartnership.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:07:33 -0700 [thread overview]
Message-ID: <998bffa8-d280-8779-e567-c758f27b7b7b@infradead.org> (raw)
In-Reply-To: <16a20416-0045-dfe6-d937-63f2f0cff269@gmail.com>
On 10/17/18 11:49 AM, Frank Rowand wrote:
> On 10/16/18 19:41, James Bottomley wrote:
>> On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote:
>>> On 10/16/18 07:58, James Bottomley wrote:
>>>> The current code of conduct has an ambiguity in the it considers
>>>> publishing
>>>> private information such as email addresses unacceptable
>>>> behaviour. Since
>>>> the Linux kernel collects and publishes email addresses as part of
>>>> the patch
>>>> process, add an exception clause for email addresses ordinarily
>>>> collected by
>>>> the project to correct this ambiguity.
>>>>
>>>> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
>>>> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
>>>> Acked-by: Shuah Khan <shuah@kernel.org>
>>>> Acked-by: Guenter Roeck <linux@roeck-us.net>
>>>> Reviewed-by: Alan Cox <alan@llwyncelyn.cymru>
>>>> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>>>> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>> Acked-by: Kees Cook <keescook@chromium.org>
>>>> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.c
>>>> om>
>>>> ---
>>>> Documentation/process/code-of-conduct.rst | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> 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:
>>>> * 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
>>>>
>>>>
>>>
>
> There seems to be a disconnect between what I am trying to
> communicate and what I perceive you to have understood.
>
> I'll add comments below to try to make more clear what I'm trying to
> say.
>
> But first a general statement. I understand that the intent of the
> patch wording is to allow use of email addresses in the tags of a patch
> submittal or git commit without being an unacceptable behavior. I do
> not think that the words in the patch accomplish that goal.
>
>
>>> 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.
>
> 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.
>
> 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?
>
>
>>> Ordinarily collected could include activities that can be expected to
>>> be private and not visible to any arbitrary person in the world.
>>
>> It's not a blanket permission, it's an exclusion from being considered
>> unacceptable behaviour. I would be interested to know what information
>> we ordinarily collect in the course of building linux that should be
>> considered private because I might have missed something about the
>> implications here.
>
> Permission vs exclusion is orthogonal to my comments.
>
> "building linux" is not the patch wording. "ordinarily collected by the
> project" is a much broader universe.
>
> A very simplistic definition of public _could_ be:
>
> - Visible on a project mail list that any one can subscribe to
> - Visible on a project mail list whose archive is available via
> the public internet
> - Visible on an interactive communication ("chat") platform that
> is open to the public internet
> - Published on a web page intended for public access (for example
> this could cover opt-in conference attendee lists and emails
> that conference presenters voluntarily place in their slides).
does that include bugzilla.kernel.org, or should we think of those email
addresses (of bug submitters) as private? They look public to me.
> - (I am guessing the above covers 97% or more of possible public
> sources, but maybe there are some more common sources.)
>
> I'm sure that the professionals that deal with information privacy
> could provide better wording for the above list. I am but an
> amateur in that field.
>
> Anything else collected by the project would not be considered public.
> For example, an email address provided in an email sent to me and not
> copied to any mail list would not be public.
>
> -Frank
>
>>
>> James
>>
>>> My issue is with the word choice. I agree with the underlying
>>> concept.
>>>
>>> -Frank
--
~Randy
next prev parent reply other threads:[~2018-10-17 19:07 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 [this message]
2018-10-17 19:08 ` James Bottomley
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=998bffa8-d280-8779-e567-c758f27b7b7b@infradead.org \
--to=rdunlap@infradead.org \
--cc=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