[PATCH 0/2] code of conduct fixes

[PATCH 0/2] code of conduct fixes

[James Bottomley]

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 (2):
  code-of-conduct: Fix the ambiguity about collecting email addresses
  code-of-conduct: Strip the enforcement paragraph pending community
    discussion

 Documentation/process/code-of-conduct.rst | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

[PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[James Bottomley]

From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: Sat, 6 Oct 2018 14:21:56 -0700
Subject: [PATCH 1/2] 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.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
 Documentation/process/code-of-conduct.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..aa40e34e7785 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
 * Trolling, insulting/derogatory comments, and personal or political attacks
 * Public or private harassment
 * Publishing others’ private information, such as a physical or electronic
-  address, without explicit permission
+  address not ordinarily collected by the project, without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
-- 
2.13.7

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Geert Uytterhoeven]

Hi James,

Thanks for your patch!

On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Sat, 6 Oct 2018 14:21:56 -0700
> Subject: [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email
>  addresses
>
> The current code of conduct has an ambiguity in the it considers publishing

that

> 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.
>
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

> --- 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

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Shuah Khan]

Hi James,

Thanks for the patch.

On 10/07/2018 02:25 AM, Geert Uytterhoeven wrote:
> Hi James,
> 
> Thanks for your patch!
> 
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
>> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
>> From: James Bottomley <James.Bottomley@HansenPartnership.com>
>> Date: Sat, 6 Oct 2018 14:21:56 -0700
>> Subject: [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email
>>  addresses
>>
>> The current code of conduct has an ambiguity in the it considers publishing
> 
> that
> 
>> 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.
>>
>> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> 
> Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")
> 
> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
> 

Acked-by: Shuah Khan <shuah@kernel.org>

>> --- 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
> 

thanks,
-- Shuah

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Daniel Vetter]

On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Sat, 6 Oct 2018 14:21:56 -0700
> Subject: [PATCH 1/2] 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.
>
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>  Documentation/process/code-of-conduct.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
>  * Trolling, insulting/derogatory comments, and personal or political attacks
>  * Public or private harassment
>  * Publishing others’ private information, such as a physical or electronic
> -  address, without explicit permission
> +  address not ordinarily collected by the project, without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting

We've discussed this a bit with freedesktop.org people a while ago,
both from a CoC and privacy regulations pov, and we concluded that
attaching random people's emails in Reported-by: and similar lines,
without their consent, is indeed a problem. Bugzilla is rather
problematic in this way, since it looks like it's protecting your
email address and keeping it private, but then you can still just grab
it from the bugzilla emails without first asking for permission.
That's one of the reasons why fd.o admins want to retire Bugzilla in
favour of gitlab issues (where this is handled a lot more strictly).

What we discussed in the older thread here on ksummit-discuss is
making it clear that email addresses sent to public mailing lists are
considered public information, which I think is worth clarifying. But
what you're excempting here is anything collected without permission
in the past, which I don't think is a good wording. I've definitely
been skimping on the rules here in the past. At least in my
understanding of the legal situation, if you get a bug report through
a private channel, or at least a channel that hides private address
information (like Bugzilla does, albeit sloppily), then you do have to
ask for explicit consent to publishing that information.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Hannes Reinecke]

On 10/7/18 11:04 AM, Daniel Vetter wrote:
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
>>
>> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
>> From: James Bottomley <James.Bottomley@HansenPartnership.com>
>> Date: Sat, 6 Oct 2018 14:21:56 -0700
>> Subject: [PATCH 1/2] 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.
>>
>> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
>> ---
>>  Documentation/process/code-of-conduct.rst | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
>> index ab7c24b5478c..aa40e34e7785 100644
>> --- a/Documentation/process/code-of-conduct.rst
>> +++ b/Documentation/process/code-of-conduct.rst
>> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
>>  * Trolling, insulting/derogatory comments, and personal or political attacks
>>  * Public or private harassment
>>  * Publishing others’ private information, such as a physical or electronic
>> -  address, without explicit permission
>> +  address not ordinarily collected by the project, without explicit permission
>>  * Other conduct which could reasonably be considered inappropriate in a
>>    professional setting
> 
> We've discussed this a bit with freedesktop.org people a while ago,
> both from a CoC and privacy regulations pov, and we concluded that
> attaching random people's emails in Reported-by: and similar lines,
> without their consent, is indeed a problem. Bugzilla is rather
> problematic in this way, since it looks like it's protecting your
> email address and keeping it private, but then you can still just grab
> it from the bugzilla emails without first asking for permission.
> That's one of the reasons why fd.o admins want to retire Bugzilla in
> favour of gitlab issues (where this is handled a lot more strictly).
> 
> What we discussed in the older thread here on ksummit-discuss is
> making it clear that email addresses sent to public mailing lists are
> considered public information, which I think is worth clarifying. But
> what you're excempting here is anything collected without permission
> in the past, which I don't think is a good wording. I've definitely
> been skimping on the rules here in the past. At least in my
> understanding of the legal situation, if you get a bug report through
> a private channel, or at least a channel that hides private address
> information (like Bugzilla does, albeit sloppily), then you do have to
> ask for explicit consent to publishing that information.

That is my interpretation, too.

And it even says so in Documentation/submitting-patches.rst, do I don't
we need to clarify it further.

Cheers,

Hannes

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[James Bottomley]

On Sun, 2018-10-07 at 11:04 +0200, Daniel Vetter wrote:
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00
> > 2001
> > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Date: Sat, 6 Oct 2018 14:21:56 -0700
> > Subject: [PATCH 1/2] 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.
> > 
> > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.c
> > om>
> > ---
> >  Documentation/process/code-of-conduct.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/process/code-of-conduct.rst
> > b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c..aa40e34e7785 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants
> > include:
> >  * Trolling, insulting/derogatory comments, and personal or
> > political attacks
> >  * Public or private harassment
> >  * Publishing others’ private information, such as a physical or
> > electronic
> > -  address, without explicit permission
> > +  address not ordinarily collected by the project, without
> > explicit permission
> >  * Other conduct which could reasonably be considered inappropriate
> > in a
> >    professional setting
> 
> We've discussed this a bit with freedesktop.org people a while ago,
> both from a CoC and privacy regulations pov, and we concluded that
> attaching random people's emails in Reported-by: and similar lines,
> without their consent, is indeed a problem. Bugzilla is rather
> problematic in this way, since it looks like it's protecting your
> email address and keeping it private, but then you can still just
> grab it from the bugzilla emails without first asking for permission.
> That's one of the reasons why fd.o admins want to retire Bugzilla in
> favour of gitlab issues (where this is handled a lot more strictly).

This is a code of conduct example of a violation.  While I agree we
should exercise sensitivity in reporter expectations I don't think a
maintainer getting it wrong should be equated to doxxing.

In many ways, this is why having examples sections in quasi legal
documents is a bad thing to do because it's arguable (as you have done)
that if some behaviour isn't explicitly mentioned in the unacceptable
examples it must be acceptable.

Look at it this way: if a maintainer screws up and adds a reported by
from someone who didn't expect their email to be published should that
be treated as an immediate code of conduct violation by whatever
enforcement process we come up with?  I think most maintainers would
answer "no" to this. 

> What we discussed in the older thread here on ksummit-discuss is
> making it clear that email addresses sent to public mailing lists are
> considered public information, which I think is worth clarifying. But
> what you're excempting here is anything collected without permission
> in the past, which I don't think is a good wording. I've definitely
> been skimping on the rules here in the past. At least in my
> understanding of the legal situation, if you get a bug report through
> a private channel, or at least a channel that hides private address
> information (like Bugzilla does, albeit sloppily), then you do have
> to ask for explicit consent to publishing that information.

I think that's not the way to look at what a code of conduct is.  The
examples need to be clear and they need to exclude any usual project
habits from the violations piece.  The nuances of when to get
permission for adding our usual tags should be covered in a separate
document (the submitting patches one).

James

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Mauro Carvalho Chehab]

Em Sun, 07 Oct 2018 08:29:01 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Sun, 2018-10-07 at 11:04 +0200, Daniel Vetter wrote:
> > On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:  
> > > 
> > > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00
> > > 2001
> > > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > Date: Sat, 6 Oct 2018 14:21:56 -0700
> > > Subject: [PATCH 1/2] 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.
> > > 
> > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.c  
> > > om>  
> > > ---
> > >  Documentation/process/code-of-conduct.rst | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/Documentation/process/code-of-conduct.rst
> > > b/Documentation/process/code-of-conduct.rst
> > > index ab7c24b5478c..aa40e34e7785 100644
> > > --- a/Documentation/process/code-of-conduct.rst
> > > +++ b/Documentation/process/code-of-conduct.rst
> > > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants
> > > include:
> > >  * Trolling, insulting/derogatory comments, and personal or
> > > political attacks
> > >  * Public or private harassment
> > >  * Publishing others’ private information, such as a physical or
> > > electronic
> > > -  address, without explicit permission
> > > +  address not ordinarily collected by the project, without
> > > explicit permission
> > >  * Other conduct which could reasonably be considered inappropriate
> > > in a
> > >    professional setting  
> > 
> > We've discussed this a bit with freedesktop.org people a while ago,
> > both from a CoC and privacy regulations pov, and we concluded that
> > attaching random people's emails in Reported-by: and similar lines,
> > without their consent, is indeed a problem. Bugzilla is rather
> > problematic in this way, since it looks like it's protecting your
> > email address and keeping it private, but then you can still just
> > grab it from the bugzilla emails without first asking for permission.
> > That's one of the reasons why fd.o admins want to retire Bugzilla in
> > favour of gitlab issues (where this is handled a lot more strictly).  
> 
> This is a code of conduct example of a violation.  While I agree we
> should exercise sensitivity in reporter expectations I don't think a
> maintainer getting it wrong should be equated to doxxing.
> 
> In many ways, this is why having examples sections in quasi legal
> documents is a bad thing to do because it's arguable (as you have done)
> that if some behaviour isn't explicitly mentioned in the unacceptable
> examples it must be acceptable.
> 
> Look at it this way: if a maintainer screws up and adds a reported by
> from someone who didn't expect their email to be published should that
> be treated as an immediate code of conduct violation by whatever
> enforcement process we come up with?  I think most maintainers would
> answer "no" to this. 

Agreed. 

I'd say more: what happens if someone adds a diff inside a bug
report? Not adding the author can be problematic too.

People should assume that, when reporting a bug, replying to
a patch, etc, his e-mail will be visible by people, and it can be
used when a fixup patch is produced. If someone doesn't want that,
it should *explicitly* say otherwise.

The text changes suggested by James reflects that: an e-mail sent in
private, with an explicit message saying to not use the personal
address is not an "electronic address not ordinarily collected by the
project".

Of course, it is up to the maintainer/developer that receives
such e-mails to either use its content, anonimizing the submitter
as requested (and eventually taking associated risks with regards
to GPL - if the email contains a patch) or to just ignore it.

Anyway, such "special cases" are the kind of thing that makes sense
on a FAQ, and not at the letter of the document itself.

Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Guenter Roeck]

