* [PATCH v3 0/3] code of conduct fixes @ 2018-10-16 14:57 James Bottomley 2018-10-16 14:58 ` [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses James Bottomley ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: James Bottomley @ 2018-10-16 14:57 UTC (permalink / raw) To: ksummit-discuss; +Cc: linux-kernel Resend to modify the third patch to add (except where required by law) and accumulate more tags --- Previous cover letter: Resend to show accumulated tags and also to add a third patch listing the TAB as the reporting point as a few people seem to want. If it gets the same level of support, I'll send it in with the other two. --- Previous cover letter: We've had several threads discussing potential changes to the code of conduct but Mauro is the only person to have proposed an actual patch. In order to move the debate on, I'm presenting two patches, one to fix the email problem Mauro identified and the other to strip the enforcement section pending community discussion as Shuah suggested. I'll take responsibility for collecting any tags people want to add (review/ack/sign off, etc) and sending the patch in as a signed pull request before 4.19 final if they get enough community support. Note, I've sent both patches in as a series to facilitate review and discussion, but they are separable if one is looked on with less favour than the other. It was also a bit unclear which list to send this to, but I finally settled on linux-kernel as the catch all and ksummit-discuss since that's where most of the current discussion is. I can add other lists as people suggest them. James --- James Bottomley (3): code-of-conduct: Fix the ambiguity about collecting email addresses code-of-conduct: Strip the enforcement paragraph pending community discussion code-of-conduct: Add back the TAB as the central reporting point Documentation/process/code-of-conduct.rst | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) -- 2.13.7 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-16 14:57 [PATCH v3 0/3] code of conduct fixes James Bottomley @ 2018-10-16 14:58 ` James Bottomley 2018-10-17 2:10 ` [Ksummit-discuss] " Frank Rowand 2018-10-20 18:11 ` Michael Tirado 2018-10-16 14:59 ` [PATCH v3 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion James Bottomley 2018-10-16 15:00 ` [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point James Bottomley 2 siblings, 2 replies; 18+ messages in thread From: James Bottomley @ 2018-10-16 14:58 UTC (permalink / raw) To: ksummit-discuss; +Cc: linux-kernel 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.com> --- 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 -- 2.13.7 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-16 14:58 ` [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-20 18:11 ` Michael Tirado 1 sibling, 1 reply; 18+ messages in thread From: Frank Rowand @ 2018-10-17 2:10 UTC (permalink / raw) To: James Bottomley, ksummit-discuss; +Cc: linux-kernel 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.com> > --- > 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 > > 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". Ordinarily collected could include activities that can be expected to be private and not visible to any arbitrary person in the world. My issue is with the word choice. I agree with the underlying concept. -Frank ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 2:10 ` [Ksummit-discuss] " Frank Rowand @ 2018-10-17 2:41 ` James Bottomley 2018-10-17 18:49 ` Frank Rowand 0 siblings, 1 reply; 18+ messages in thread From: James Bottomley @ 2018-10-17 2:41 UTC (permalink / raw) To: Frank Rowand, ksummit-discuss; +Cc: linux-kernel 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 > > > > > > 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. > 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. James > My issue is with the word choice. I agree with the underlying > concept. > > -Frank > _______________________________________________ > Ksummit-discuss mailing list > Ksummit-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 2:41 ` James Bottomley @ 2018-10-17 18:49 ` Frank Rowand 2018-10-17 19:07 ` Randy Dunlap ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Frank Rowand @ 2018-10-17 18:49 UTC (permalink / raw) To: James Bottomley, ksummit-discuss; +Cc: linux-kernel 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). - (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 >> _______________________________________________ >> Ksummit-discuss mailing list >> Ksummit-discuss@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 18:49 ` Frank Rowand @ 2018-10-17 19:07 ` Randy Dunlap 2018-10-17 19:08 ` James Bottomley 2018-10-17 19:26 ` Alexandre Belloni 2 siblings, 0 replies; 18+ messages in thread From: Randy Dunlap @ 2018-10-17 19:07 UTC (permalink / raw) To: Frank Rowand, James Bottomley, ksummit-discuss; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 18:49 ` Frank Rowand 2018-10-17 19:07 ` Randy Dunlap @ 2018-10-17 19:08 ` James Bottomley 2018-10-17 19:53 ` Frank Rowand 2018-10-17 19:26 ` Alexandre Belloni 2 siblings, 1 reply; 18+ messages in thread From: James Bottomley @ 2018-10-17 19:08 UTC (permalink / raw) To: Frank Rowand, ksummit-discuss; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 19:08 ` James Bottomley @ 2018-10-17 19:53 ` Frank Rowand 2018-10-18 14:56 ` James Bottomley 0 siblings, 1 reply; 18+ messages in thread From: Frank Rowand @ 2018-10-17 19:53 UTC (permalink / raw) To: James Bottomley, ksummit-discuss; +Cc: linux-kernel 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 > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 19:53 ` Frank Rowand @ 2018-10-18 14:56 ` James Bottomley 2018-10-18 19:22 ` Frank Rowand 0 siblings, 1 reply; 18+ messages in thread From: James Bottomley @ 2018-10-18 14:56 UTC (permalink / raw) To: Frank Rowand, ksummit-discuss; +Cc: linux-kernel 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. James ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-18 14:56 ` James Bottomley @ 2018-10-18 19:22 ` Frank Rowand 2018-10-18 19:49 ` Tim.Bird 0 siblings, 1 reply; 18+ messages in thread From: Frank Rowand @ 2018-10-18 19:22 UTC (permalink / raw) To: James Bottomley, ksummit-discuss; +Cc: linux-kernel 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 See you in Edinburgh, -Frank > > James > > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-18 19:22 ` Frank Rowand @ 2018-10-18 19:49 ` Tim.Bird 2018-10-18 19:57 ` James Bottomley 0 siblings, 1 reply; 18+ messages in thread From: Tim.Bird @ 2018-10-18 19:49 UTC (permalink / raw) To: frowand.list, James.Bottomley, ksummit-discuss; +Cc: linux-kernel > -----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: 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. 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. 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 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-18 19:49 ` Tim.Bird @ 2018-10-18 19:57 ` James Bottomley 2018-10-18 23:07 ` Frank Rowand 0 siblings, 1 reply; 18+ messages in thread From: James Bottomley @ 2018-10-18 19:57 UTC (permalink / raw) To: Tim.Bird, frowand.list, ksummit-discuss; +Cc: linux-kernel 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: > 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. > 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. 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-18 19:57 ` James Bottomley @ 2018-10-18 23:07 ` Frank Rowand 0 siblings, 0 replies; 18+ messages in thread From: Frank Rowand @ 2018-10-18 23:07 UTC (permalink / raw) To: James Bottomley, Tim.Bird, ksummit-discuss; +Cc: linux-kernel 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 > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-17 18:49 ` Frank Rowand 2018-10-17 19:07 ` Randy Dunlap 2018-10-17 19:08 ` James Bottomley @ 2018-10-17 19:26 ` Alexandre Belloni 2 siblings, 0 replies; 18+ messages in thread From: Alexandre Belloni @ 2018-10-17 19:26 UTC (permalink / raw) To: Frank Rowand; +Cc: James Bottomley, ksummit-discuss, linux-kernel Hello, On 17/10/2018 11:49:06-0700, Frank Rowand wrote: > 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). What about properly formatted patches (with From and SoB) sent to the maintainer, without copying any mailing lists? To me, a patch sent to a maintainer is obviously sent for inclusion in the kernel. > - (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. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses 2018-10-16 14:58 ` [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses James Bottomley 2018-10-17 2:10 ` [Ksummit-discuss] " Frank Rowand @ 2018-10-20 18:11 ` Michael Tirado 1 sibling, 0 replies; 18+ messages in thread From: Michael Tirado @ 2018-10-20 18:11 UTC (permalink / raw) To: James.Bottomley, LKML James, and our other friends, On Tue, Oct 16, 2018 at 2:59 PM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > The current code of conduct has an ambiguity More than one ambiguity. This whole file needs to go. >* Trolling, Who decides what is trolling, and what is a technique for raising awareness or sparking discussion on an issue? > * Other conduct which could reasonably be considered inappropriate in a > professional setting Why should this last bit remain? Any literate person with access to a dictionary should know how ambiguous the word professional is. As an amateur contributor to the FOSS ecosystem I am more than a bit offended by the decision to use such divisive, politically charged, and financially discriminatory language in a project of such massive technical importance. This entire file should be expunged from the repository and replaced by well defined minimalistic guidelines for maintaining order on the mailing lists, rather than a set of ambiguous codes that force maintainers to take politically motivated actions against contributors for undefined reasons. Using words like professional is a distressing red flag because it doesn't add any clarification on the issue (what was the issue again?), it only raises more questions. I can't think of any reason that word would be needed unless you're trying to push out unpaid contributors. Why should someones employment status be held against them when contributing ideas or code to a technical project that has benefited greatly from amateur contributions? I fear for the kernels future now that irrational politics are beginning to creep. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v3 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion 2018-10-16 14:57 [PATCH v3 0/3] code of conduct fixes James Bottomley 2018-10-16 14:58 ` [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses James Bottomley @ 2018-10-16 14:59 ` James Bottomley 2018-10-16 15:00 ` [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point James Bottomley 2 siblings, 0 replies; 18+ messages in thread From: James Bottomley @ 2018-10-16 14:59 UTC (permalink / raw) To: ksummit-discuss; +Cc: linux-kernel Significant concern has been expressed about the responsibilities outlined in the enforcement clause of the new code of conduct. Since there is concern that this becomes binding on the release of the 4.19 kernel, strip the enforcement clauses to give the community time to consider and debate how this should be handled. Note, this patch is expected to be the starting point for a discussion not the end point, so there is an expectation that an Enforcement section will be added again to our code of conduct once we have sufficient community consensus on what it should say. Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.") Acked-by: Shuah Khan <shuah@kernel.org> Acked-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Alan Cox <alan@llwyncelyn.cymru> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> --- v2: Added additional commit paragraph clarifying we do expect eventually to have an enforcement section (as requested by Shuah) --- Documentation/process/code-of-conduct.rst | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index aa40e34e7785..4dd90987305b 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. -Enforcement -=========== - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the Technical Advisory Board (TAB) at -<tab@lists.linux-foundation.org>. All complaints will be reviewed and -investigated and will result in a response that is deemed necessary and -appropriate to the circumstances. The TAB is obligated to maintain -confidentiality with regard to the reporter of an incident. Further details of -specific enforcement policies may be posted separately. - -Maintainers who do not follow or enforce the Code of Conduct in good faith may -face temporary or permanent repercussions as determined by other members of the -project’s leadership. - Attribution =========== -- 2.13.7 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point 2018-10-16 14:57 [PATCH v3 0/3] code of conduct fixes James Bottomley 2018-10-16 14:58 ` [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses James Bottomley 2018-10-16 14:59 ` [PATCH v3 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion James Bottomley @ 2018-10-16 15:00 ` James Bottomley 2018-10-17 15:32 ` [Ksummit-discuss] " Shuah Khan 2 siblings, 1 reply; 18+ messages in thread From: James Bottomley @ 2018-10-16 15:00 UTC (permalink / raw) To: ksummit-discuss; +Cc: linux-kernel Add a Reporting section where the Enforcement section used to be. The intention is still to debate what should go here, but in the meantime, this gives us back the central reporting point we had in the old code of conflict. Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> --- v2: Added this patch to allay concerns we were stripping the reporting mechanism entirely. v3: Add (where required by law) as a qualifier to the confidentiality requirement --- Documentation/process/code-of-conduct.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst index 4dd90987305b..eec768471a4d 100644 --- a/Documentation/process/code-of-conduct.rst +++ b/Documentation/process/code-of-conduct.rst @@ -59,6 +59,17 @@ address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. +Reporting +========= + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the Technical Advisory Board (TAB) at +<tab@lists.linux-foundation.org>. All complaints will be reviewed and +investigated and will result in a response that is deemed necessary and +appropriate to the circumstances. The TAB is obligated to maintain +confidentiality with regard to the reporter of an incident (except where +required by law). + Attribution =========== -- 2.13.7 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Ksummit-discuss] [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point 2018-10-16 15:00 ` [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 0 siblings, 0 replies; 18+ messages in thread From: Shuah Khan @ 2018-10-17 15:32 UTC (permalink / raw) To: James Bottomley, ksummit-discuss; +Cc: linux-kernel On 10/16/2018 09:00 AM, James Bottomley wrote: > Add a Reporting section where the Enforcement section used to be. The > intention is still to debate what should go here, but in the meantime, this > gives us back the central reporting point we had in the old code of conflict. > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> > Reviewed-by: Mauro Carvalho Chehab <mchehab@kernel.org> > Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > > --- > > v2: Added this patch to allay concerns we were stripping the reporting > mechanism entirely. > v3: Add (where required by law) as a qualifier to the confidentiality > requirement > --- > Documentation/process/code-of-conduct.rst | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst > index 4dd90987305b..eec768471a4d 100644 > --- a/Documentation/process/code-of-conduct.rst > +++ b/Documentation/process/code-of-conduct.rst > @@ -59,6 +59,17 @@ address, posting via an official social media account, or acting as an appointed > representative at an online or offline event. Representation of a project may be > further defined and clarified by project maintainers. > > +Reporting > +========= > + > +Instances of abusive, harassing, or otherwise unacceptable behavior may be > +reported by contacting the Technical Advisory Board (TAB) at > +<tab@lists.linux-foundation.org>. All complaints will be reviewed and > +investigated and will result in a response that is deemed necessary and > +appropriate to the circumstances. The TAB is obligated to maintain > +confidentiality with regard to the reporter of an incident (except where > +required by law). > + > Attribution > =========== > > Acked-by : Shuah Khan <shuah@kernel.org> thanks, -- Shuah ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2018-10-20 22:37 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-16 14:57 [PATCH v3 0/3] code of conduct fixes James Bottomley 2018-10-16 14:58 ` [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses James Bottomley 2018-10-17 2:10 ` [Ksummit-discuss] " 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 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-20 18:11 ` Michael Tirado 2018-10-16 14:59 ` [PATCH v3 2/3] code-of-conduct: Strip the enforcement paragraph pending community discussion James Bottomley 2018-10-16 15:00 ` [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point James Bottomley 2018-10-17 15:32 ` [Ksummit-discuss] " Shuah Khan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).