Resend to modify the third patch to add (except where required by law)
and accumulate more tags
---
Previous cover letter:
Resend to show accumulated tags and also to add a third patch listing
the TAB as the reporting point as a few people seem to want. If it
gets the same level of support, I'll send it in with the other two.
---
Previous cover letter:
We've had several threads discussing potential changes to the code of
conduct but Mauro is the only person to have proposed an actual patch.
In order to move the debate on, I'm presenting two patches, one to fix
the email problem Mauro identified and the other to strip the
enforcement section pending community discussion as Shuah suggested.
I'll take responsibility for collecting any tags people want to add
(review/ack/sign off, etc) and sending the patch in as a signed pull
request before 4.19 final if they get enough community support.
Note, I've sent both patches in as a series to facilitate review and
discussion, but they are separable if one is looked on with less favour
than the other.
It was also a bit unclear which list to send this to, but I finally
settled on linux-kernel as the catch all and ksummit-discuss since
that's where most of the current discussion is. I can add other lists
as people suggest them.
James
---
James Bottomley (3):
code-of-conduct: Fix the ambiguity about collecting email addresses
code-of-conduct: Strip the enforcement paragraph pending community
discussion
code-of-conduct: Add back the TAB as the central reporting point
Documentation/process/code-of-conduct.rst | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
--
2.13.7
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 <[email protected]>
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: "Eric W. Biederman" <[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(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..aa40e34e7785 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others’ private information, such as a physical or electronic
- address, without explicit permission
+ address not ordinarily collected by the project, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
--
2.13.7
Significant concern has been expressed about the responsibilities outlined in
the enforcement clause of the new code of conduct. Since there is concern
that this becomes binding on the release of the 4.19 kernel, strip the
enforcement clauses to give the community time to consider and debate how this
should be handled.
Note, this patch is expected to be the starting point for a discussion not the
end point, so there is an expectation that an Enforcement section will be
added again to our code of conduct once we have sufficient community consensus
on what it should say.
Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
Acked-by: Shuah Khan <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Alan Cox <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
---
v2: Added additional commit paragraph clarifying we do expect eventually to
have an enforcement section (as requested by Shuah)
---
Documentation/process/code-of-conduct.rst | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index aa40e34e7785..4dd90987305b 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
-Enforcement
-===========
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the Technical Advisory Board (TAB) at
-<[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
===========
--
2.13.7
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]>
Acked-by: Geert Uytterhoeven <[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(+)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index 4dd90987305b..eec768471a4d 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,6 +59,17 @@ address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
+Reporting
+=========
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the Technical Advisory Board (TAB) at
+<[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
===========
--
2.13.7
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 <[email protected]>
> 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: "Eric W. Biederman" <[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(-)
>
> 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
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 <[email protected]>
> > 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: "Eric W. Biederman" <[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(-)
> >
> > 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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
On 10/16/2018 09:00 AM, James Bottomley wrote:
> Add a Reporting section where the Enforcement section used to be. The
> intention is still to debate what should go here, but in the meantime, this
> gives us back the central reporting point we had in the old code of conflict.
>
> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]>
> Reviewed-by: Mauro Carvalho Chehab <[email protected]>
> Acked-by: Geert Uytterhoeven <[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(+)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index 4dd90987305b..eec768471a4d 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,6 +59,17 @@ address, posting via an official social media account, or acting as an appointed
> representative at an online or offline event. Representation of a project may be
> further defined and clarified by project maintainers.
>
> +Reporting
> +=========
> +
> +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> +reported by contacting the Technical Advisory Board (TAB) at
> +<[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
> ===========
>
>
Acked-by : Shuah Khan <[email protected]>
thanks,
-- Shuah
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 <[email protected]>
>>> 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: "Eric W. Biederman" <[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(-)
>>>
>>> diff --git a/Documentation/process/code-of-conduct.rst
>>> b/Documentation/process/code-of-conduct.rst
>>> index ab7c24b5478c..aa40e34e7785 100644
>>> --- a/Documentation/process/code-of-conduct.rst
>>> +++ b/Documentation/process/code-of-conduct.rst
>>> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants
>>> include:
>>> * Trolling, insulting/derogatory comments, and personal or
>>> political attacks
>>> * Public or private harassment
>>> * Publishing others’ private information, such as a physical or
>>> electronic
>>> - address, without explicit permission
>>> + address not ordinarily collected by the project, without
>>> explicit permission
>>> * Other conduct which could reasonably be considered inappropriate
>>> in a
>>> professional setting
>>>
>>>
>>
There seems to be a disconnect between what I am trying to
communicate and what I perceive you to have understood.
I'll add comments below to try to make more clear what I'm trying to
say.
But first a general statement. I understand that the intent of the
patch wording is to allow use of email addresses in the tags of a patch
submittal or git commit without being an unacceptable behavior. I do
not think that the words in the patch accomplish that goal.
>> Repeating my comment on version 1:
>>
>> My understanding of the concern behind this change is that we should
>> be able to use an email address for the current development
>> practices, such as Reported-by, Suggested-by, etc tags when the email
>> address was provided in what is a public space for the project. The
>> public space is visible to anyone in the world who desires to access
>> it.
>>
>> I do not understand how "ordinarily collected by the project" is
>> equivalent to "an email address that was provided in a public space
>> for the project".
>
> I don't think it is ... or should be. This section is specifically
> enumerating unacceptable behaviours. The carve out "email address not
> ordinarily collected by the project" means that adding someone's email
> address in a tag isn't immediately sanctionable in the code of conduct
> as unacceptable behaviour if a question about whether you asked
> explicit permission arises. Equally, a carve out from unacceptable
> behaviours doesn't make the action always acceptable, so it's not a
> licence to publish someone's email address regardless of context.
The patch says "Publishing ... electronic address not ordinarily
collected by the project, without explicit permission". (I think it
is fair to abstract here with "...".) This phrase specifies which
email addresses can be published. It does not specify in what cases
the email address can be published. The desired goal is to be able to
publish email addresses in patch and commit tags.
Which email addresses are allowed to be published? (This is the point
of my original comment.) To me, the patch wording is describing how
I can determine whether I can put a specific email address in a tag
in a patch that I submit or commit. I can put an email address in a
tag _if_ it is "ordinarily collected by the project".
This then leads my mental process down the path of the disclosures (from
all of the companies that I do business with) that tell me what they
are going to do with my personal information, such as my address. (They
usually plan to share it with the world for their financial benefit.)
In that context, my personal information is not _public_, but it is
_ordinarily collected_ by the company. I hope this provides some
insight into what I am reading into "ordinarily collected by the project".
My original comment was trying to provide the concept behind a way to
create an alternate wording in the patch to define "which email
addresses".
Where are email addresses allowed to be published? I do not understand
the patch wording to address this at all.
Trying to understand how you are understanding my comment vs what I
intended to communicate, it seems to me that you are focused on the
"where allowed" and I am focused on the "which email addresses".
More clear? Or am I still not communicating well enough?
>> Ordinarily collected could include activities that can be expected to
>> be private and not visible to any arbitrary person in the world.
>
> It's not a blanket permission, it's an exclusion from being considered
> unacceptable behaviour. I would be interested to know what information
> we ordinarily collect in the course of building linux that should be
> considered private because I might have missed something about the
> implications here.
Permission vs exclusion is orthogonal to my comments.
"building linux" is not the patch wording. "ordinarily collected by the
project" is a much broader universe.
A very simplistic definition of public _could_ be:
- Visible on a project mail list that any one can subscribe to
- Visible on a project mail list whose archive is available via
the public internet
- Visible on an interactive communication ("chat") platform that
is open to the public internet
- Published on a web page intended for public access (for example
this could cover opt-in conference attendee lists and emails
that conference presenters voluntarily place in their slides).
- (I am guessing the above covers 97% or more of possible public
sources, but maybe there are some more common sources.)
I'm sure that the professionals that deal with information privacy
could provide better wording for the above list. I am but an
amateur in that field.
Anything else collected by the project would not be considered public.
For example, an email address provided in an email sent to me and not
copied to any mail list would not be public.
-Frank
>
> James
>
>> My issue is with the word choice. I agree with the underlying
>> concept.
>>
>> -Frank
>> _______________________________________________
>> Ksummit-discuss mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
>
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 <[email protected]>
>>>> 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: "Eric W. Biederman" <[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(-)
>>>>
>>>> diff --git a/Documentation/process/code-of-conduct.rst
>>>> b/Documentation/process/code-of-conduct.rst
>>>> index ab7c24b5478c..aa40e34e7785 100644
>>>> --- a/Documentation/process/code-of-conduct.rst
>>>> +++ b/Documentation/process/code-of-conduct.rst
>>>> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants
>>>> include:
>>>> * Trolling, insulting/derogatory comments, and personal or
>>>> political attacks
>>>> * Public or private harassment
>>>> * Publishing others’ private information, such as a physical or
>>>> electronic
>>>> - address, without explicit permission
>>>> + address not ordinarily collected by the project, without
>>>> explicit permission
>>>> * Other conduct which could reasonably be considered inappropriate
>>>> in a
>>>> professional setting
>>>>
>>>>
>>>
>
> There seems to be a disconnect between what I am trying to
> communicate and what I perceive you to have understood.
>
> I'll add comments below to try to make more clear what I'm trying to
> say.
>
> But first a general statement. I understand that the intent of the
> patch wording is to allow use of email addresses in the tags of a patch
> submittal or git commit without being an unacceptable behavior. I do
> not think that the words in the patch accomplish that goal.
>
>
>>> Repeating my comment on version 1:
>>>
>>> My understanding of the concern behind this change is that we should
>>> be able to use an email address for the current development
>>> practices, such as Reported-by, Suggested-by, etc tags when the email
>>> address was provided in what is a public space for the project. The
>>> public space is visible to anyone in the world who desires to access
>>> it.
>>>
>>> I do not understand how "ordinarily collected by the project" is
>>> equivalent to "an email address that was provided in a public space
>>> for the project".
>>
>> I don't think it is ... or should be. This section is specifically
>> enumerating unacceptable behaviours. The carve out "email address not
>> ordinarily collected by the project" means that adding someone's email
>> address in a tag isn't immediately sanctionable in the code of conduct
>> as unacceptable behaviour if a question about whether you asked
>> explicit permission arises. Equally, a carve out from unacceptable
>> behaviours doesn't make the action always acceptable, so it's not a
>> licence to publish someone's email address regardless of context.
>
> The patch says "Publishing ... electronic address not ordinarily
> collected by the project, without explicit permission". (I think it
> is fair to abstract here with "...".) This phrase specifies which
> email addresses can be published. It does not specify in what cases
> the email address can be published. The desired goal is to be able to
> publish email addresses in patch and commit tags.
>
> Which email addresses are allowed to be published? (This is the point
> of my original comment.) To me, the patch wording is describing how
> I can determine whether I can put a specific email address in a tag
> in a patch that I submit or commit. I can put an email address in a
> tag _if_ it is "ordinarily collected by the project".
>
> This then leads my mental process down the path of the disclosures (from
> all of the companies that I do business with) that tell me what they
> are going to do with my personal information, such as my address. (They
> usually plan to share it with the world for their financial benefit.)
> In that context, my personal information is not _public_, but it is
> _ordinarily collected_ by the company. I hope this provides some
> insight into what I am reading into "ordinarily collected by the project".
>
> My original comment was trying to provide the concept behind a way to
> create an alternate wording in the patch to define "which email
> addresses".
>
> Where are email addresses allowed to be published? I do not understand
> the patch wording to address this at all.
>
> Trying to understand how you are understanding my comment vs what I
> intended to communicate, it seems to me that you are focused on the
> "where allowed" and I am focused on the "which email addresses".
>
> More clear? Or am I still not communicating well enough?
>
>
>>> Ordinarily collected could include activities that can be expected to
>>> be private and not visible to any arbitrary person in the world.
>>
>> It's not a blanket permission, it's an exclusion from being considered
>> unacceptable behaviour. I would be interested to know what information
>> we ordinarily collect in the course of building linux that should be
>> considered private because I might have missed something about the
>> implications here.
>
> Permission vs exclusion is orthogonal to my comments.
>
> "building linux" is not the patch wording. "ordinarily collected by the
> project" is a much broader universe.
>
> A very simplistic definition of public _could_ be:
>
> - Visible on a project mail list that any one can subscribe to
> - Visible on a project mail list whose archive is available via
> the public internet
> - Visible on an interactive communication ("chat") platform that
> is open to the public internet
> - Published on a web page intended for public access (for example
> this could cover opt-in conference attendee lists and emails
> that conference presenters voluntarily place in their slides).
does that include bugzilla.kernel.org, or should we think of those email
addresses (of bug submitters) as private? They look public to me.
> - (I am guessing the above covers 97% or more of possible public
> sources, but maybe there are some more common sources.)
>
> I'm sure that the professionals that deal with information privacy
> could provide better wording for the above list. I am but an
> amateur in that field.
>
> Anything else collected by the project would not be considered public.
> For example, an email address provided in an email sent to me and not
> copied to any mail list would not be public.
>
> -Frank
>
>>
>> James
>>
>>> My issue is with the word choice. I agree with the underlying
>>> concept.
>>>
>>> -Frank
--
~Randy
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
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
On 10/17/18 12:08, James Bottomley wrote:
> On Wed, 2018-10-17 at 11:49 -0700, Frank Rowand wrote:
>> On 10/16/18 19:41, James Bottomley wrote:
>>> On Tue, 2018-10-16 at 19:10 -0700, Frank Rowand wrote:
> [...]
>>>> Repeating my comment on version 1:
>>>>
>>>> My understanding of the concern behind this change is that we
>>>> should be able to use an email address for the current
>>>> development practices, such as Reported-by, Suggested-by, etc
>>>> tags when the email address was provided in what is a public
>>>> space for the project. The public space is visible to anyone in
>>>> the world who desires to access it.
>>>>
>>>> I do not understand how "ordinarily collected by the project" is
>>>> equivalent to "an email address that was provided in a public
>>>> space for the project".
>>>
>>> I don't think it is ... or should be. This section is specifically
>>> enumerating unacceptable behaviours. The carve out "email address
>>> not ordinarily collected by the project" means that adding
>>> someone's email address in a tag isn't immediately sanctionable in
>>> the code of conduct as unacceptable behaviour if a question about
>>> whether you asked explicit permission arises. Equally, a carve out
>>> from unacceptable behaviours doesn't make the action always
>>> acceptable, so it's not a licence to publish someone's email
>>> address regardless of context.
>>
>> The patch says "Publishing ... electronic address not ordinarily
>> collected by the project, without explicit permission". (I think it
>> is fair to abstract here with "...".) This phrase specifies which
>> email addresses can be published. It does not specify in what cases
>> the email address can be published. The desired goal is to be able
>> to publish email addresses in patch and commit tags.
>
> No, that's not my desired goal. The section is not about giving
> permission it's about making sure listed unacceptable behaviours don't
> overlap what we normally do. The goal is to exclude email the project
> ordinarily collects from immediate sanction under the unacceptable
> behaviours clause. I deliberately didn't add anything about permission
> because that's up to the project to define in its more standard
> contribution documents.
OK. I am fine with the goal of wording that excludes certain things
from unacceptable behavior instead providing permissions for certain
things. I think me phrasing as permission instead of carve out is
creating a lot of the miscommunication.
Please re-read my comments, but in every place where I state things
in a way of providing permissions, re-state it in your mind as the
same sentence _except_ phrased as excluding from unacceptable
behavior. (I started to do that explicitly, but it looked like
I was just going to create a whole lot of distracting text.)
>> Which email addresses are allowed to be published? (This is the
>> point of my original comment.) To me, the patch wording is
>> describing how I can determine whether I can put a specific email
>> address in a tag in a patch that I submit or commit. I can put an
>> email address in a tag _if_ it is "ordinarily collected by the
>> project".
>>
>> This then leads my mental process down the path of the disclosures
>> (from all of the companies that I do business with) that tell me what
>> they are going to do with my personal information, such as my
>> address. (They usually plan to share it with the world for their
>> financial benefit.) In that context, my personal information is not
>> _public_, but it is _ordinarily collected_ by the company. I hope
>> this provides some insight into what I am reading into "ordinarily
>> collected by the project".
>>
>> My original comment was trying to provide the concept behind a way to
>> create an alternate wording in the patch to define "which email
>> addresses".
>>
>> Where are email addresses allowed to be published? I do not
>> understand the patch wording to address this at all.
>
> I agree, but, as I said, my goal wasn't to provide explicit permission
> (because the list is too long and too dependent on the way the project
> operates) it was to carve out an exclusion from sanction for stuff the
> kernel normally does. The carve out doesn't translate into explicit
> permission because the project can define other standards for the way
> email addresses are added to the tags.
>
>> Trying to understand how you are understanding my comment vs what I
>> intended to communicate, it seems to me that you are focused on the
>> "where allowed" and I am focused on the "which email addresses".
>>
>> More clear? Or am I still not communicating well enough?
>
> I think the crux of the disagreement is that you think the carve out
> equates to a permission which is not specific enough and I think it
Nope. That is a big place where I was not transferring my thoughts
to clear communication. I agree that what I wrote should have been
written in terms of carve out instead of permission.
> doesn't equate to a permission at all, which is why there's no need to
> make it more explicit. Is that a fair characterisation?
Nope. My concern is "which email addresses".
-Frank
> James
>
>
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
> -----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
On Thu, 2018-10-18 at 19:49 +0000, [email protected] wrote:
> > -----Original Message-----
> > From: Frank Rowand
> >
> > On 10/18/18 07:56, James Bottomley wrote:
> > > On Wed, 2018-10-17 at 12:53 -0700, Frank Rowand wrote:
> > > > On 10/17/18 12:08, James Bottomley wrote:
> > >
> > > [...]
> > > > > > Trying to understand how you are understanding my comment
> > > > > > vs what
> > > > > > I intended to communicate, it seems to me that you are
> > > > > > focused on
> > > > > > the "where allowed" and I am focused on the "which email
> > > > > > addresses".
> > > > > >
> > > > > > More clear? Or am I still not communicating well enough?
> > > > >
> > > > > I think the crux of the disagreement is that you think the
> > > > > carve
> > > > > out equates to a permission which is not specific enough and
> > > > > I
> > > > > think it
> > > >
> > > > Nope. That is a big place where I was not transferring my
> > > > thoughts
> > > > to clear communication. I agree that what I wrote should have
> > > > been
> > > > written in terms of carve out instead of permission.
> > > >
> > > >
> > > > > doesn't equate to a permission at all, which is why there's
> > > > > no need
> > > > > to make it more explicit. Is that a fair characterisation?
> > > >
> > > > Nope. My concern is "which email addresses".
> > >
> > > The idea here was because it's a carve out that doesn't give
> > > permission
> > > and because the permission is ruled by the project contribution
> > > documents, the carve out should be broad enough to cover anything
> > > they
> > > might say hence "email addresses not ordinarily collected by the
> > > project" are still included as unacceptable behaviour.
> > >
> > > Perhaps if you propose the wording you'd like to see it would
> > > help
> > > because there still looks to be some subtlety I'm not getting.
> >
> >
> > From the beginning of the thread:
> >
> > > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by
> > participants
> > include:
> > > * Trolling, insulting/derogatory comments, and personal or
> > political
> > attacks
> > > * Public or private harassment
> > > * Publishing others’ private information, such as a physical
> > or electronic
> > > - address, without explicit permission
> > > + address not ordinarily collected by the project, without
> > explicit
> > permission
> > > * Other conduct which could reasonably be considered
> > inappropriate in a
> > > professional setting
> >
> >
> > Alternative (and I'm sure someone else can probably clean this up a
> > little bit):
> >
> > + address that has been provided in a public space for the project,
> > without explicit permission
>
> This ends up reading like so:
>
> ----
> Examples of unacceptable behavior by participants include:
> ...
> * Publishing others’ private information, such as a physical or
> electronic
> address that has been provided in a public space for the project,
> without
> explicit permission.
> ----
>
> I think that in context, you want a 'not' in there. That is:
> unacceptable behavior includes publishing others' private
> information... that has *not* been provided in a public space. So, I
> think the suggested text needs some fixing, IMHO.
You beat me to this one. However, there is another issue that I did
touch on but perhaps not in this subthread: For those of us who live in
the US, our addresses (that's physical and sometimes email) are
actually provided in a public space because they're available in the
public property records. That's actually why I chose "not ordinarily
collected by the project" as opposed to "not previously provided in the
public space" or an equivalent because doxxing in the US is mostly
finding this information from public sources and broadcasting it.
> I looked at this issue upstream, and decided to leave the wording in
> the CoC itself alone - favoring instead to add a clarifying addition
> to the upstream CoC FAQ, about some email addresses not being
> private information.
>
> The reason I took that approach, rather than try to change the
> wording inside the CoC, is that the current wording seems to me to be
> sufficient. The thing that is unacceptable is publishing private
> information. The "such as..." clause is intended to convey examples
> of the types of thing that might usually be considered private
> information. But it is not exhaustive, nor is it necessarily
> correct, depending on the circumstances. In particular, email
> addresses are sometimes private information and sometimes not.
> In the context of kernel development, many email addresses are not
> private.
>
> I am sympathetic to the argument that we use emails as public
> information so much in kernel development processes, that it makes
> sense to omit this or qualify it more.
I think that's the sense of the people who acked this, yes. Personally
I'm happy with a separate clarification in another document, but I can
also see the argument that we do need our single CoC to be consistent
with our operational method, which is why I proposed the patch.
> My own views are that:
> 1) if we change this line at all, we should simply omit the "such
> as..." part of the phrase, and leave it at:
>
> * Publishing others’ private information without explicit permission
This looks OK to me too ... the problem with the original is that the
additional qualification overlaps our normal project method of
operation, this solves the issue as well.
James
> but also
> 2) I'm OK with leaving the phrase as is and handling the concerns
> in an clarifying document.
>
> Just my 2 cents.
> -- Tim
>
>
>
> _______________________________________________
> Ksummit-discuss mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
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
>
>
>
>
On 10/18/18 12:57, James Bottomley wrote:
> On Thu, 2018-10-18 at 19:49 +0000, [email protected] wrote:
>>> -----Original Message-----
>>> From: Frank Rowand
>>>
>>> On 10/18/18 07:56, James Bottomley wrote:
>>>> On Wed, 2018-10-17 at 12:53 -0700, Frank Rowand wrote:
>>>>> On 10/17/18 12:08, James Bottomley wrote:
>>>>
>>>> [...]
>>>>>>> Trying to understand how you are understanding my comment
>>>>>>> vs what
>>>>>>> I intended to communicate, it seems to me that you are
>>>>>>> focused on
>>>>>>> the "where allowed" and I am focused on the "which email
>>>>>>> addresses".
>>>>>>>
>>>>>>> More clear? Or am I still not communicating well enough?
>>>>>>
>>>>>> I think the crux of the disagreement is that you think the
>>>>>> carve
>>>>>> out equates to a permission which is not specific enough and
>>>>>> I
>>>>>> think it
>>>>>
>>>>> Nope. That is a big place where I was not transferring my
>>>>> thoughts
>>>>> to clear communication. I agree that what I wrote should have
>>>>> been
>>>>> written in terms of carve out instead of permission.
>>>>>
>>>>>
>>>>>> doesn't equate to a permission at all, which is why there's
>>>>>> no need
>>>>>> to make it more explicit. Is that a fair characterisation?
>>>>>
>>>>> Nope. My concern is "which email addresses".
>>>>
>>>> The idea here was because it's a carve out that doesn't give
>>>> permission
>>>> and because the permission is ruled by the project contribution
>>>> documents, the carve out should be broad enough to cover anything
>>>> they
>>>> might say hence "email addresses not ordinarily collected by the
>>>> project" are still included as unacceptable behaviour.
>>>>
>>>> Perhaps if you propose the wording you'd like to see it would
>>>> help
>>>> because there still looks to be some subtlety I'm not getting.
>>>
>>>
>>> From the beginning of the thread:
>>>
>>> > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by
>>> participants
>>> include:
>>> > * Trolling, insulting/derogatory comments, and personal or
>>> political
>>> attacks
>>> > * Public or private harassment
>>> > * Publishing others’ private information, such as a physical
>>> or electronic
>>> > - address, without explicit permission
>>> > + address not ordinarily collected by the project, without
>>> explicit
>>> permission
>>> > * Other conduct which could reasonably be considered
>>> inappropriate in a
>>> > professional setting
>>>
>>>
>>> Alternative (and I'm sure someone else can probably clean this up a
>>> little bit):
>>>
>>> + address that has been provided in a public space for the project,
>>> without explicit permission
>>
>> This ends up reading like so:
>>
>> ----
>> Examples of unacceptable behavior by participants include:
>> ...
>> * Publishing others’ private information, such as a physical or
>> electronic
>> address that has been provided in a public space for the project,
>> without
>> explicit permission.
>> ----
>>
>> I think that in context, you want a 'not' in there. That is:
Yes, thank you.
>> unacceptable behavior includes publishing others' private
>> information... that has *not* been provided in a public space. So, I
>> think the suggested text needs some fixing, IMHO.
>
> You beat me to this one. However, there is another issue that I did
> touch on but perhaps not in this subthread: For those of us who live in
> the US, our addresses (that's physical and sometimes email) are
> actually provided in a public space because they're available in the
> public property records. That's actually why I chose "not ordinarily
> collected by the project" as opposed to "not previously provided in the
> public space" or an equivalent because doxxing in the US is mostly
> finding this information from public sources and broadcasting it.
That clarification helps a _lot_ in understanding what you have said
previously in this thread. Thanks. :-)
>> I looked at this issue upstream, and decided to leave the wording in
>> the CoC itself alone - favoring instead to add a clarifying addition
>> to the upstream CoC FAQ, about some email addresses not being
>> private information.
>>
>> The reason I took that approach, rather than try to change the
>> wording inside the CoC, is that the current wording seems to me to be
>> sufficient. The thing that is unacceptable is publishing private
>> information. The "such as..." clause is intended to convey examples
>> of the types of thing that might usually be considered private
>> information. But it is not exhaustive, nor is it necessarily
>> correct, depending on the circumstances. In particular, email
>> addresses are sometimes private information and sometimes not.
>> In the context of kernel development, many email addresses are not
>> private.
>>
>> I am sympathetic to the argument that we use emails as public
>> information so much in kernel development processes, that it makes
>> sense to omit this or qualify it more.
>
> I think that's the sense of the people who acked this, yes. Personally
> I'm happy with a separate clarification in another document, but I can
> also see the argument that we do need our single CoC to be consistent
> with our operational method, which is why I proposed the patch.
>
>> My own views are that:
>> 1) if we change this line at all, we should simply omit the "such
>> as..." part of the phrase, and leave it at:
>>
>> * Publishing others’ private information without explicit permission
>
> This looks OK to me too ... the problem with the original is that the
> additional qualification overlaps our normal project method of
> operation, this solves the issue as well.
Looks good to me.
-Frank
>
> James
>
>
>> but also
>> 2) I'm OK with leaving the phrase as is and handling the concerns
>> in an clarifying document.
>>
>> Just my 2 cents.
>> -- Tim
>>
>>
>>
>> _______________________________________________
>> Ksummit-discuss mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
>
James, and our other friends,
On Tue, Oct 16, 2018 at 2:59 PM James Bottomley
<[email protected]> wrote:
>
> The current code of conduct has an ambiguity
More than one ambiguity. This whole file needs to go.
>* Trolling,
Who decides what is trolling, and what is a technique for raising
awareness or sparking discussion on an issue?
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
Why should this last bit remain? Any literate person with access to a
dictionary should know how ambiguous the word professional is. As an
amateur contributor to the FOSS ecosystem I am more than a bit
offended by the decision to use such divisive, politically charged,
and financially discriminatory language in a project of such massive
technical importance. This entire file should be expunged from the
repository and replaced by well defined minimalistic guidelines for
maintaining order on the mailing lists, rather than a set of ambiguous
codes that force maintainers to take politically motivated actions
against contributors for undefined reasons.
Using words like professional is a distressing red flag because it
doesn't add any clarification on the issue (what was the issue
again?), it only raises more questions. I can't think of any reason
that word would be needed unless you're trying to push out unpaid
contributors. Why should someones employment status be held against
them when contributing ideas or code to a technical project that has
benefited greatly from amateur contributions?
I fear for the kernels future now that irrational politics are
beginning to creep.