On 10/06/2018 02:36 PM, James Bottomley wrote:
>  From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Sat, 6 Oct 2018 14:21:56 -0700
> Subject: [PATCH 1/2] 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.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

> ---
>   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
>   
> 

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Dave Airlie]

On Sun, 7 Oct 2018 at 07:36, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Sat, 6 Oct 2018 14:21:56 -0700
> Subject: [PATCH 1/2] 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.
>
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>  Documentation/process/code-of-conduct.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
>  * Trolling, insulting/derogatory comments, and personal or political attacks
>  * Public or private harassment
>  * Publishing others’ private information, such as a physical or electronic
> -  address, without explicit permission
> +  address not ordinarily collected by the project, without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting
>

I agree we want something like this, the question is whether we want
to change the CoC text from upstream, or clarify it in a separate
section.

This isn't a legally binding license or anything, but departing from
the upstream wording makes it tricker to merge new upstream versions
if they are considered appropriate.

Dave.

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Al Viro]

On Mon, Oct 08, 2018 at 08:25:35AM +1000, Dave Airlie wrote:

> This isn't a legally binding license or anything, but departing from
> the upstream wording makes it tricker to merge new upstream versions
> if they are considered appropriate.

Nicely done, that - gotta love the passive voice use.  Considered appropriate
*by* *whom*?

Anyway, upstream clearly is a poor fit for Linus kernel community structure
- the use of open lists, amount of subprojects, the length of transmission
chains into the mainline, total amount of contributors, amount of people
elsewhere in the project with occasional forays into any given area, etc.
And IIRC the CoC upstream's opinion was that it wouldn't fit.

We can surround it with "explanations" until we get something that more or
less fits, but then we'd need to reanalyse them every time an upstream
change gets merged.  And the lack of textual conflicts is not a good thing
in such situations, obviously.

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Al Viro]

On Sun, Oct 07, 2018 at 11:56:13PM +0100, Al Viro wrote:

> We can surround it with "explanations"

Sorry, "clarifications".  Or whatever euphemism you prefer for
exegesis, really...

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Dave Airlie]

On Mon, 8 Oct 2018 at 08:56, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, Oct 08, 2018 at 08:25:35AM +1000, Dave Airlie wrote:
>
> > This isn't a legally binding license or anything, but departing from
> > the upstream wording makes it tricker to merge new upstream versions
> > if they are considered appropriate.
>
> Nicely done, that - gotta love the passive voice use.  Considered appropriate
> *by* *whom*?

Good question, do we have a CoC maintainer? Is Linus it, Greg, TAB?

Maybe step one is to find the person who can make changes to the
kernel CoC (has anyone checked if Linus or Greg will merge this).

>
> Anyway, upstream clearly is a poor fit for Linus kernel community structure
> - the use of open lists, amount of subprojects, the length of transmission
> chains into the mainline, total amount of contributors, amount of people
> elsewhere in the project with occasional forays into any given area, etc.
> And IIRC the CoC upstream's opinion was that it wouldn't fit.

I think we can try, fixing upstream is a worthy goal for other
projects in the same position, rather than everyone diverging.
>
> We can surround it with "explanations" until we get something that more or
> less fits, but then we'd need to reanalyse them every time an upstream
> change gets merged.  And the lack of textual conflicts is not a good thing
> in such situations, obviously.

We do this already for the GPL (hence the GPLv2 only, and syscall exceptions).

Dave.

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 892 bytes --]

On Mon, Oct 08, 2018 at 09:37:59AM +1000, Dave Airlie wrote:
> On Mon, 8 Oct 2018 at 08:56, Al Viro <viro@zeniv.linux.org.uk> wrote:

> > We can surround it with "explanations" until we get something that more or
> > less fits, but then we'd need to reanalyse them every time an upstream
> > change gets merged.  And the lack of textual conflicts is not a good thing
> > in such situations, obviously.

> We do this already for the GPL (hence the GPLv2 only, and syscall exceptions).

That works reasonably well for licenses because people reading licenses
tend to do so in a rather detail oriented fashion so it's not that big
an obstacle to have something that's a bit harder to follow.  It's not
clear to me that the same thing is going to apply to people reading
codes of conduct, especially those looking for reassurance from them.
It might be OK but it's probably worth thinking about.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Mauro Carvalho Chehab]

Em Mon, 8 Oct 2018 09:37:59 +1000
Dave Airlie <airlied@gmail.com> escreveu:

> On Mon, 8 Oct 2018 at 08:56, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > On Mon, Oct 08, 2018 at 08:25:35AM +1000, Dave Airlie wrote:
> >  
> > > This isn't a legally binding license or anything, but departing from
> > > the upstream wording makes it tricker to merge new upstream versions
> > > if they are considered appropriate.  
> >
> > Nicely done, that - gotta love the passive voice use.  Considered appropriate
> > *by* *whom*?  
> 
> Good question, do we have a CoC maintainer? Is Linus it, Greg, TAB?
> 
> Maybe step one is to find the person who can make changes to the
> kernel CoC (has anyone checked if Linus or Greg will merge this).

If we add it to the MAINTAINERS file (with makes perfect sense to me),
I would like to have a R: entry there, in order to be notified when
people propose changes to it. My personal understanding is that it may 
have legal value under the legislation of the Country I live, and I'd
like to understand changes there that might affect my workflow.

Thanks,
Mauro

RE: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Luck, Tony]

On Mon, Oct 08, 2018 at 08:25:35AM +1000, Dave Airlie wrote:

> This isn't a legally binding license or anything, but departing from
> the upstream wording makes it tricker to merge new upstream versions
> if they are considered appropriate.

The whole document is under 500 words, if we can manage merges of tens
of thousands of lines of code, this should be pretty easy by comparison.

Making it difficult to merge new upstream versions could also be considered
a positive thing.  Given the outcry about this version appearing with no
community discussion, I think folks will also be unhappy about finding some
future merge that just says "Update CoC to upstream 1.5".

-Tony

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[James Bottomley]

On Mon, 2018-10-08 at 08:25 +1000, Dave Airlie wrote:
> On Sun, 7 Oct 2018 at 07:36, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 
> > From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00
> > 2001
> > From: James Bottomley <James.Bottomley@HansenPartnership.com>
> > Date: Sat, 6 Oct 2018 14:21:56 -0700
> > Subject: [PATCH 1/2] 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.
> > 
> > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.c
> > om>
> > ---
> >  Documentation/process/code-of-conduct.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/process/code-of-conduct.rst
> > b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c..aa40e34e7785 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants
> > include:
> >  * Trolling, insulting/derogatory comments, and personal or
> > political attacks
> >  * Public or private harassment
> >  * Publishing others’ private information, such as a physical or
> > electronic
> > -  address, without explicit permission
> > +  address not ordinarily collected by the project, without
> > explicit permission
> >  * Other conduct which could reasonably be considered inappropriate
> > in a professional setting
> > 
> 
> I agree we want something like this, the question is whether we want
> to change the CoC text from upstream, or clarify it in a separate
> section.

A Code of Conduct should be clear and not hedged around with footnotes
and interpretations in my opinion, which is why I offered the patch
like this.

> This isn't a legally binding license or anything, but departing from
> the upstream wording makes it tricker to merge new upstream versions
> if they are considered appropriate.

The way I look at this is that it's very much like a vendor driver. 
Some are mirror images of the source because we work closely with them;
others could be forks.  However, the process for vendor drivers is that
we make them work for us first and then see how the vendor wants to
handle it.

Once we agree the shape of what we need I promise to try to push it
back into the source ... is that good enough compromise?

James

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]


> > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> > ---
> >  Documentation/process/code-of-conduct.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c..aa40e34e7785 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
> >  * Trolling, insulting/derogatory comments, and personal or political attacks
> >  * Public or private harassment
> >  * Publishing others’ private information, such as a physical or electronic
> > -  address, without explicit permission
> > +  address not ordinarily collected by the project, without explicit permission
> >  * Other conduct which could reasonably be considered inappropriate in a
> >    professional setting
> >
> 
> I agree we want something like this, the question is whether we want
> to change the CoC text from upstream, or clarify it in a separate
> section.

If this comes from some kind of "upstream", that should be clearly
marked so in the document or at least in the git log. I was always
wondering who created that "useful document".

									Pavel
(And would still like to know what the background story is.)
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Josh Triplett]

On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.

Upstream has now adopted a FAQ, which addresses this and many other
questions. See https://www.contributor-covenant.org/faq .

Might I suggest adding that link to the bottom of the document, instead?
(And then, optionally, submitting entries for that FAQ.)

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[James Bottomley]

On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
> 
> Upstream has now adopted a FAQ, which addresses this and many other
> questions. See https://www.contributor-covenant.org/faq .
> 
> Might I suggest adding that link to the bottom of the document,
> instead? (And then, optionally, submitting entries for that FAQ.)

We can debate that as part of everything else, but my personal opinion
would be we should never point to an outside document under someone
else's control for guidance as to how our community would enforce its
own code of conduct.

James

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Mauro Carvalho Chehab]

Em Mon, 08 Oct 2018 08:30:20 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> > On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.  
> > 
> > Upstream has now adopted a FAQ, which addresses this and many other
> > questions. See https://www.contributor-covenant.org/faq .
> > 
> > Might I suggest adding that link to the bottom of the document,
> > instead? (And then, optionally, submitting entries for that FAQ.)  
> 
> We can debate that as part of everything else, but my personal opinion
> would be we should never point to an outside document under someone
> else's control for guidance as to how our community would enforce its
> own code of conduct.

Fully agreed on that. The same argument that we use for GPL 2 only
applies here: we should stick with an specific version of this it, in
a way that we won't be automatically bound to whatever new version
of it would say.

Btw, the term "social contract" is there at the FAQ. At least in
Brazil, as far as I can tell, there's no distinction of a "social
contract" and a "contract". From what I understand, both will have
equal legal value.

Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Josh Triplett]

On Mon, Oct 08, 2018 at 04:23:57PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Oct 2018 08:30:20 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
> > On Mon, 2018-10-08 at 08:20 -0700, Josh Triplett wrote:
> > > On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.  
> > > 
> > > Upstream has now adopted a FAQ, which addresses this and many other
> > > questions. See https://www.contributor-covenant.org/faq .
> > > 
> > > Might I suggest adding that link to the bottom of the document,
> > > instead? (And then, optionally, submitting entries for that FAQ.)  
> > 
> > We can debate that as part of everything else, but my personal opinion
> > would be we should never point to an outside document under someone
> > else's control for guidance as to how our community would enforce its
> > own code of conduct.
> 
> Fully agreed on that. The same argument that we use for GPL 2 only
> applies here: we should stick with an specific version of this it, in
> a way that we won't be automatically bound to whatever new version
> of it would say.

Linking to a FAQ with useful clarifications in it doesn't make those
"binding". This is *not* a legal agreement.

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Mon, Oct 08, 2018 at 12:57:51PM -0700, Josh Triplett wrote:
> On Mon, Oct 08, 2018 at 04:23:57PM -0300, Mauro Carvalho Chehab wrote:

> > Fully agreed on that. The same argument that we use for GPL 2 only
> > applies here: we should stick with an specific version of this it, in
> > a way that we won't be automatically bound to whatever new version
> > of it would say.

