code of conduct fixes
Subsystems (3)
v3 cover code of conduct fixes
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(-)
Signature · 1 line
2.13.7
PATCH v3 1/3 code-of-conduct: Fix the ambiguity about collecting email addresses
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.
--- Documentation/process/code-of-conduct.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Documentation/process/code-of-conduct.rst +1 -1
@@ -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
Signature · 1 line
2.13.7
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Quoted 25 lines · James Bottomley
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 Shuah Khan <[email protected]>Acked-by Guenter Roeck <[email protected]>Reviewed-by Alan Cox <[email protected]>Reviewed-by Mauro Carvalho Chehab <[email protected]>Acked-by Kees Cook <[email protected]>Signed-off-by James Bottomley <[email protected]>--- Documentation/process/code-of-conduct.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Documentation/process/code-of-conduct.rst +0
-0
Documentation/process/code-of-conduct.rst Examples of unacceptable behavior by participants include: · line 37
Quoted 8 lines
Documentation/process/code-of-conduct.rst +1
-1@@ -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
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Quoted 55 lines · Frank Rowand
Quoted 38 lines · James Bottomley
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 Shuah Khan <[email protected]>Acked-by Guenter Roeck <[email protected]>Reviewed-by Alan Cox <[email protected]>Reviewed-by Mauro Carvalho Chehab <[email protected]>Acked-by Kees Cook <[email protected]>Signed-off-by James Bottomley <[email protected]om>
--- Documentation/process/code-of-conduct.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Documentation/process/code-of-conduct.rst +0
-0@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participantsinclude:
* Trolling, insulting/derogatory comments, and personal or
political attacks
* Public or private harassment
* Publishing others’ private information, such as a physical or
electronicDocumentation/process/code-of-conduct.rst +1
-1- address, without explicit permission + address not ordinarily collected by the project, withoutQuoted 6 lines
explicit permission
* Other conduct which could reasonably be considered inappropriate
in a
professional settingRepeating 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.
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 8 lines
My issue is with the word choice. I agree with the underlying concept.
-Frank
_______________________________________________
Ksummit-discuss mailing list
[email protected]
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
Quoted 39 lines · James Bottomley
Quoted 38 lines · Frank Rowand
Quoted 37 lines · James Bottomley
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 Shuah Khan <[email protected]>Acked-by Guenter Roeck <[email protected]>Reviewed-by Alan Cox <[email protected]>Reviewed-by Mauro Carvalho Chehab <[email protected]>Acked-by Kees Cook <[email protected]>Signed-off-by James Bottomley <[email protected]om>
--- Documentation/process/code-of-conduct.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Documentation/process/code-of-conduct.rst +0
-0@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participantsinclude:
* 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
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
+ 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.
Quoted 13 lines
Quoted 9 lines
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.
Quoted 3 lines
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".
Quoted 8 lines
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?
Quoted 8 lines
Quoted 2 lines
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
Quoted 13 lines
James
Quoted 8 lines
My issue is with the word choice. I agree with the underlying concept.
-Frank
_______________________________________________
Ksummit-discuss mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
Randy Dunlap
reviewerRe: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Quoted 134 lines · Frank Rowand
Quoted 39 lines · James Bottomley
Quoted 38 lines · Frank Rowand
Quoted 37 lines · James Bottomley
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 Shuah Khan <[email protected]>Acked-by Guenter Roeck <[email protected]>Reviewed-by Alan Cox <[email protected]>Reviewed-by Mauro Carvalho Chehab <[email protected]>Acked-by Kees Cook <[email protected]>Signed-off-by James Bottomley <[email protected]om>
--- Documentation/process/code-of-conduct.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Documentation/process/code-of-conduct.rst +0
-0@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participantsinclude:
* 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 permissionQuoted 8 lines
Quoted 8 lines
Quoted 7 lines
+ address not ordinarily collected by the project, without explicit permission
* Other conduct which could reasonably be considered inappropriate
in a
professional settingThere 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.
Quoted 13 lines
Quoted 9 lines
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.
Quoted 3 lines
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".
Quoted 8 lines
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
_ordinarilycollected_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?
Quoted 8 lines
Quoted 2 lines
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:
Quoted 8 lines
- 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.
Quoted 20 lines
- (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
Quoted 7 lines
James
Quoted 4 lines
My issue is with the word choice. I agree with the underlying concept.
-Frank
Signature · 1 line
~Randy
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
In reply to Frank RowandQuoted 2 lines · Frank Rowand
Quoted 1 line · James Bottomley
On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote:
[...]
Quoted 23 lines
Quoted 13 lines
Quoted 9 lines
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.
Quoted 3 lines
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".
Quoted 9 lines
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.
Quoted 6 lines
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.
Quoted 16 lines
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
_ordinarilycollected_by the company. I hope this provides some insight into what I am reading into "ordinarily collected by the project".
Quoted 6 lines
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.
Quoted 5 lines
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
Quoted 34 lines · James Bottomley
Quoted 2 lines · Frank Rowand
Quoted 1 line · James Bottomley
On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote:
[...]
Quoted 23 lines
Quoted 13 lines
Quoted 9 lines
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.
Quoted 3 lines
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".
Quoted 9 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
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.)
Quoted 30 lines
Quoted 16 lines
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
_ordinarilycollected_by the company. I hope this provides some insight into what I am reading into "ordinarily collected by the project".Quoted 6 lines
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.
Quoted 8 lines
Quoted 5 lines
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.
Quoted 2 lines
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
Quoted 3 lines
James
Re: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Quoted 1 line · Frank Rowand
On 10/17/18 12:08, James Bottomley wrote:
[...]
Quoted 16 lines
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines
Quoted 2 lines
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
Quoted 37 lines · James Bottomley
Quoted 1 line · Frank Rowand
On 10/17/18 12:08, James Bottomley wrote:
[...]
Quoted 16 lines
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines
Quoted 2 lines
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:
Review Examples of unacceptable behavior by participants include: · line 36
Quoted 7 lines
(quoted diff) +1
-1@@ -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
Quoted 6 lines
James
RE: [Ksummit-discuss] [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
Quoted 51 lines
-----Original Message-----
From: Frank RowandQuoted 24 lines · James Bottomley
Quoted 1 line · Frank Rowand
On 10/17/18 12:08, James Bottomley wrote:
[...]
Quoted 16 lines
Quoted 10 lines
Quoted 6 lines
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.
Quoted 4 lines
Quoted 2 lines
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".
Quoted 8 lines
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:
Review Examples of unacceptable behavior by participants
Quoted 1 line
(quoted diff) +0
-0@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participantsinclude:
Review Examples of unacceptable behavior by participants · line 31
Quoted 1 line
(quoted diff) +0
-0* Trolling, insulting/derogatory comments, and personal or politicalattacks
Review Examples of unacceptable behavior by participants · line 34
Quoted 4 lines
(quoted diff) +1
-1* 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 explicitpermission
Quoted 8 lines
Review Examples of unacceptable behavior by participants · line 36
Quoted 2 lines
(quoted diff) +0
-0* Other conduct which could reasonably be considered inappropriate in a professional settingAlternative (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
Quoted 87 lines · On Thu, 2018-10-18 at 19:49 +0000, [email protected] wrote:
Quoted 66 lines
-----Original Message-----
From: Frank RowandQuoted 40 lines · James Bottomley
Quoted 1 line · Frank Rowand
On 10/17/18 12:08, James Bottomley wrote:
[...]
Quoted 22 lines
Quoted 7 lines
Quoted 7 lines
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".Quoted 7 lines
Quoted 1 line
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 itNope. 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.Quoted 5 lines
Quoted 3 lines
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.Quoted 3 lines
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:
Review Examples of unacceptable behavior by
Quoted 1 line
(quoted diff) +0
-0@@ -31,7 +31,7 @@ Examples of unacceptable behavior byparticipants
include:Review Examples of unacceptable behavior by · line 31
Quoted 1 line
(quoted diff) +0
-0* Trolling, insulting/derogatory comments, and personal orpolitical
attacksReview Examples of unacceptable behavior by · line 33
Quoted 2 lines
(quoted diff) +0
-0* Public or private harassment * Publishing others’ private information, such as a physicalor electronic
Review Examples of unacceptable behavior by · line 34
Quoted 2 lines
(quoted diff) +1
-1- address, without explicit permission + address not ordinarily collected by the project, withoutexplicit
permissionReview Examples of unacceptable behavior by · line 35
Quoted 1 line
(quoted diff) +0
-0* Other conduct which could reasonably be consideredinappropriate in a
Quoted 8 lines
Review Examples of unacceptable behavior by · line 36
Quoted 1 line
(quoted diff) +0
-0professional settingAlternative (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.
----
Quoted 4 lines
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.
Quoted 16 lines
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.
Quoted 3 lines
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.
Quoted 5 lines
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
Quoted 13 lines
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
[email protected]
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
Quoted 89 lines · James Bottomley
Quoted 87 lines · On Thu, 2018-10-18 at 19:49 +0000, [email protected] wrote:
Quoted 66 lines
-----Original Message-----
From: Frank RowandQuoted 40 lines · James Bottomley
Quoted 1 line · Frank Rowand
On 10/17/18 12:08, James Bottomley wrote:
[...]
Quoted 22 lines
Quoted 7 lines
Quoted 7 lines
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".Quoted 7 lines
Quoted 1 line
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 itNope. 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.Quoted 5 lines
Quoted 3 lines
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.Quoted 3 lines
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:
Review Examples of unacceptable behavior by
Quoted 1 line
(quoted diff) +0
-0@@ -31,7 +31,7 @@ Examples of unacceptable behavior byparticipants
include:Review Examples of unacceptable behavior by · line 31
Quoted 1 line
(quoted diff) +0
-0* Trolling, insulting/derogatory comments, and personal orpolitical
attacksReview Examples of unacceptable behavior by · line 33
Quoted 2 lines
(quoted diff) +0
-0* Public or private harassment * Publishing others’ private information, such as a physicalor electronic
Review Examples of unacceptable behavior by · line 34
Quoted 2 lines
(quoted diff) +1
-1- address, without explicit permission + address not ordinarily collected by the project, withoutexplicit
permissionReview Examples of unacceptable behavior by · line 35
Quoted 1 line
(quoted diff) +0
-0* Other conduct which could reasonably be consideredinappropriate in a
Quoted 8 lines
Review Examples of unacceptable behavior by · line 36
Quoted 1 line
(quoted diff) +0
-0professional settingAlternative (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.
----
Quoted 1 line
Quoted 1 line
I think that in context, you want a 'not' in there. That is:
Yes, thank you.
Quoted 4 lines
Quoted 3 lines
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.
Quoted 8 lines
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. :-)
Quoted 29 lines
Quoted 16 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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:
Quoted 5 lines
Quoted 1 line
* 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
Quoted 19 lines
James
Quoted 13 lines
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
[email protected]
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
In reply to Frank RowandHello,
Quoted 7 lines · Frank Rowand
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:
Quoted 8 lines
- 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.
Quoted 10 lines
- (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.
Signature · 3 lines
Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v3 1/3] code-of-conduct: Fix the ambiguity about collecting email addresses
In reply to James BottomleyJames, and our other friends,
Quoted 2 lines · James Bottomley
The current code of conduct has an ambiguity
More than one ambiguity. This whole file needs to go.
Quoted 1 line
* Trolling,
Who decides what is trolling, and what is a technique for raising awareness or sparking discussion on an issue?
Quoted 2 lines
* 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.
PATCH v3 2/3 code-of-conduct: Strip the enforcement paragraph pending community discussion
In reply to James BottomleySignificant 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.
---
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(-)
Documentation/process/code-of-conduct.rst +0 -15
@@ -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 -<[email protected]>. 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 ===========
Signature · 1 line
2.13.7
PATCH v3 3/3 code-of-conduct: Add back the TAB as the central reporting point
In reply to James BottomleyAdd 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.
---
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(+)
Documentation/process/code-of-conduct.rst +11 -0
@@ -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 +<[email protected]>. 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 ===========
Signature · 1 line
2.13.7
Re: [Ksummit-discuss] [PATCH v3 3/3] code-of-conduct: Add back the TAB as the central reporting point
Quoted 32 lines · James Bottomley
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 <[email protected]>Reviewed-by Mauro Carvalho Chehab <[email protected]>Signed-off-by James Bottomley <[email protected]>---
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(+)Documentation/process/code-of-conduct.rst +4
-0@@ -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
Documentation/process/code-of-conduct.rst address, posting via an official social media account, or acting as an appointed · line 75
Quoted 10 lines
Documentation/process/code-of-conduct.rst +7
-0+reported by contacting the Technical Advisory Board (TAB) at +<[email protected]>. 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 ===========
thanks,
-- Shuah