Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
On 10/18/18 12:57, James Bottomley wrote: > On Thu, 2018-10-18 at 19:49 +, tim.b...@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. Pe
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
On Thu, 2018-10-18 at 19:49 +, tim.b...@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
RE: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
> -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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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 > > > >
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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 Acked-by: Shuah Khan Acked-by: Guenter Roeck Reviewed-by: Alan Cox Reviewed-by: Mauro Carvalho Chehab Acked-by: "Eric W. Biederman" Acked-by: Kees Cook Signed-off-by: James Bottomley >>> 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 p
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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 >>> Acked-by: Shuah Khan >>> Acked-by: Guenter Roeck >>> Reviewed-by: Alan Cox >>> Reviewed-by: Mauro Carvalho Chehab >>> Acked-by: "Eric W. Biederman" >>> Acked-by: Kees Cook >>> Signed-off-by: James Bottomley >> 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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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 > > Acked-by: Shuah Khan > > Acked-by: Guenter Roeck > > Reviewed-by: Alan Cox > > Reviewed-by: Mauro Carvalho Chehab > > Acked-by: "Eric W. Biederman" > > Acked-by: Kees Cook > > Signed-off-by: James Bottomley > 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-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
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 > Acked-by: Shuah Khan > Acked-by: Guenter Roeck > Reviewed-by: Alan Cox > Reviewed-by: Mauro Carvalho Chehab > Acked-by: "Eric W. Biederman" > Acked-by: Kees Cook > Signed-off-by: James Bottomley > --- > 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