> Linking to a FAQ with useful clarifications in it doesn't make those
> "binding". This is *not* a legal agreement.

I don't think it's unreasonable for people to interpret the contributor
covenant in that sort of fashion - one of the consequences of the fact
that it does things people want like be explicit about exactly what
behaviours it's covering, specify consequences and so on is that it
looks a lot like how things that are intended to be some sort of legal
document look.  This is going to be especially true for non-native
speakers.  If it is causing problems that needs some clarification but
to be honest if people are erring on the side of taking the code of
conduct too seriously that doesn't seem like the worst thing ever.  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Rainer Fiebig]

Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
> 
> Upstream has now adopted a FAQ, which addresses this and many other
> questions. See https://www.contributor-covenant.org/faq .
> 
> Might I suggest adding that link to the bottom of the document, instead?
> (And then, optionally, submitting entries for that FAQ.)
> 

The Code of Conflict has 28 lines, including the heading. 
The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. Hm.

Here's a one-line Code of Conduct from Kant:
"Act only according to that maxim whereby you can, at the same time, will that it should become a universal law."[1]

Put another way: 
Don't do to others what you don't want others to do to you.

Simple beats complex. No FAQ necessary, imo.


Regards!


Rainer Fiebig


[1] https://en.wikipedia.org/wiki/Immanuel_Kant

-- 
The truth always turns out to be simpler than you thought.
Richard Feynman

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Josh Triplett]

On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> > On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
> > 
> > Upstream has now adopted a FAQ, which addresses this and many other
> > questions. See https://www.contributor-covenant.org/faq .
> > 
> > Might I suggest adding that link to the bottom of the document, instead?
> > (And then, optionally, submitting entries for that FAQ.)
> > 
> 
> The Code of Conflict has 28 lines, including the heading. 
> The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. Hm.

Yes, it turns out to be a more complicated problem than it was
previously oversimplified to. People don't automatically share a common
understanding.

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Laurent Pinchart]

Hi Josh,

On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> > Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> >> On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
> >> 
> >> Upstream has now adopted a FAQ, which addresses this and many other
> >> questions. See https://www.contributor-covenant.org/faq .
> >> 
> >> Might I suggest adding that link to the bottom of the document, instead?
> >> (And then, optionally, submitting entries for that FAQ.)
> > 
> > The Code of Conflict has 28 lines, including the heading.
> > The Code of Conduct has 81 lines, including the heading. And it needs a
> > FAQ. Hm.
> 
> Yes, it turns out to be a more complicated problem than it was
> previously oversimplified to. People don't automatically share a common
> understanding.

I see an elephant in the room in the fact that we have carefully avoided 
discussing whether people share a common goal here :-/

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[James Bottomley]

On Tue, 2018-10-09 at 22:38 +0300, Laurent Pinchart wrote:
> Hi Josh,
> 
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
> > On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
> > > Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
> > > > On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
> > > > 
> > > > Upstream has now adopted a FAQ, which addresses this and many
> > > > other questions. See https://www.contributor-covenant.org/faq .
> > > > 
> > > > Might I suggest adding that link to the bottom of the document,
> > > > instead? (And then, optionally, submitting entries for that
> > > > FAQ.)
> > > 
> > > The Code of Conflict has 28 lines, including the heading.
> > > The Code of Conduct has 81 lines, including the heading. And it
> > > needs a FAQ. Hm.
> > 
> > Yes, it turns out to be a more complicated problem than it was
> > previously oversimplified to. People don't automatically share a
> > common understanding.
> 
> I see an elephant in the room in the fact that we have carefully
> avoided  discussing whether people share a common goal here :-/

We don't need to share a common goal; we just need to find the
document useful on its merits.  That's why we're a mostly GPLv2
project without signing up to most of the FSF philosophy.  However,
that's also why we would keep our own interpretations, understandings
and clarifications in house, as it were.

James

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Rainer Fiebig]

James Bottomley schrieb:
> On Tue, 2018-10-09 at 22:38 +0300, Laurent Pinchart wrote:
>> Hi Josh,
>>
>> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
>>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
>>>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
>>>>>
>>>>> Upstream has now adopted a FAQ, which addresses this and many
>>>>> other questions. See https://www.contributor-covenant.org/faq .
>>>>>
>>>>> Might I suggest adding that link to the bottom of the document,
>>>>> instead? (And then, optionally, submitting entries for that
>>>>> FAQ.)
>>>>
>>>> The Code of Conflict has 28 lines, including the heading.
>>>> The Code of Conduct has 81 lines, including the heading. And it
>>>> needs a FAQ. Hm.
>>>
>>> Yes, it turns out to be a more complicated problem than it was
>>> previously oversimplified to. People don't automatically share a
>>> common understanding.
>>
>> I see an elephant in the room in the fact that we have carefully
>> avoided  discussing whether people share a common goal here :-/
> 
> We don't need to share a common goal; we just need to find the
It wouldn't hurt to have one and mention it either.

> document useful on its merits.  That's why we're a mostly GPLv2
> project without signing up to most of the FSF philosophy.  However,
> that's also why we would keep our own interpretations, understandings
> and clarifications in house, as it were.
> 
> James
> 
Sure.


So long!

Rainer Fiebig

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Rainer Fiebig]

Laurent Pinchart schrieb:
> Hi Josh,
> 
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
>>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
>>>>
>>>> Upstream has now adopted a FAQ, which addresses this and many other
>>>> questions. See https://www.contributor-covenant.org/faq .
>>>>
>>>> Might I suggest adding that link to the bottom of the document, instead?
>>>> (And then, optionally, submitting entries for that FAQ.)
>>>
>>> The Code of Conflict has 28 lines, including the heading.
>>> The Code of Conduct has 81 lines, including the heading. And it needs a
>>> FAQ. Hm.
>>
>> Yes, it turns out to be a more complicated problem than it was
>> previously oversimplified to. People don't automatically share a common
>> understanding.
> 
> I see an elephant in the room in the fact that we have carefully avoided 
> discussing whether people share a common goal here :-/
> 
I've been thinking about this a bit lately. Maybe it might be good to explicitly mention that common
goal in a sort of a preamble. Here are the first few lines of what came to my mind:


Code of Conduct
+++++++++++++++

The goal of the Linux kernel development process is to maintain and advance
the most robust operating system kernel ever.

Needless to say, views on how to achieve this will differ at times.

In order to keep arguments civilized and to ensure an open, positive
and constructive environment, we have setup guidelines
that participants are expected to comply with:

No bias
=======

Nobody must be discriminated or favored due to personal traits like
- for example - age, gender or ethnicity. They are irrelevant.
What counts is whether the contribution is in line with a/m goal.
Any such contribution will be carefully reviewed.

Be excellent to each other
==========================
[...]


So long!

Rainer Fiebig

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Rainer Fiebig]

Josh Triplett schrieb:
> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
>>> On Sat, Oct 06, 2018 at 02:36:39PM -0700, 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.
>>>
>>> Upstream has now adopted a FAQ, which addresses this and many other
>>> questions. See https://www.contributor-covenant.org/faq .
>>>
>>> Might I suggest adding that link to the bottom of the document, instead?
>>> (And then, optionally, submitting entries for that FAQ.)
>>>
>>
>> The Code of Conflict has 28 lines, including the heading. 
>> The Code of Conduct has 81 lines, including the heading. And it needs a FAQ. Hm.
> 

> Yes, it turns out to be a more complicated problem than it was
> previously oversimplified to. People don't automatically share a common
> understanding.
> 

I don't know what that complicated problem was. The commit message is a bit vaque in that respect.
But I bet that in the end it *was* simple. And it probably wasn't that people felt discriminated
because of their "body size".

I also think that people actually do share a common understanding. Otherwise *no* CoC would work -
however explicit it would be. We're not that different after all.

A CoC that needs a FAQ to be understood may create more problems that it solves.

So long!


Rainer Fiebig

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Mauro Carvalho Chehab]

Em Sat, 06 Oct 2018 14:36:39 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Sat, 6 Oct 2018 14:21:56 -0700
> Subject: [PATCH 1/2] 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.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>  Documentation/process/code-of-conduct.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
>  * Trolling, insulting/derogatory comments, and personal or political attacks
>  * Public or private harassment
>  * Publishing others’ private information, such as a physical or electronic
> -  address, without explicit permission
> +  address not ordinarily collected by the project, without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting
>  

Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Frank Rowand]

On 10/06/18 14:36, James Bottomley wrote:
> From 4a614e9440148894207bef5bf69e74071baceb3b Mon Sep 17 00:00:00 2001
> From: James Bottomley <James.Bottomley@HansenPartnership.com>
> Date: Sat, 6 Oct 2018 14:21:56 -0700
> Subject: [PATCH 1/2] 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.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>  Documentation/process/code-of-conduct.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa40e34e7785 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,7 +31,7 @@ Examples of unacceptable behavior by participants include:
>  * Trolling, insulting/derogatory comments, and personal or political attacks
>  * Public or private harassment
>  * Publishing others’ private information, such as a physical or electronic
> -  address, without explicit permission
> +  address not ordinarily collected by the project, without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting


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

[PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[James Bottomley]

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.

Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
---
 Documentation/process/code-of-conduct.rst | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index aa40e34e7785..4dd90987305b 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
 representative at an online or offline event. Representation of a project may be
 further defined and clarified by project maintainers.
 
-Enforcement
-===========
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the Technical Advisory Board (TAB) at
-<tab@lists.linux-foundation.org>. All complaints will be reviewed and
-investigated and will result in a response that is deemed necessary and
-appropriate to the circumstances. The TAB is obligated to maintain
-confidentiality with regard to the reporter of an incident.  Further details of
-specific enforcement policies may be posted separately.
-
-Maintainers who do not follow or enforce the Code of Conduct in good faith may
-face temporary or permanent repercussions as determined by other members of the
-project’s leadership.
-
 Attribution
 ===========
 
-- 
2.13.7

RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Tim.Bird]

> -----Original Message-----
> From: James Bottomley
> 
> 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.
> 
> Signed-off-by: James Bottomley
> <James.Bottomley@HansenPartnership.com>
> ---
>  Documentation/process/code-of-conduct.rst | 15 ---------------
>  1 file changed, 15 deletions(-)
> 
> diff --git a/Documentation/process/code-of-conduct.rst
> b/Documentation/process/code-of-conduct.rst
> index aa40e34e7785..4dd90987305b 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,21 +59,6 @@ address, posting via an official social media account, or
> acting as an appointed
>  representative at an online or offline event. Representation of a project may
> be
>  further defined and clarified by project maintainers.
> 
> -Enforcement
> -===========
> -
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> -reported by contacting the Technical Advisory Board (TAB) at
> -<tab@lists.linux-foundation.org>. All complaints will be reviewed and
> -investigated and will result in a response that is deemed necessary and
> -appropriate to the circumstances. The TAB is obligated to maintain
> -confidentiality with regard to the reporter of an incident.  Further details of
> -specific enforcement policies may be posted separately.

I think it's OK to leave the above section, as it doesn't speak to
enforcement, but rather is just a set of reporting instructions,
with an assurance of confidentiality.  This seems to me not to be
the objectionable part of this section.
(IOW, I would omit this removal from the patch).

If the next part is indeed removed, then maybe the section
needs to be renamed?
 -- Tim

> -
> -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
>  ===========

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[James Bottomley]

On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > -----Original Message-----
> > From: James Bottomley
> > 
> > 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.
> > 
> > Signed-off-by: James Bottomley
> > <James.Bottomley@HansenPartnership.com>
> > ---
> >  Documentation/process/code-of-conduct.rst | 15 ---------------
> >  1 file changed, 15 deletions(-)
> > 
> > diff --git a/Documentation/process/code-of-conduct.rst
> > b/Documentation/process/code-of-conduct.rst
> > index aa40e34e7785..4dd90987305b 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -59,21 +59,6 @@ address, posting via an official social media
> > account, or
> > acting as an appointed
> >  representative at an online or offline event. Representation of a
> > project may
> > be
> >  further defined and clarified by project maintainers.
> > 
> > -Enforcement
> > -===========
> > -
> > -Instances of abusive, harassing, or otherwise unacceptable
> > behavior may be
> > -reported by contacting the Technical Advisory Board (TAB) at
> > -<tab@lists.linux-foundation.org>. All complaints will be reviewed
> > and
> > -investigated and will result in a response that is deemed
> > necessary and
> > -appropriate to the circumstances. The TAB is obligated to maintain
> > -confidentiality with regard to the reporter of an
> > incident.  Further details of
> > -specific enforcement policies may be posted separately.
> 
> I think it's OK to leave the above section, as it doesn't speak to
> enforcement, but rather is just a set of reporting instructions,
> with an assurance of confidentiality.  This seems to me not to be
> the objectionable part of this section.
> (IOW, I would omit this removal from the patch).

So I did think about that, but it struck me that with both paragraphs
removed, the current CoC is very similar to the status quo: namely
every subsystem handles their own issues and that's formalised by the
"Our Responsibilities" section.  That also makes me think that whether
we want a centralised channel of reporting or enforcement and what it
should be also ought to be part of the debate.  The TAB was created to
channel community technical input into the Linux Foundation.  That's
not to say it can't provide the reporting and arbitration structure,
but if we're going to do it right we should debate the expansion of its
duties (and powers).

I happen to think that the fact that the TAB cannot compel where it
cannot persuade is a huge strength of the system because it means
there's no power structure to subvert if someone were interested in
using it to try to impose their own viewpoint on the community.  But
that's just my opinion and I did write the TAB charter, so I'm probably
biased in this viewpoint.

James


> If the next part is indeed removed, then maybe the section
> needs to be renamed?
>  -- Tim
> 
> > -
> > -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
> >  ===========
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Tim.Bird]

> -----Original Message-----
> From: James Bottomley 
> On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > > -----Original Message-----
> > > From: James Bottomley
> > >
> > > 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.
> > >
> > > Signed-off-by: James Bottomley
> > > <James.Bottomley@HansenPartnership.com>
> > > ---
> > >  Documentation/process/code-of-conduct.rst | 15 ---------------
> > >  1 file changed, 15 deletions(-)
> > >
> > > diff --git a/Documentation/process/code-of-conduct.rst
> > > b/Documentation/process/code-of-conduct.rst
> > > index aa40e34e7785..4dd90987305b 100644
> > > --- a/Documentation/process/code-of-conduct.rst
> > > +++ b/Documentation/process/code-of-conduct.rst
> > > @@ -59,21 +59,6 @@ address, posting via an official social media
> > > account, or
> > > acting as an appointed
> > >  representative at an online or offline event. Representation of a
> > > project may
> > > be
> > >  further defined and clarified by project maintainers.
> > >
> > > -Enforcement
> > > -===========
> > > -
> > > -Instances of abusive, harassing, or otherwise unacceptable
> > > behavior may be
> > > -reported by contacting the Technical Advisory Board (TAB) at
> > > -<tab@lists.linux-foundation.org>. All complaints will be reviewed
> > > and
> > > -investigated and will result in a response that is deemed
> > > necessary and
> > > -appropriate to the circumstances. The TAB is obligated to maintain
> > > -confidentiality with regard to the reporter of an
> > > incident.  Further details of
> > > -specific enforcement policies may be posted separately.
> >
> > I think it's OK to leave the above section, as it doesn't speak to
> > enforcement, but rather is just a set of reporting instructions,
> > with an assurance of confidentiality.  This seems to me not to be
> > the objectionable part of this section.
> > (IOW, I would omit this removal from the patch).
> 
> So I did think about that, but it struck me that with both paragraphs
> removed, the current CoC is very similar to the status quo: namely
> every subsystem handles their own issues and that's formalised by the
> "Our Responsibilities" section.  That also makes me think that whether
> we want a centralised channel of reporting or enforcement and what it
> should be also ought to be part of the debate.  The TAB was created to
> channel community technical input into the Linux Foundation.  That's
> not to say it can't provide the reporting and arbitration structure,
> but if we're going to do it right we should debate the expansion of its
> duties (and powers).

When the Code of Conflict was adopted 3 years ago, we already created
the central reporting mechanism, so I actually think leaving (ie including) the above
paragraph is closer to the status quo.  I think it's the expanded powers and
duties (or perception thereof) that are causing concern and I think debating
those to clarify intent, and adopting changes as needed  to ameliorate concerns
is worthwhile.

I believe that in the vast majority of cases, the TAB will end up
performing a mediator role to smooth hurt feelings and remind and encourage
improved communication - very similar to what we've done in the past.  I really
believe that bans will continue to be very few and far between, as they have
been historically (I can only think of 3 in the past decade.)
 -- Tim

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[James Bottomley]

On Mon, 2018-10-08 at 13:51 +0000, Tim.Bird@sony.com wrote:
> > -----Original Message-----
> > From: James Bottomley 
> > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > > > -----Original Message-----
> > > > From: James Bottomley
> > > > 
> > > > 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.
> > > > 
> > > > Signed-off-by: James Bottomley
> > > > <James.Bottomley@HansenPartnership.com>
> > > > ---
> > > >  Documentation/process/code-of-conduct.rst | 15 ---------------
> > > >  1 file changed, 15 deletions(-)
> > > > 
> > > > diff --git a/Documentation/process/code-of-conduct.rst
> > > > b/Documentation/process/code-of-conduct.rst
> > > > index aa40e34e7785..4dd90987305b 100644
> > > > --- a/Documentation/process/code-of-conduct.rst
> > > > +++ b/Documentation/process/code-of-conduct.rst
> > > > @@ -59,21 +59,6 @@ address, posting via an official social
> > > > media account, or acting as an appointed representative at an
> > > > online or offline event. Representation of a project may be
> > > >  further defined and clarified by project maintainers.
> > > > 
> > > > -Enforcement
> > > > -===========
> > > > -
> > > > -Instances of abusive, harassing, or otherwise unacceptable
> > > > behavior may be
> > > > -reported by contacting the Technical Advisory Board (TAB) at
> > > > -<tab@lists.linux-foundation.org>. All complaints will be
> > > > reviewed and
> > > > -investigated and will result in a response that is deemed
> > > > necessary and
> > > > -appropriate to the circumstances. The TAB is obligated to
> > > > maintain
> > > > -confidentiality with regard to the reporter of an
> > > > incident.  Further details of
> > > > -specific enforcement policies may be posted separately.
> > > 
> > > I think it's OK to leave the above section, as it doesn't speak
> > > to enforcement, but rather is just a set of reporting
> > > instructions, with an assurance of confidentiality.  This seems
> > > to me not to be the objectionable part of this section.
> > > (IOW, I would omit this removal from the patch).
> > 
> > So I did think about that, but it struck me that with both
> > paragraphs removed, the current CoC is very similar to the status
> > quo: namely every subsystem handles their own issues and that's
> > formalised by the "Our Responsibilities" section.  That also makes
> > me think that whether we want a centralised channel of reporting or
> > enforcement and what it should be also ought to be part of the
> > debate.  The TAB was created to channel community technical input
> > into the Linux Foundation.  That's not to say it can't provide the
> > reporting and arbitration structure, but if we're going to do it
> > right we should debate the expansion of its duties (and powers).
> 
> When the Code of Conflict was adopted 3 years ago, we already created
> the central reporting mechanism, so I actually think leaving (ie
> including) the above paragraph is closer to the status quo.  I think
> it's the expanded powers and duties (or perception thereof) that are
> causing concern and I think debating those to clarify intent, and
> adopting changes as needed  to ameliorate concerns is worthwhile.

If we want to go back to the status quo, then a plain revert is the
patch series I should submit.

> I believe that in the vast majority of cases, the TAB will end up
> performing a mediator role to smooth hurt feelings and remind and
> encourage improved communication - very similar to what we've done in
> the past.  I really believe that bans will continue to be very few
> and far between, as they have been historically (I can only think of
> 3 in the past decade.)

That might very well be the position the discussion arrives at;
however, I really think making the process fully transparent this time
requires not prejudging the outcome.

James

RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Tim.Bird]

> -----Original Message-----
> From: James Bottomley
> 
> On Mon, 2018-10-08 at 13:51 +0000, Tim.Bird@sony.com wrote:
> > > -----Original Message-----
> > > From: James Bottomley
> > > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > > > > -----Original Message-----
> > > > > From: James Bottomley
> > > > >
> > > > > 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.
> > > > >
> > > > > Signed-off-by: James Bottomley
> > > > > <James.Bottomley@HansenPartnership.com>
> > > > > ---
> > > > >  Documentation/process/code-of-conduct.rst | 15 ---------------
> > > > >  1 file changed, 15 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/process/code-of-conduct.rst
> > > > > b/Documentation/process/code-of-conduct.rst
> > > > > index aa40e34e7785..4dd90987305b 100644
> > > > > --- a/Documentation/process/code-of-conduct.rst
> > > > > +++ b/Documentation/process/code-of-conduct.rst
> > > > > @@ -59,21 +59,6 @@ address, posting via an official social
> > > > > media account, or acting as an appointed representative at an
> > > > > online or offline event. Representation of a project may be
> > > > >  further defined and clarified by project maintainers.
> > > > >
> > > > > -Enforcement
> > > > > -===========
> > > > > -
> > > > > -Instances of abusive, harassing, or otherwise unacceptable
> > > > > behavior may be
> > > > > -reported by contacting the Technical Advisory Board (TAB) at
> > > > > -<tab@lists.linux-foundation.org>. All complaints will be
> > > > > reviewed and
> > > > > -investigated and will result in a response that is deemed
> > > > > necessary and
> > > > > -appropriate to the circumstances. The TAB is obligated to
> > > > > maintain
> > > > > -confidentiality with regard to the reporter of an
> > > > > incident.  Further details of
> > > > > -specific enforcement policies may be posted separately.
> > > >
> > > > I think it's OK to leave the above section, as it doesn't speak
> > > > to enforcement, but rather is just a set of reporting
> > > > instructions, with an assurance of confidentiality.  This seems
> > > > to me not to be the objectionable part of this section.
> > > > (IOW, I would omit this removal from the patch).
> > >
> > > So I did think about that, but it struck me that with both
> > > paragraphs removed, the current CoC is very similar to the status
> > > quo: namely every subsystem handles their own issues and that's
> > > formalised by the "Our Responsibilities" section.  That also makes
> > > me think that whether we want a centralised channel of reporting or
> > > enforcement and what it should be also ought to be part of the
> > > debate.  The TAB was created to channel community technical input
> > > into the Linux Foundation.  That's not to say it can't provide the
> > > reporting and arbitration structure, but if we're going to do it
> > > right we should debate the expansion of its duties (and powers).
> >
> > When the Code of Conflict was adopted 3 years ago, we already created
> > the central reporting mechanism, so I actually think leaving (ie
> > including) the above paragraph is closer to the status quo.  I think
> > it's the expanded powers and duties (or perception thereof) that are
> > causing concern and I think debating those to clarify intent, and
> > adopting changes as needed  to ameliorate concerns is worthwhile.
> 
> If we want to go back to the status quo, then a plain revert is the
> patch series I should submit.

Let me try to be more clear.  I don't want to go back to the status quo.
I was saying that if we keep this document, but omit the central
reporting mechanism, that is a large departure from the status quo,
because the Code of Conflict already established that.  And I think
that having an ombudsman-type role somewhere in the community
is beneficial.

I believe parts of the Code of Conduct are an improvement over the
Code of Conflict, so my personal preference would be to keep it
and try to adjust it moving forward.  I think your patches, with clear
suggestions for improvements (or for deletions in the case where we
want more debate on particular sections before adopting them) is
a good approach, and I like that process as opposed to starting over
from scratch.

> 
> > I believe that in the vast majority of cases, the TAB will end up
> > performing a mediator role to smooth hurt feelings and remind and
> > encourage improved communication - very similar to what we've done in
> > the past.  I really believe that bans will continue to be very few
> > and far between, as they have been historically (I can only think of
> > 3 in the past decade.)
> 
> That might very well be the position the discussion arrives at;
> however, I really think making the process fully transparent this time
> requires not prejudging the outcome.
I don't understand your point here.  Can you elaborate?

Thanks,
 -- Tim

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[James Bottomley]

On Mon, 2018-10-08 at 17:58 +0000, Tim.Bird@sony.com wrote:
> > -----Original Message-----
> > From: James Bottomley
> > 
> > On Mon, 2018-10-08 at 13:51 +0000, Tim.Bird@sony.com wrote:
> > > > -----Original Message-----
> > > > From: James Bottomley
> > > > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > > > > > -----Original Message-----
> > > > > > From: James Bottomley
> > > > > > 
> > > > > > 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.
> > > > > > 
> > > > > > Signed-off-by: James Bottomley
> > > > > > <James.Bottomley@HansenPartnership.com>
> > > > > > ---
> > > > > >  Documentation/process/code-of-conduct.rst | 15 ---------
> > > > > > ------
> > > > > >  1 file changed, 15 deletions(-)
> > > > > > 
> > > > > > diff --git a/Documentation/process/code-of-conduct.rst
> > > > > > b/Documentation/process/code-of-conduct.rst
> > > > > > index aa40e34e7785..4dd90987305b 100644
> > > > > > --- a/Documentation/process/code-of-conduct.rst
> > > > > > +++ b/Documentation/process/code-of-conduct.rst
> > > > > > @@ -59,21 +59,6 @@ address, posting via an official social
> > > > > > media account, or acting as an appointed representative at
> > > > > > an
> > > > > > online or offline event. Representation of a project may be
> > > > > >  further defined and clarified by project maintainers.
> > > > > > 
> > > > > > -Enforcement
> > > > > > -===========
> > > > > > -
> > > > > > -Instances of abusive, harassing, or otherwise unacceptable
> > > > > > behavior may be
> > > > > > -reported by contacting the Technical Advisory Board (TAB)
> > > > > > at
> > > > > > -<tab@lists.linux-foundation.org>. All complaints will be
> > > > > > reviewed and
> > > > > > -investigated and will result in a response that is deemed
> > > > > > necessary and
> > > > > > -appropriate to the circumstances. The TAB is obligated to
> > > > > > maintain
> > > > > > -confidentiality with regard to the reporter of an
> > > > > > incident.  Further details of
> > > > > > -specific enforcement policies may be posted separately.
> > > > > 
> > > > > I think it's OK to leave the above section, as it doesn't
> > > > > speak
> > > > > to enforcement, but rather is just a set of reporting
> > > > > instructions, with an assurance of confidentiality.  This
> > > > > seems
> > > > > to me not to be the objectionable part of this section.
> > > > > (IOW, I would omit this removal from the patch).
> > > > 
> > > > So I did think about that, but it struck me that with both
> > > > paragraphs removed, the current CoC is very similar to the
> > > > status quo: namely every subsystem handles their own issues and
> > > > that's formalised by the "Our Responsibilities" section.  That
> > > > also makes me think that whether we want a centralised channel
> > > > of reporting or enforcement and what it should be also ought to
> > > > be part of the debate.  The TAB was created to channel
> > > > community technical input into the Linux Foundation.  That's
> > > > not to say it can't provide the reporting and arbitration
> > > > structure, but if we're going to do it right we should debate
> > > > the expansion of its duties (and powers).
> > > 
> > > When the Code of Conflict was adopted 3 years ago, we already
> > > created the central reporting mechanism, so I actually think
> > > leaving (ie including) the above paragraph is closer to the
> > > status quo.  I think it's the expanded powers and duties (or
> > > perception thereof) that are causing concern and I think debating
> > > those to clarify intent, and adopting changes as needed  to
> > > ameliorate concerns is worthwhile. 
> > If we want to go back to the status quo, then a plain revert is the
> > patch series I should submit.
> 
> Let me try to be more clear.  I don't want to go back to the status
> quo. I was saying that if we keep this document, but omit the central
> reporting mechanism, that is a large departure from the status quo,
> because the Code of Conflict already established that.  And I think
> that having an ombudsman-type role somewhere in the community
> is beneficial.

The purpose of this patch is not to be the final point but to take us
up to a useful starting point for Shuah's CoC debate proposal at the
kernel summit (and beyond).  Shuah asked that I clarify this in the
commit message, so I will in v2.

> I believe parts of the Code of Conduct are an improvement over the
> Code of Conflict, so my personal preference would be to keep it
> and try to adjust it moving forward.  I think your patches, with
> clear suggestions for improvements (or for deletions in the case
> where we want more debate on particular sections before adopting
> them) is a good approach, and I like that process as opposed to
> starting over from scratch.

OK, so you're happy with the current patch as the starting not the
ending point?

> > > I believe that in the vast majority of cases, the TAB will end up
> > > performing a mediator role to smooth hurt feelings and remind and
> > > encourage improved communication - very similar to what we've
> > > done in the past.  I really believe that bans will continue to be
> > > very few and far between, as they have been historically (I can
> > > only think of 3 in the past decade.)
> > 
> > That might very well be the position the discussion arrives at;
> > however, I really think making the process fully transparent this
> > time requires not prejudging the outcome.
> 
> I don't understand your point here.  Can you elaborate?

Yes: I could foresee an outcome where the kernel community decides to
vest CoC enforcement in a different body from the TAB, or even in no
body but an informal maintainers list.  I'm not saying that *will*
happen, merely that it's an outcome that should not be foreclosed at
this point.

James

RE: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Tim.Bird]

> -----Original Message-----
> From: James Bottomley
> 
> On Mon, 2018-10-08 at 17:58 +0000, Tim.Bird@sony.com wrote:
> > > -----Original Message-----
> > > From: James Bottomley
> > >
> > > On Mon, 2018-10-08 at 13:51 +0000, Tim.Bird@sony.com wrote:
> > > > > -----Original Message-----
> > > > > From: James Bottomley
> > > > > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: James Bottomley
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > Signed-off-by: James Bottomley
> > > > > > > <James.Bottomley@HansenPartnership.com>
> > > > > > > ---
> > > > > > >  Documentation/process/code-of-conduct.rst | 15 ---------
> > > > > > > ------
> > > > > > >  1 file changed, 15 deletions(-)
> > > > > > >
> > > > > > > diff --git a/Documentation/process/code-of-conduct.rst
> > > > > > > b/Documentation/process/code-of-conduct.rst
> > > > > > > index aa40e34e7785..4dd90987305b 100644
> > > > > > > --- a/Documentation/process/code-of-conduct.rst
> > > > > > > +++ b/Documentation/process/code-of-conduct.rst
> > > > > > > @@ -59,21 +59,6 @@ address, posting via an official social
> > > > > > > media account, or acting as an appointed representative at
> > > > > > > an
> > > > > > > online or offline event. Representation of a project may be
> > > > > > >  further defined and clarified by project maintainers.
> > > > > > >
> > > > > > > -Enforcement
> > > > > > > -===========
> > > > > > > -
> > > > > > > -Instances of abusive, harassing, or otherwise unacceptable
> > > > > > > behavior may be
> > > > > > > -reported by contacting the Technical Advisory Board (TAB)
> > > > > > > at
> > > > > > > -<tab@lists.linux-foundation.org>. All complaints will be
> > > > > > > reviewed and
> > > > > > > -investigated and will result in a response that is deemed
> > > > > > > necessary and
> > > > > > > -appropriate to the circumstances. The TAB is obligated to
> > > > > > > maintain
> > > > > > > -confidentiality with regard to the reporter of an
> > > > > > > incident.  Further details of
> > > > > > > -specific enforcement policies may be posted separately.
> > > > > >
> > > > > > I think it's OK to leave the above section, as it doesn't
> > > > > > speak
> > > > > > to enforcement, but rather is just a set of reporting
> > > > > > instructions, with an assurance of confidentiality.  This
> > > > > > seems
> > > > > > to me not to be the objectionable part of this section.
> > > > > > (IOW, I would omit this removal from the patch).
> > > > >
> > > > > So I did think about that, but it struck me that with both
> > > > > paragraphs removed, the current CoC is very similar to the
> > > > > status quo: namely every subsystem handles their own issues and
> > > > > that's formalised by the "Our Responsibilities" section.  That
> > > > > also makes me think that whether we want a centralised channel
> > > > > of reporting or enforcement and what it should be also ought to
> > > > > be part of the debate.  The TAB was created to channel
> > > > > community technical input into the Linux Foundation.  That's
> > > > > not to say it can't provide the reporting and arbitration
> > > > > structure, but if we're going to do it right we should debate
> > > > > the expansion of its duties (and powers).
> > > >
> > > > When the Code of Conflict was adopted 3 years ago, we already
> > > > created the central reporting mechanism, so I actually think
> > > > leaving (ie including) the above paragraph is closer to the
> > > > status quo.  I think it's the expanded powers and duties (or
> > > > perception thereof) that are causing concern and I think debating
> > > > those to clarify intent, and adopting changes as needed  to
> > > > ameliorate concerns is worthwhile.
> > > If we want to go back to the status quo, then a plain revert is the
> > > patch series I should submit.
> >
> > Let me try to be more clear.  I don't want to go back to the status
> > quo. I was saying that if we keep this document, but omit the central
> > reporting mechanism, that is a large departure from the status quo,
> > because the Code of Conflict already established that.  And I think
> > that having an ombudsman-type role somewhere in the community
> > is beneficial.
> 
> The purpose of this patch is not to be the final point but to take us
> up to a useful starting point for Shuah's CoC debate proposal at the
> kernel summit (and beyond).  Shuah asked that I clarify this in the
> commit message, so I will in v2.
> 
> > I believe parts of the Code of Conduct are an improvement over the
> > Code of Conflict, so my personal preference would be to keep it
> > and try to adjust it moving forward.  I think your patches, with
> > clear suggestions for improvements (or for deletions in the case
> > where we want more debate on particular sections before adopting
> > them) is a good approach, and I like that process as opposed to
> > starting over from scratch.
> 
> OK, so you're happy with the current patch as the starting not the
> ending point?

I'm happy with the second hunk as a starting point, but not the first.
I think the first hunk is a regression that is not needed to address the
concerns that I have seen raised so far.  The first hunk seems to me to be
close to what the Code of Conflict already had, and what the
community was already working under.

> > > > I believe that in the vast majority of cases, the TAB will end up
> > > > performing a mediator role to smooth hurt feelings and remind and
> > > > encourage improved communication - very similar to what we've
> > > > done in the past.  I really believe that bans will continue to be
> > > > very few and far between, as they have been historically (I can
> > > > only think of 3 in the past decade.)
> > >
> > > That might very well be the position the discussion arrives at;
> > > however, I really think making the process fully transparent this
> > > time requires not prejudging the outcome.
> >
> > I don't understand your point here.  Can you elaborate?
> 
> Yes: I could foresee an outcome where the kernel community decides to
> vest CoC enforcement in a different body from the TAB, or even in no
> body but an informal maintainers list.  I'm not saying that *will*
> happen, merely that it's an outcome that should not be foreclosed at
> this point.

OK, thanks for the explanation.  I don't have a strong opinion about
the resulting outcome of community consensus.  I think we'll come up
with something that satisfies most people, and it's possible it won't look like
what we have now.  So I'd agree we shouldn't foreclose outcomes.  I hope it
doesn't look like I'm *just* arguing for keeping the TAB in some enforcement
role.  I'm not.  I'm arguing that the current CoC language (in the first
paragraph of the enforcement section) keeps the TAB as the central reporting
mechanism, and that this is less of a change to current policy than removing it.
If people want to argue for a difference in central reporting, or no central
reporting at all, I'm all ears.
(Although, I'm not sure my ears count for anything.  That's up to whoever
accepts such patches, and that's not me.)

Put a completely different way:  I believe the goal of the patch is to remove
parts of the new CoC that people have concerns about, pending a community
discussion about the issues.  My personal opinion is that the first part of
the enforcement clause, listing the TAB as the contact point, and trying to make
an assurance of confidentiality, doesn't have to be part of that removal (now),
because it's not very controversial.
 -- Tim

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[jonsmirl]

On Mon, Oct 8, 2018 at 9:51 AM <Tim.Bird@sony.com> wrote:
>
>
>
> > -----Original Message-----
> > From: James Bottomley
> > On Sat, 2018-10-06 at 21:43 +0000, Tim.Bird@sony.com wrote:
> > > > -----Original Message-----
> > > > From: James Bottomley
> > > >
> > > > 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.
> > > >
> > > > Signed-off-by: James Bottomley
> > > > <James.Bottomley@HansenPartnership.com>
> > > > ---
> > > >  Documentation/process/code-of-conduct.rst | 15 ---------------
> > > >  1 file changed, 15 deletions(-)
> > > >
> > > > diff --git a/Documentation/process/code-of-conduct.rst
> > > > b/Documentation/process/code-of-conduct.rst
> > > > index aa40e34e7785..4dd90987305b 100644
> > > > --- a/Documentation/process/code-of-conduct.rst
> > > > +++ b/Documentation/process/code-of-conduct.rst
> > > > @@ -59,21 +59,6 @@ address, posting via an official social media
> > > > account, or
> > > > acting as an appointed
> > > >  representative at an online or offline event. Representation of a
> > > > project may
> > > > be
> > > >  further defined and clarified by project maintainers.
> > > >
> > > > -Enforcement
> > > > -===========
> > > > -
> > > > -Instances of abusive, harassing, or otherwise unacceptable
> > > > behavior may be
> > > > -reported by contacting the Technical Advisory Board (TAB) at
> > > > -<tab@lists.linux-foundation.org>. All complaints will be reviewed
> > > > and
> > > > -investigated and will result in a response that is deemed
> > > > necessary and
> > > > -appropriate to the circumstances. The TAB is obligated to maintain
> > > > -confidentiality with regard to the reporter of an
> > > > incident.  Further details of
> > > > -specific enforcement policies may be posted separately.
> > >
> > > I think it's OK to leave the above section, as it doesn't speak to
> > > enforcement, but rather is just a set of reporting instructions,
> > > with an assurance of confidentiality.  This seems to me not to be
> > > the objectionable part of this section.
> > > (IOW, I would omit this removal from the patch).
> >
> > So I did think about that, but it struck me that with both paragraphs
> > removed, the current CoC is very similar to the status quo: namely
> > every subsystem handles their own issues and that's formalised by the
> > "Our Responsibilities" section.  That also makes me think that whether
> > we want a centralised channel of reporting or enforcement and what it
> > should be also ought to be part of the debate.  The TAB was created to
> > channel community technical input into the Linux Foundation.  That's
> > not to say it can't provide the reporting and arbitration structure,
> > but if we're going to do it right we should debate the expansion of its
> > duties (and powers).
>
> When the Code of Conflict was adopted 3 years ago, we already created
> the central reporting mechanism, so I actually think leaving (ie including) the above
> paragraph is closer to the status quo.  I think it's the expanded powers and
> duties (or perception thereof) that are causing concern and I think debating
> those to clarify intent, and adopting changes as needed  to ameliorate concerns
> is worthwhile.

In most cases any CoC is not going to be much of a problem. The
problem is going to occur when one of the top five or so people is
accused of a violation. That is going to end up in the mainstream
press. Big money and corporate power will be at play.  The CoC needs
needs to be designed to handle something like the Bredan Eich
situation.  In that situation he was initially attacked by external
parties. I will keep recommending that the legal community weigh in
before making this official policy. We are focusing on the case of the
random individual, but I suspect the problem lies in an attack on the
leadership.

>
> I believe that in the vast majority of cases, the TAB will end up
> performing a mediator role to smooth hurt feelings and remind and encourage
> improved communication - very similar to what we've done in the past.  I really
> believe that bans will continue to be very few and far between, as they have
> been historically (I can only think of 3 in the past decade.)
>  -- Tim
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Alan Cox]

 
> I happen to think that the fact that the TAB cannot compel where it
> cannot persuade is a huge strength of the system because it means
> there's no power structure to subvert if someone were interested in
> using it to try to impose their own viewpoint on the community.  But
> that's just my opinion and I did write the TAB charter, so I'm probably
> biased in this viewpoint.

The TAB can't handle it anyway because the privacy promise about
reporting is incompatible with reality for three reasons (and I bet there
are more)

1. Things like the EUCD can force almost all but the name to be revealed
to the person complained about as the tab has no legal privilege.
2. There are lots of laws in lots of locations where some allegations
*MUST* be reported to law enforcement.
3. We know from things like the catholic church debacle that serious
allegations need to be fast-pathed to the legal system - yet the privacy
promises are incompatible with that.

It ever got really nasty then the scenario that unfolds is potentially
the following

Developer A makes a complaint about developer B
Developer B's employer fires developer B

Developer B then uses things like the EUCD to force the TAB to provide
the complaint details (with personal data redacted) and the TAB has no
real defence as it's not legally privileged. 

Developer B then sues developer A, the TAB for all sorts of things, the
LF and their employer.

In court what's going to happen to the TAB ?

= Where is your written policy ?
= Who approved it and reviewed it for legal compliance ?
= What are your qualifications in this area ?
= Where are the full minutes of the decision ?
= Which of you work for rival companies ?
= What personal connections do or your frends have to A and B ?

Needless to say answers like 'we don't have one, nobody, none, umm I think
there's an email thread' are not going to go down well.

This sort of mess works with big company HR departments because they've
got lawyers and they have lots of written process. If it hits a court
then B's employer is able to point at all their rules and policies,
employment contracts etc. All of the decisions were either legally
privileged or minuted properly. The people who made the decisions have
appropriate professional qualifications.

The TAB can't enforce anything. If maintainers decide to carry on
accepting patches from someone what can they do ?

So both patches:

Reviewed-by: Alan Cox <alan@llwyncelyn.cymru>

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Dan Carpenter]

On Mon, Oct 08, 2018 at 04:37:48PM +0100, Alan Cox wrote:
>  
> > I happen to think that the fact that the TAB cannot compel where it
> > cannot persuade is a huge strength of the system because it means
> > there's no power structure to subvert if someone were interested in
> > using it to try to impose their own viewpoint on the community.  But
> > that's just my opinion and I did write the TAB charter, so I'm probably
> > biased in this viewpoint.
> 
> The TAB can't handle it anyway because the privacy promise about
> reporting is incompatible with reality for three reasons (and I bet there
> are more)

Really you want to keep any reporting private from people on the TAB
because they're going to be interviewing you for a job in a couple
years.

regards,
dan carpenter

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Shuah Khan]

On 10/06/2018 03:37 PM, James Bottomley wrote:
> 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.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
> ---
>  Documentation/process/code-of-conduct.rst | 15 ---------------
>  1 file changed, 15 deletions(-)
> 
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index aa40e34e7785..4dd90987305b 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
>  representative at an online or offline event. Representation of a project may be
>  further defined and clarified by project maintainers.
>  
> -Enforcement
> -===========
> -
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> -reported by contacting the Technical Advisory Board (TAB) at
> -<tab@lists.linux-foundation.org>. All complaints will be reviewed and
> -investigated and will result in a response that is deemed necessary and
> -appropriate to the circumstances. The TAB is obligated to maintain
> -confidentiality with regard to the reporter of an incident.  Further details of
> -specific enforcement policies may be posted separately.
> -
> -Maintainers who do not follow or enforce the Code of Conduct in good faith may
> -face temporary or permanent repercussions as determined by other members of the
> -project’s leadership.
> -
>  Attribution
>  ===========
>  
> 

With the assumption that the enforcement details will be added later after community
discussion in upcoming releases.

Acked-by: Shuah Khan <shuah@kernel.org>

thanks,
-- Shuah

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Guenter Roeck]

On 10/06/2018 02:37 PM, James Bottomley wrote:
> 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.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

Acked-by: Guenter Roeck <linux@roeck-us.net>

Reasoning:
- The TAB was not elected as enforcement agency.
- I, as a maintainer, was not consulted when it was decided that I shall be
   responsible for enforcing the Code of Conduct.

Guenter

> ---
>   Documentation/process/code-of-conduct.rst | 15 ---------------
>   1 file changed, 15 deletions(-)
> 
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index aa40e34e7785..4dd90987305b 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
>   representative at an online or offline event. Representation of a project may be
>   further defined and clarified by project maintainers.
>   
> -Enforcement
> -===========
> -
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> -reported by contacting the Technical Advisory Board (TAB) at
> -<tab@lists.linux-foundation.org>. All complaints will be reviewed and
> -investigated and will result in a response that is deemed necessary and
> -appropriate to the circumstances. The TAB is obligated to maintain
> -confidentiality with regard to the reporter of an incident.  Further details of
> -specific enforcement policies may be posted separately.
> -
> -Maintainers who do not follow or enforce the Code of Conduct in good faith may
> -face temporary or permanent repercussions as determined by other members of the
> -project’s leadership.
> -
>   Attribution
>   ===========
>   
> 

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Geert Uytterhoeven]

On Sat, Oct 6, 2018 at 11:37 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> 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.
>
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

Fixes: 8a104f8b5867c682 ("Code of Conduct: Let's revamp it.")

Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Chris Mason]

On 6 Oct 2018, at 17:37, James Bottomley wrote:

> 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.

Even in the places where I don't agree with the discussion about what 
our code of conduct should be, I love that we're having it.  Removing 
the enforcement clause basically goes back to the way things were.  We'd 
be recognizing that we know issues happen, and explicitly stating that 
when serious events do happen, the community as a whole isn't committing 
to helping.

It's true there are a lot of questions about how the community resolves 
problems and holds each other accountable for maintaining any code of 
conduct.  I think the enforcement section leaves us the room we need to 
continue discussions and still make it clear that we're making an effort 
to shift away from the harsh discussions in the past.

-chris

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Josh Triplett]

On Mon, Oct 08, 2018 at 02:15:25PM -0400, Chris Mason wrote:
> On 6 Oct 2018, at 17:37, James Bottomley wrote:
> > 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.
> 
> Even in the places where I don't agree with the discussion about what our
> code of conduct should be, I love that we're having it.  Removing the
> enforcement clause basically goes back to the way things were.  We'd be
> recognizing that we know issues happen, and explicitly stating that when
> serious events do happen, the community as a whole isn't committing to
> helping.
> 
> It's true there are a lot of questions about how the community resolves
> problems and holds each other accountable for maintaining any code of
> conduct.  I think the enforcement section leaves us the room we need to
> continue discussions and still make it clear that we're making an effort to
> shift away from the harsh discussions in the past.

Emphatically seconded.

I absolutely agree that we should to work on the enforcement section
over time; for instance, I agree that a dedicated team (ideally with
some training) would be better than vesting this in a technical
decision-making body.

But I agree with Chris that we should not remove this entirely. And I
don't think there's any special significance to this being in the 4.19
release as compared to an -rc or git HEAD.

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Mauro Carvalho Chehab]

Em Sat, 06 Oct 2018 14:37:31 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> 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.
> 
> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>


With my maintainer's hat, my main concern would be solved with this hunk:

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..f07d51129d4b 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -43,7 +43,7 @@ Maintainers are responsible for clarifying the standards of acceptable behavior
 and are expected to take appropriate and fair corrective action in response to
 any instances of unacceptable behavior.
 
-Maintainers have the right and responsibility to remove, edit, or reject
+Maintainers may remove, edit, or reject
 comments, commits, code, wiki edits, issues, and other contributions that are
 not aligned to this Code of Conduct, or to ban temporarily or permanently any
 contributor for other behaviors that they deem inappropriate, threatening,

The previous text seems too much legal for my taste.

> ---
>  Documentation/process/code-of-conduct.rst | 15 ---------------
>  1 file changed, 15 deletions(-)
> 
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index aa40e34e7785..4dd90987305b 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -59,21 +59,6 @@ address, posting via an official social media account, or acting as an appointed
>  representative at an online or offline event. Representation of a project may be
>  further defined and clarified by project maintainers.
>  
> -Enforcement
> -===========
> -
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> -reported by contacting the Technical Advisory Board (TAB) at
> -<tab@lists.linux-foundation.org>. All complaints will be reviewed and
> -investigated and will result in a response that is deemed necessary and
> -appropriate to the circumstances. The TAB is obligated to maintain
> -confidentiality with regard to the reporter of an incident.  Further details of
> -specific enforcement policies may be posted separately.
> -
> -Maintainers who do not follow or enforce the Code of Conduct in good faith may
> -face temporary or permanent repercussions as determined by other members of the
> -project’s leadership.
> -
>  Attribution
>  ===========

After looking at the comments, I would just keep TAB as a point of contact
for CoC violations:

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..fa908dbff51c 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,20 +59,12 @@ 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
-===========
+Reports
+=======
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported by contacting the Technical Advisory Board (TAB) at
-<tab@lists.linux-foundation.org>. All complaints will be reviewed and
-investigated and will result in a response that is deemed necessary and
-appropriate to the circumstances. The TAB is obligated to maintain
-confidentiality with regard to the reporter of an incident.  Further details of
-specific enforcement policies may be posted separately.
-
-Maintainers who do not follow or enforce the Code of Conduct in good faith may
-face temporary or permanent repercussions as determined by other members of the
-project’s leadership.
+<tab@lists.linux-foundation.org>.
 
 Attribution
 ===========

Keeping the rest implicit. This can be revisited after having more
discussions.

Thanks,
Mauro

-

Both hunks are shown below.


diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..df44867a2db5 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -43,7 +43,7 @@ Maintainers are responsible for clarifying the standards of acceptable behavior
 and are expected to take appropriate and fair corrective action in response to
 any instances of unacceptable behavior.
 
-Maintainers have the right and responsibility to remove, edit, or reject
+Maintainers may remove, edit, or reject
 comments, commits, code, wiki edits, issues, and other contributions that are
 not aligned to this Code of Conduct, or to ban temporarily or permanently any
 contributor for other behaviors that they deem inappropriate, threatening,
@@ -59,20 +59,12 @@ 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
-===========
+Reports
+=======
 
 Instances of abusive, harassing, or otherwise unacceptable behavior may be
 reported by contacting the Technical Advisory Board (TAB) at
-<tab@lists.linux-foundation.org>. All complaints will be reviewed and
-investigated and will result in a response that is deemed necessary and
-appropriate to the circumstances. The TAB is obligated to maintain
-confidentiality with regard to the reporter of an incident.  Further details of
-specific enforcement policies may be posted separately.
-
-Maintainers who do not follow or enforce the Code of Conduct in good faith may
-face temporary or permanent repercussions as determined by other members of the
-project’s leadership.
+<tab@lists.linux-foundation.org>.
 
 Attribution
 ===========

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Alan Cox]

> -Maintainers have the right and responsibility to remove, edit, or reject
> +Maintainers may remove, edit, or reject
>  comments, commits, code, wiki edits, issues, and other contributions that are
>  not aligned to this Code of Conduct, or to ban temporarily or permanently any
>  contributor for other behaviors that they deem inappropriate, threatening,
> 
> The previous text seems too much legal for my taste.
> 

That is just as confusing. Maintainers have the right to remove, edit,
reject commits that *are* aligned with the code as well. So what exactly
is the point here ?

Alan

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Mauro Carvalho Chehab]

Em Wed, 10 Oct 2018 16:53:08 +0100
Alan Cox <gnomes@lxorguk.ukuu.org.uk> escreveu:

> > -Maintainers have the right and responsibility to remove, edit, or reject
> > +Maintainers may remove, edit, or reject
> >  comments, commits, code, wiki edits, issues, and other contributions that are
> >  not aligned to this Code of Conduct, or to ban temporarily or permanently any
> >  contributor for other behaviors that they deem inappropriate, threatening,
> > 
> > The previous text seems too much legal for my taste.
> >   
> 
> That is just as confusing. Maintainers have the right to remove, edit,
> reject commits that *are* aligned with the code as well.

Good point. Yeah, a maintainer can do whatever he thinks it is 
appropriate for a patch - even when it follows the CoC.

> So what exactly is the point here ?

The point is "responsibility" - that sounds like it is bounding a legal
duty to a maintainer.

While this makes sense for Github (as the company doesn't want to be
responsible for sanitizing every single post), this doesn't work for
e-mail based workflow, where the message is stored on a distributed
way, as a maintainer can't "remove, edit or reject" an e-mail.

Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Alan Cox]

On Wed, 10 Oct 2018 14:19:17 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:

> Em Wed, 10 Oct 2018 16:53:08 +0100
> Alan Cox <gnomes@lxorguk.ukuu.org.uk> escreveu:
> 
> > > -Maintainers have the right and responsibility to remove, edit, or reject
> > > +Maintainers may remove, edit, or reject
> > >  comments, commits, code, wiki edits, issues, and other contributions that are
> > >  not aligned to this Code of Conduct, or to ban temporarily or permanently any
> > >  contributor for other behaviors that they deem inappropriate, threatening,
> > > 
> > > The previous text seems too much legal for my taste.
> > >     
> > 
> > That is just as confusing. Maintainers have the right to remove, edit,
> > reject commits that *are* aligned with the code as well.  
> 
> Good point. Yeah, a maintainer can do whatever he thinks it is 
> appropriate for a patch - even when it follows the CoC.
> 
> > So what exactly is the point here ?  
> 
> The point is "responsibility" - that sounds like it is bounding a legal
> duty to a maintainer.

If you remove the responsibility aspect you might as well remove the
entire clause. It doesn't say anything as it's simply a subset of what
maintainers do anyway.

So how about

"Maintainers should remove, edit or reject..."

that keeps the sense that there should be pressure against abusive
behaviour.

except of course someone will attach a zero day exploit and fix to a
coc-violating rant and then you are a bit stuffed 8)

Alan

Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion

[Mauro Carvalho Chehab]

Em Wed, 10 Oct 2018 21:09:48 +0100
Alan Cox <gnomes@lxorguk.ukuu.org.uk> escreveu:

> On Wed, 10 Oct 2018 14:19:17 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> 
> > Em Wed, 10 Oct 2018 16:53:08 +0100
> > Alan Cox <gnomes@lxorguk.ukuu.org.uk> escreveu:
> >   
> > > > -Maintainers have the right and responsibility to remove, edit, or reject
> > > > +Maintainers may remove, edit, or reject
> > > >  comments, commits, code, wiki edits, issues, and other contributions that are
> > > >  not aligned to this Code of Conduct, or to ban temporarily or permanently any
> > > >  contributor for other behaviors that they deem inappropriate, threatening,
> > > > 
> > > > The previous text seems too much legal for my taste.
> > > >       
> > > 
> > > That is just as confusing. Maintainers have the right to remove, edit,
> > > reject commits that *are* aligned with the code as well.    
> > 
> > Good point. Yeah, a maintainer can do whatever he thinks it is 
> > appropriate for a patch - even when it follows the CoC.
> >   
> > > So what exactly is the point here ?    
> > 
> > The point is "responsibility" - that sounds like it is bounding a legal
> > duty to a maintainer.  
> 
> If you remove the responsibility aspect you might as well remove the
> entire clause. It doesn't say anything as it's simply a subset of what
> maintainers do anyway.
> 
> So how about
> 
> "Maintainers should remove, edit or reject..."
> 
> that keeps the sense that there should be pressure against abusive
> behaviour.

Works for me.

> except of course someone will attach a zero day exploit and fix to a
> coc-violating rant and then you are a bit stuffed 8)

:-)

Thanks,
Mauro

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

[Daniel Vetter]

Hi James,

On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> 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.

Personally I'm not happy at all with how the new code of conduct was
rushed in, least because I still don't understand why it happened, but
also for all the other reasons we've discussed here in the past few
weeks.

For all the same reasons I don't think it's a good idea to now rush in
a few edits, just a few days before the 4.19 release. In my
experience, and I've discussed code of conducts and their enforcement
for years even before we implemented the fd.o/dri-devel one, mailing
lists aren't the best place to have this discussion. Definitely not
under the time pressure of just a few days to get it all sorted. I
hope that we can have these discussiones at the maintainer summit and
kernel summit/plumbers, and will have more clarity in a few weeks
(probably more likely months).

But I also understand that there's lots of people (me included) who
don't want to ship a release with the code of conduct in it's current
in-between state. I think adding a disclaimer at the top, along the
lines of

"Please note that this code of conduct and it's enforcement are still
under discussion."

would make this clear and ameliorate the concerns from many people
about the open questions we still have, at least for now. This would
give us the time to discuss all the details properly and with all due
deliberation. I'm travelling next week, so not the right guy to push
this, but I'd be happy to ack such a patch (or something along the
same lines). I also believe that this statement is undisputed enough
that we can gather widespread support for it in the few days left
until 4.19 ships to make it happen.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

[James Bottomley]

On Sun, 2018-10-07 at 19:11 +0200, Daniel Vetter wrote:
> Hi James,
> 
> On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > 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.
> 
> Personally I'm not happy at all with how the new code of conduct was
> rushed in, least because I still don't understand why it happened,
> but also for all the other reasons we've discussed here in the past
> few weeks.
> 
> For all the same reasons I don't think it's a good idea to now rush
> in a few edits, just a few days before the 4.19 release. In my
> experience, and I've discussed code of conducts and their enforcement
> for years even before we implemented the fd.o/dri-devel one, mailing
> lists aren't the best place to have this discussion. Definitely not
> under the time pressure of just a few days to get it all sorted. I
> hope that we can have these discussiones at the maintainer summit and
> kernel summit/plumbers, and will have more clarity in a few weeks
> (probably more likely months).
> 
> But I also understand that there's lots of people (me included) who
> don't want to ship a release with the code of conduct in it's current
> in-between state. I think adding a disclaimer at the top, along the
> lines of
> 
> "Please note that this code of conduct and it's enforcement are still
> under discussion."

I don't disagree with the position, but eliminating our old code of
conduct in favour of another we cast doubt on with this disclaimer
effectively leaves us with nothing at all, which seems to be a worse
situation.  In that case, I think reverting the CoC commit
(8a104f8b5867c682) and then restarting the replacement process is
better than adding a disclaimer to the new one.

My preference is to try to fix what we have instead of starting over,
but it's not a strong one, so if people want to go for the revert
instead of the amendment, I'd be happy to redo the patch series with
that.

James


> would make this clear and ameliorate the concerns from many people
> about the open questions we still have, at least for now. This would
> give us the time to discuss all the details properly and with all due
> deliberation. I'm travelling next week, so not the right guy to push
> this, but I'd be happy to ack such a patch (or something along the
> same lines). I also believe that this statement is undisputed enough
> that we can gather widespread support for it in the few days left
> until 4.19 ships to make it happen.
> 
> Thanks, Daniel

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

[jonsmirl]

On Sun, Oct 7, 2018 at 1:42 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Sun, 2018-10-07 at 19:11 +0200, Daniel Vetter wrote:
> > Hi James,
> >
> > On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > 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.
> >
> > Personally I'm not happy at all with how the new code of conduct was
> > rushed in, least because I still don't understand why it happened,
> > but also for all the other reasons we've discussed here in the past
> > few weeks.

As far as I know none of the usual open source friendly lawyers have
reviewed and commented. I suspect this document is on shaky legal
ground and it needs a vetting from the legal community. For example,
is the CoC simply guidance or it is a legal contract? I don't know
enough about the law to answer that.

> >
> > For all the same reasons I don't think it's a good idea to now rush
> > in a few edits, just a few days before the 4.19 release. In my
> > experience, and I've discussed code of conducts and their enforcement
> > for years even before we implemented the fd.o/dri-devel one, mailing
> > lists aren't the best place to have this discussion. Definitely not
> > under the time pressure of just a few days to get it all sorted. I
> > hope that we can have these discussiones at the maintainer summit and
> > kernel summit/plumbers, and will have more clarity in a few weeks
> > (probably more likely months).
> >
> > But I also understand that there's lots of people (me included) who
> > don't want to ship a release with the code of conduct in it's current
> > in-between state. I think adding a disclaimer at the top, along the
> > lines of
> >
> > "Please note that this code of conduct and it's enforcement are still
> > under discussion."
>
> I don't disagree with the position, but eliminating our old code of
> conduct in favour of another we cast doubt on with this disclaimer
> effectively leaves us with nothing at all, which seems to be a worse
> situation.  In that case, I think reverting the CoC commit
> (8a104f8b5867c682) and then restarting the replacement process is
> better than adding a disclaimer to the new one.
>
> My preference is to try to fix what we have instead of starting over,
> but it's not a strong one, so if people want to go for the revert
> instead of the amendment, I'd be happy to redo the patch series with
> that.
>
> James
>
>
> > would make this clear and ameliorate the concerns from many people
> > about the open questions we still have, at least for now. This would
> > give us the time to discuss all the details properly and with all due
> > deliberation. I'm travelling next week, so not the right guy to push
> > this, but I'd be happy to ack such a patch (or something along the
> > same lines). I also believe that this statement is undisputed enough
> > that we can gather widespread support for it in the few days left
> > until 4.19 ships to make it happen.
> >
> > Thanks, Daniel
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

[Daniel Vetter]

On Sun, Oct 7, 2018 at 7:40 PM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
>
> On Sun, 2018-10-07 at 19:11 +0200, Daniel Vetter wrote:
> > Hi James,
> >
> > On Sat, Oct 6, 2018 at 11:36 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > 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.
> >
> > Personally I'm not happy at all with how the new code of conduct was
> > rushed in, least because I still don't understand why it happened,
> > but also for all the other reasons we've discussed here in the past
> > few weeks.
> >
> > For all the same reasons I don't think it's a good idea to now rush
> > in a few edits, just a few days before the 4.19 release. In my
> > experience, and I've discussed code of conducts and their enforcement
> > for years even before we implemented the fd.o/dri-devel one, mailing
> > lists aren't the best place to have this discussion. Definitely not
> > under the time pressure of just a few days to get it all sorted. I
> > hope that we can have these discussiones at the maintainer summit and
> > kernel summit/plumbers, and will have more clarity in a few weeks
> > (probably more likely months).
> >
> > But I also understand that there's lots of people (me included) who
> > don't want to ship a release with the code of conduct in it's current
> > in-between state. I think adding a disclaimer at the top, along the
> > lines of
> >
> > "Please note that this code of conduct and it's enforcement are still
> > under discussion."
>
> I don't disagree with the position, but eliminating our old code of
> conduct in favour of another we cast doubt on with this disclaimer
> effectively leaves us with nothing at all, which seems to be a worse
> situation.  In that case, I think reverting the CoC commit
> (8a104f8b5867c682) and then restarting the replacement process is
> better than adding a disclaimer to the new one.
>
> My preference is to try to fix what we have instead of starting over,
> but it's not a strong one, so if people want to go for the revert
> instead of the amendment, I'd be happy to redo the patch series with
> that.

I thought about adding something like "meanwhile the old Code of
Conflict stays in effect", but that already felt like editorializing,
and so could prevent the big pile of acks I think we need for any such
change. That's why I tried to limit my suggestion as much as possible
to stricly undisputed facts only (we _are_ discussing it still after
all). Personally I don't want to ack or nack any concrete changes
(including going back to the old one, if temporarily), as long as
Linus hasn't clarified why this was rushed and why he felt the change
was necessary.

Long term I'm all for getting this right of course, but figuring out
what "right" is in the context of the linux kernel community will take
a while longer than what we have until 4.19 ships (even with the 1
week extension, just read the -rc7 release announcement)..

Thanks, Daniel

> > would make this clear and ameliorate the concerns from many people
> > about the open questions we still have, at least for now. This would
> > give us the time to discuss all the details properly and with all due
> > deliberation. I'm travelling next week, so not the right guy to push
> > this, but I'd be happy to ack such a patch (or something along the
> > same lines). I also believe that this statement is undisputed enough
> > that we can gather widespread support for it in the few days left
> > until 4.19 ships to make it happen.
> >
> > Thanks, Daniel
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

Hi!

> > Personally I'm not happy at all with how the new code of conduct was
> > rushed in, least because I still don't understand why it happened,
> > but also for all the other reasons we've discussed here in the past
> > few weeks.

These are exactly my thoughts.

> > But I also understand that there's lots of people (me included) who
> > don't want to ship a release with the code of conduct in it's current
> > in-between state. I think adding a disclaimer at the top, along the
> > lines of
> > 
> > "Please note that this code of conduct and it's enforcement are still
> > under discussion."
> 
> I don't disagree with the position, but eliminating our old code of
> conduct in favour of another we cast doubt on with this disclaimer
> effectively leaves us with nothing at all, which seems to be a worse
> situation.  In that case, I think reverting the CoC commit
> (8a104f8b5867c682) and then restarting the replacement process is
> better than adding a disclaimer to the new one.

Reverting it then having proper discussion sounds suitable to me.

(And it would be nice to have something on the mailing lists, too, as
I probably won't make it to kernel summit this year.)
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Ksummit-discuss] [PATCH 0/2] code of conduct fixes

[Randy Dunlap]

On 10/10/18 9:12 AM, Pavel Machek wrote:
> Hi!
> 
>>> Personally I'm not happy at all with how the new code of conduct was
>>> rushed in, least because I still don't understand why it happened,
>>> but also for all the other reasons we've discussed here in the past
>>> few weeks.
> 
> These are exactly my thoughts.

Exactly.  We have a process and the 4.19-rc4 CoC patch did not follow it.

>>> But I also understand that there's lots of people (me included) who
>>> don't want to ship a release with the code of conduct in it's current
>>> in-between state. I think adding a disclaimer at the top, along the
>>> lines of
>>>
>>> "Please note that this code of conduct and it's enforcement are still
>>> under discussion."
>>
>> I don't disagree with the position, but eliminating our old code of
>> conduct in favour of another we cast doubt on with this disclaimer
>> effectively leaves us with nothing at all, which seems to be a worse
>> situation.  In that case, I think reverting the CoC commit
>> (8a104f8b5867c682) and then restarting the replacement process is
>> better than adding a disclaimer to the new one.
> 
> Reverting it then having proper discussion sounds suitable to me.
> 
> (And it would be nice to have something on the mailing lists, too, as
> I probably won't make it to kernel summit this year.)

Ditto.

-- 
~Randy