[Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Dave Airlie]

Hey,

Allow me to open this large can of worms I find sitting in front of
me, I'm not sure where it came from and I certainly didn't own it last
week.

I'm unlikely to be able to produce a trip to Edinburgh (even Vancouver
might be touch and go, travel budgets and family commitments don't
always line up).

I think there might be place for a report from the people who did sign
off the CoC about the thoughts/process involved in updating it (and/or
urgency) to the rest of the Maintainer group.

Now I understand that having a public talk about such a thing will
likely descend into farce, there may be scope for something of a
Chatham House Rule style meeting, or just a non-recorded, non-public
session like we've done for sensitive subjects are previous kernel
summits.

It might just be a readout from a similar meeting at Edinburgh summit
(maybe someone else can propose that), or maybe some sort of Q&A
session. Maybe Linus could record a piece to camera for the
maintainers that can't make Edinburgh, but would still like to
understand where everything currently sits. Said piece would of course
be burned afterwards.

After the past 2-3 days I get the feeling there are maintainers unsure
about how this affects them and I think assuaging those fears might be
a good thing.

(Daniel and I have worked under the freedesktop CoC for graphics
projects for over a year now, so this actually doesn't affect me in
any way I haven't already considered over a year ago, when I
signed'off introducing a CoC to the drm subsystem).

I'm also equally happy nailing the lid back on the can of worms and
never discussing it again.

Dave.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Steven Rostedt]

On Tue, 18 Sep 2018 15:55:23 +1000
Dave Airlie <airlied@gmail.com> wrote:

> I think there might be place for a report from the people who did sign
> off the CoC about the thoughts/process involved in updating it (and/or
> urgency) to the rest of the Maintainer group.
> 
> Now I understand that having a public talk about such a thing will
> likely descend into farce, there may be scope for something of a
> Chatham House Rule style meeting, or just a non-recorded, non-public
> session like we've done for sensitive subjects are previous kernel
> summits.

I believe this topic merits a discussion at Maintainer's Summit. It can
probably be much more productive face to face with several maintainers
in one room than what would result in a mailing list (both public and
private) discussion.

I'm willing to lead this if nobody else wants to do it.

  (I don't know why I do this to myself)


> 
> It might just be a readout from a similar meeting at Edinburgh summit
> (maybe someone else can propose that), or maybe some sort of Q&A
> session. Maybe Linus could record a piece to camera for the
> maintainers that can't make Edinburgh, but would still like to
> understand where everything currently sits. Said piece would of course
> be burned afterwards.

I would like to get an honest opinion from everyone involved, and
remove any of the ambiguities that people still have.

> 
> After the past 2-3 days I get the feeling there are maintainers unsure
> about how this affects them and I think assuaging those fears might be
> a good thing.

Agreed.

> 
> I'm also equally happy nailing the lid back on the can of worms and
> never discussing it again.

No no, the can is now open and you have released the worms ;-)

-- Steve

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[James Bottomley]

On Tue, 2018-09-18 at 15:55 +1000, Dave Airlie wrote:
> Hey,
> 
> Allow me to open this large can of worms I find sitting in front of
> me, I'm not sure where it came from and I certainly didn't own it
> last week.
> 
> I'm unlikely to be able to produce a trip to Edinburgh (even
> Vancouver might be touch and go, travel budgets and family
> commitments don't always line up).
> 
> I think there might be place for a report from the people who did
> sign off the CoC about the thoughts/process involved in updating it
> (and/or urgency) to the rest of the Maintainer group.
> 
> Now I understand that having a public talk about such a thing will
> likely descend into farce, there may be scope for something of a
> Chatham House Rule style meeting, or just a non-recorded, non-public
> session like we've done for sensitive subjects are previous kernel
> summits.
> 
> It might just be a readout from a similar meeting at Edinburgh summit
> (maybe someone else can propose that), or maybe some sort of Q&A
> session. Maybe Linus could record a piece to camera for the
> maintainers that can't make Edinburgh, but would still like to
> understand where everything currently sits. Said piece would of
> course be burned afterwards.

I'll let the people who signed off on it address this.

> After the past 2-3 days I get the feeling there are maintainers
> unsure about how this affects them and I think assuaging those fears
> might be a good thing.
> 
> (Daniel and I have worked under the freedesktop CoC for graphics
> projects for over a year now, so this actually doesn't affect me in
> any way I haven't already considered over a year ago, when I
> signed'off introducing a CoC to the drm subsystem).
> 
> I'm also equally happy nailing the lid back on the can of worms and
> never discussing it again.

>From my perspective, which is probably fairly widespread: we're already
pretty much policing the lists using a set of rules which match fairly
closely to the new CoC, so there should really be no huge impact.

The can of worms is that you can endlessly debate CoCs.  I don't think
this one is the best we could have chosen because it separates
behaviour into "contributing to positive environment" and
"unacceptable" but we have a lot of borderline problem behaviour that
isn't mentioned at all: things like being excessively nit picking in
reviews; being unable or unwilling to reach a compromise in a code
related dispute.  However, I think I'd rather have a root canal than a
debate on how to amend the new CoC, so I think it's good enough, lets
just go with it.

James

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Daniel Vetter]

On Tue, Sep 18, 2018 at 3:43 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 18 Sep 2018 15:55:23 +1000
> Dave Airlie <airlied@gmail.com> wrote:
>
>> I think there might be place for a report from the people who did sign
>> off the CoC about the thoughts/process involved in updating it (and/or
>> urgency) to the rest of the Maintainer group.
>>
>> Now I understand that having a public talk about such a thing will
>> likely descend into farce, there may be scope for something of a
>> Chatham House Rule style meeting, or just a non-recorded, non-public
>> session like we've done for sensitive subjects are previous kernel
>> summits.
>
> I believe this topic merits a discussion at Maintainer's Summit. It can
> probably be much more productive face to face with several maintainers
> in one room than what would result in a mailing list (both public and
> private) discussion.
>
> I'm willing to lead this if nobody else wants to do it.
>
>   (I don't know why I do this to myself)
>
>
>>
>> It might just be a readout from a similar meeting at Edinburgh summit
>> (maybe someone else can propose that), or maybe some sort of Q&A
>> session. Maybe Linus could record a piece to camera for the
>> maintainers that can't make Edinburgh, but would still like to
>> understand where everything currently sits. Said piece would of course
>> be burned afterwards.
>
> I would like to get an honest opinion from everyone involved, and
> remove any of the ambiguities that people still have.

What suprised me is how quickly this all happened. Back when we've
done the same CoC for freedesktop.org and all the graphics stuff
hosted there, there's been years of hallway track preceeding formally
enacting the CoC. Social expectations on the mailing list already
reflected the consensus that we expect constructive and respectful
collaboration, with informal peer driven enforcement when a maintainer
went a bit over the line. We also had pretty much everyone ack the
documentation patch before it landed. In other words, nothing changed
for dri-devel when we've done this ~2 years ago, except the already
lived expectations have been encoded.

As much as I welcome this as a first step on a fairly long path, it
does feel rushed since it seems to have happened in just ~10 days.
>From chatting with people, I think this left a lot wondering about
what's really going on, with interesting conspiracy theories running
rampant. Personally I have serious worries that to rapid change will
overwhelm the community's ability to process it, with ugly unintended
consequences.
-Daniel

>> After the past 2-3 days I get the feeling there are maintainers unsure
>> about how this affects them and I think assuaging those fears might be
>> a good thing.
>
> Agreed.
>
>>
>> I'm also equally happy nailing the lid back on the can of worms and
>> never discussing it again.
>
> No no, the can is now open and you have released the worms ;-)
>
> -- Steve
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



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

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Daniel Vetter]

On Tue, Sep 18, 2018 at 4:02 PM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2018-09-18 at 15:55 +1000, Dave Airlie wrote:
>> Hey,
>>
>> Allow me to open this large can of worms I find sitting in front of
>> me, I'm not sure where it came from and I certainly didn't own it
>> last week.
>>
>> I'm unlikely to be able to produce a trip to Edinburgh (even
>> Vancouver might be touch and go, travel budgets and family
>> commitments don't always line up).
>>
>> I think there might be place for a report from the people who did
>> sign off the CoC about the thoughts/process involved in updating it
>> (and/or urgency) to the rest of the Maintainer group.
>>
>> Now I understand that having a public talk about such a thing will
>> likely descend into farce, there may be scope for something of a
>> Chatham House Rule style meeting, or just a non-recorded, non-public
>> session like we've done for sensitive subjects are previous kernel
>> summits.
>>
>> It might just be a readout from a similar meeting at Edinburgh summit
>> (maybe someone else can propose that), or maybe some sort of Q&A
>> session. Maybe Linus could record a piece to camera for the
>> maintainers that can't make Edinburgh, but would still like to
>> understand where everything currently sits. Said piece would of
>> course be burned afterwards.
>
> I'll let the people who signed off on it address this.
>
>> After the past 2-3 days I get the feeling there are maintainers
>> unsure about how this affects them and I think assuaging those fears
>> might be a good thing.
>>
>> (Daniel and I have worked under the freedesktop CoC for graphics
>> projects for over a year now, so this actually doesn't affect me in
>> any way I haven't already considered over a year ago, when I
>> signed'off introducing a CoC to the drm subsystem).
>>
>> I'm also equally happy nailing the lid back on the can of worms and
>> never discussing it again.
>
> From my perspective, which is probably fairly widespread: we're already
> pretty much policing the lists using a set of rules which match fairly
> closely to the new CoC, so there should really be no huge impact.
>
> The can of worms is that you can endlessly debate CoCs.  I don't think
> this one is the best we could have chosen because it separates
> behaviour into "contributing to positive environment" and
> "unacceptable" but we have a lot of borderline problem behaviour that
> isn't mentioned at all: things like being excessively nit picking in
> reviews; being unable or unwilling to reach a compromise in a code
> related dispute.  However, I think I'd rather have a root canal than a
> debate on how to amend the new CoC, so I think it's good enough, lets
> just go with it.

I think the insistence that there's nothing to discuss here, for
years, is what brought us to this point. I don't think it's an
effective strategy going forward.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Geert Uytterhoeven]

On Tue, Sep 18, 2018 at 4:34 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Sep 18, 2018 at 3:43 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Tue, 18 Sep 2018 15:55:23 +1000
> > Dave Airlie <airlied@gmail.com> wrote:
> What suprised me is how quickly this all happened. Back when we've
> done the same CoC for freedesktop.org and all the graphics stuff
> hosted there, there's been years of hallway track preceeding formally
> enacting the CoC. Social expectations on the mailing list already
> reflected the consensus that we expect constructive and respectful
> collaboration, with informal peer driven enforcement when a maintainer
> went a bit over the line. We also had pretty much everyone ack the
> documentation patch before it landed. In other words, nothing changed
> for dri-devel when we've done this ~2 years ago, except the already
> lived expectations have been encoded.
>
> As much as I welcome this as a first step on a fairly long path, it
> does feel rushed since it seems to have happened in just ~10 days.
> From chatting with people, I think this left a lot wondering about
> what's really going on, with interesting conspiracy theories running
> rampant. Personally I have serious worries that to rapid change will
> overwhelm the community's ability to process it, with ugly unintended
> consequences.

Indeed, it feels a bit... rushed.

Commit ddbd2b7ad99a418c ("Code of Conflict") was acked by 66 developers.
Bringing up the analogy with other source tree changes, I would expect a
patch ripping out a substantial piece of code to be CCed to the people that
acked its original introduction. Obviously that's not what happened here.

Disclaimer: the above doesn't say anything about the merits of the new CoC.

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] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Tue, 18 Sep 2018 10:02:08 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> > After the past 2-3 days I get the feeling there are maintainers
> > unsure about how this affects them and I think assuaging those fears
> > might be a good thing.
> > 

> From my perspective, which is probably fairly widespread: we're already
> pretty much policing the lists using a set of rules which match fairly
> closely to the new CoC, so there should really be no huge impact.

After carefully reading it a couple of times, I think it has a huge
impact.

The more immediate impact is with regards to this wording:

	"Examples of unacceptable behavior by participants include:
	...
	* Publishing others’ private information, such as a physical or electronic
	  address, without explicit permission"

When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
Requested-by, Suggested-by, etc, we are actually publishing an electronic
address.

The DCO 1.1 has an explicit clause that would allow to publish the
email address from the SOB's, together to its redistribution:

"       (d) I understand and agree that this project and the contribution
            are public and that a record of the contribution (including all
            personal information I submit with it, including my sign-off) is
            maintained indefinitely and may be redistributed consistent with
            this project or the open source license(s) involved."

But that doesn't cover the other tags.

We should solve this quickly, as otherwise maintainers may need to postpone
asking for pulling from any branches on trees that contain patches with
such tags.

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Josh Triplett]

On Tue, Sep 18, 2018 at 04:29:48PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Sep 2018 10:02:08 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
> > > After the past 2-3 days I get the feeling there are maintainers
> > > unsure about how this affects them and I think assuaging those fears
> > > might be a good thing.
> > > 
> 
> > From my perspective, which is probably fairly widespread: we're already
> > pretty much policing the lists using a set of rules which match fairly
> > closely to the new CoC, so there should really be no huge impact.
> 
> After carefully reading it a couple of times, I think it has a huge
> impact.
> 
> The more immediate impact is with regards to this wording:
> 
> 	"Examples of unacceptable behavior by participants include:
> 	...
> 	* Publishing others’ private information, such as a physical or electronic
> 	  address, without explicit permission"
> 
> When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> Requested-by, Suggested-by, etc, we are actually publishing an electronic
> address.

If they've posted public mails from that email address, that isn't
"private information" at that point. And in any case someone offering
such a tag would constitute permission.

(Publishing someone's private, otherwise-unpublished email address in an
Acked-by, on the other hand, *could* be problematic. Don't do that.)

Nonetheless, it probably couldn't hurt to have some notes on this
situation somewhere.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Tue, 18 Sep 2018 12:36:45 -0700
Josh Triplett <josh@joshtriplett.org> escreveu:

> On Tue, Sep 18, 2018 at 04:29:48PM -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 18 Sep 2018 10:02:08 -0400
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> >   
> > > > After the past 2-3 days I get the feeling there are maintainers
> > > > unsure about how this affects them and I think assuaging those fears
> > > > might be a good thing.
> > > >   
> >   
> > > From my perspective, which is probably fairly widespread: we're already
> > > pretty much policing the lists using a set of rules which match fairly
> > > closely to the new CoC, so there should really be no huge impact.  
> > 
> > After carefully reading it a couple of times, I think it has a huge
> > impact.
> > 
> > The more immediate impact is with regards to this wording:
> > 
> > 	"Examples of unacceptable behavior by participants include:
> > 	...
> > 	* Publishing others’ private information, such as a physical or electronic
> > 	  address, without explicit permission"
> > 
> > When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> > Requested-by, Suggested-by, etc, we are actually publishing an electronic
> > address.  
> 
> If they've posted public mails from that email address, that isn't
> "private information" at that point. And in any case someone offering
> such a tag would constitute permission.

Good point, but I'm pretty sure it opens multiple interpretation, as
it explicitly forbids using "electronic address without explicit
permission".

> (Publishing someone's private, otherwise-unpublished email address in an
> Acked-by, on the other hand, *could* be problematic. Don't do that.)

Well, Requested-by, Suggested-by (and sometimes tested-by) is sometimes
added by the maintainer (or by the patch writer).

> Nonetheless, it probably couldn't hurt to have some notes on this
> situation somewhere.

Yes, that's my point: that part of the CoC should explicitly exclude any
electronic addresses that are used on public community-related channels,
specially on e-mail [1].

Thanks,
Mauro

[1] While this is not common, I merged in the past some patches whose
developer included parts of discussions that happened at freenode's
public IRC channels related to the project.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Arnaldo Carvalho de Melo]

Em Tue, Sep 18, 2018 at 04:29:48PM -0300, Mauro Carvalho Chehab escreveu:
> Em Tue, 18 Sep 2018 10:02:08 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
> > > After the past 2-3 days I get the feeling there are maintainers
> > > unsure about how this affects them and I think assuaging those fears
> > > might be a good thing.
> > > 
> 
> > From my perspective, which is probably fairly widespread: we're already
> > pretty much policing the lists using a set of rules which match fairly
> > closely to the new CoC, so there should really be no huge impact.
> 
> After carefully reading it a couple of times, I think it has a huge
> impact.
> 
> The more immediate impact is with regards to this wording:
> 
> 	"Examples of unacceptable behavior by participants include:
> 	...
> 	* Publishing others’ private information, such as a physical or electronic
> 	  address, without explicit permission"
> 
> When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> Requested-by, Suggested-by, etc, we are actually publishing an electronic
> address.
> 
> The DCO 1.1 has an explicit clause that would allow to publish the
> email address from the SOB's, together to its redistribution:
> 
> "       (d) I understand and agree that this project and the contribution
>             are public and that a record of the contribution (including all
>             personal information I submit with it, including my sign-off) is
>             maintained indefinitely and may be redistributed consistent with
>             this project or the open source license(s) involved."
> 
> But that doesn't cover the other tags.
> 
> We should solve this quickly, as otherwise maintainers may need to postpone
> asking for pulling from any branches on trees that contain patches with
> such tags.

Right, this would have to be rephrased, to say that no manual convertion
should be performed anymore:

-----------------------------------------------------------------------------------
Acked-by: is not as formal as Signed-off-by:.  It is a record that the acker
has at least reviewed the patch and has indicated acceptance.  Hence patch
mergers will sometimes manually convert an acker's "yep, looks good to me"
into an Acked-by: (but note that it is usually better to ask for an
explicit ack).
--------------------------------------------------------------------------------

- Arnaldo

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Takashi Iwai]

On Tue, 18 Sep 2018 21:52:03 +0200,
Mauro Carvalho Chehab wrote:
> 
> Em Tue, 18 Sep 2018 12:36:45 -0700
> Josh Triplett <josh@joshtriplett.org> escreveu:
> 
> > On Tue, Sep 18, 2018 at 04:29:48PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > >   
> > > > > After the past 2-3 days I get the feeling there are maintainers
> > > > > unsure about how this affects them and I think assuaging those fears
> > > > > might be a good thing.
> > > > >   
> > >   
> > > > From my perspective, which is probably fairly widespread: we're already
> > > > pretty much policing the lists using a set of rules which match fairly
> > > > closely to the new CoC, so there should really be no huge impact.  
> > > 
> > > After carefully reading it a couple of times, I think it has a huge
> > > impact.
> > > 
> > > The more immediate impact is with regards to this wording:
> > > 
> > > 	"Examples of unacceptable behavior by participants include:
> > > 	...
> > > 	* Publishing others’ private information, such as a physical or electronic
> > > 	  address, without explicit permission"
> > > 
> > > When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> > > Requested-by, Suggested-by, etc, we are actually publishing an electronic
> > > address.  
> > 
> > If they've posted public mails from that email address, that isn't
> > "private information" at that point. And in any case someone offering
> > such a tag would constitute permission.
> 
> Good point, but I'm pretty sure it opens multiple interpretation, as
> it explicitly forbids using "electronic address without explicit
> permission".
> 
> > (Publishing someone's private, otherwise-unpublished email address in an
> > Acked-by, on the other hand, *could* be problematic. Don't do that.)
> 
> Well, Requested-by, Suggested-by (and sometimes tested-by) is sometimes
> added by the maintainer (or by the patch writer).

Right, such tags are often used as credits of contributions, too.

Since they are no mandatory stuff like Signed-off-by, we may drop the
address part, though.


Takashi

> > Nonetheless, it probably couldn't hurt to have some notes on this
> > situation somewhere.
> 
> Yes, that's my point: that part of the CoC should explicitly exclude any
> electronic addresses that are used on public community-related channels,
> specially on e-mail [1].
> 
> Thanks,
> Mauro
> 
> [1] While this is not common, I merged in the past some patches whose
> developer included parts of discussions that happened at freenode's
> public IRC channels related to the project.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Josh Triplett]

On Tue, Sep 18, 2018 at 04:52:03PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Sep 2018 12:36:45 -0700
> Josh Triplett <josh@joshtriplett.org> escreveu:
> > Nonetheless, it probably couldn't hurt to have some notes on this
> > situation somewhere.
> 
> Yes, that's my point: that part of the CoC should explicitly exclude any
> electronic addresses that are used on public community-related channels,
> specially on e-mail [1].

s/that part of the CoC should/we should (in accompanying documentation
on how we apply it/, but otherwise yes.

(By way of analogy, the GPL FAQ is not part of the GPL.)

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Steven Rostedt]

On Tue, 18 Sep 2018 12:36:45 -0700
Josh Triplett <josh@joshtriplett.org> wrote:

> > When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> > Requested-by, Suggested-by, etc, we are actually publishing an electronic
> > address.  
> 
> If they've posted public mails from that email address, that isn't
> "private information" at that point. And in any case someone offering
> such a tag would constitute permission.
> 
> (Publishing someone's private, otherwise-unpublished email address in an
> Acked-by, on the other hand, *could* be problematic. Don't do that.)

And this has been my work flow all along. I'm very conscience of taking
someone's email and publishing it in a "Reported-by". I will first send
an email to the submitter and ask if it is OK to include them if they
sent me the bug report privately.

But yes, if someone sends me a report and Cc's LKML, I will add the
Reported-by with the email address that they used to a public address
without any confirmation.

-- Steve

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Laurent Pinchart]

On Wednesday, 19 September 2018 02:06:18 EEST Steven Rostedt wrote:
> On Tue, 18 Sep 2018 12:36:45 -0700 Josh Triplett  wrote:
> > > When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> > > Requested-by, Suggested-by, etc, we are actually publishing an
> > > electronic
> > > address.
> > 
> > If they've posted public mails from that email address, that isn't
> > "private information" at that point. And in any case someone offering
> > such a tag would constitute permission.
> > 
> > (Publishing someone's private, otherwise-unpublished email address in an
> > Acked-by, on the other hand, *could* be problematic. Don't do that.)
> 
> And this has been my work flow all along. I'm very conscience of taking
> someone's email and publishing it in a "Reported-by". I will first send
> an email to the submitter and ask if it is OK to include them if they
> sent me the bug report privately.
> 
> But yes, if someone sends me a report and Cc's LKML, I will add the
> Reported-by with the email address that they used to a public address
> without any confirmation.

Taking a step back, I'd like to clarify the intent of this specific provision 
before discussing its working or any FAQ entry that we believe is needed.

As I understand it, the intent is to avoid individuals being put under the 
spotlight without consent, with the risks of harassment that could follow (or, 
probably usual in the problematic cases, with the disclosure already being 
part of a harassment campaign).

If that assumption is correct, I believe we could clarify the intent by 
stating that (probably reworded by a better English speaker than me) is 
excluded from private information in the context of a public communication any 
information already posted to public channels in the same context (the context 
is important here, as if someone digs up messages I posted, let's say on 
health-related public forums, with my name hidden but associated with the same 
e-mail address, those would still be private information).

Additionally, and this applies more broadly, I believe it would be useful to 
clearly state that accidental disclosure of private information that could 
reasonably not be interpreted as private by the discloser will not result in 
immediate retaliation on the first occurrence. The goal of the code of 
conduct, as I interpret it, is to define the generally accepted an unaccepted 
behaviour, not to be used as an excuse to punish anyone.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[James Bottomley]

On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Sep 2018 10:02:08 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
> > > After the past 2-3 days I get the feeling there are maintainers
> > > unsure about how this affects them and I think assuaging those
> > > fears might be a good thing.
> > > 
> > 
> > From my perspective, which is probably fairly widespread: we're
> > already pretty much policing the lists using a set of rules which
> > match fairly closely to the new CoC, so there should really be no
> > huge impact.
> 
> After carefully reading it a couple of times, I think it has a huge
> impact.
> 
> The more immediate impact is with regards to this wording:
> 
> 	"Examples of unacceptable behavior by participants include:
> 	...
> 	* Publishing others’ private information, such as a physical or
> electronic
> 	  address, without explicit permission"
> 
> When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> Requested-by, Suggested-by, etc, we are actually publishing an
> electronic address.
> 
> The DCO 1.1 has an explicit clause that would allow to publish the
> email address from the SOB's, together to its redistribution:
> 
> "       (d) I understand and agree that this project and the
> contribution
>             are public and that a record of the contribution
> (including all
>             personal information I submit with it, including my sign-
> off) is
>             maintained indefinitely and may be redistributed
> consistent with
>             this project or the open source license(s) involved."
> 
> But that doesn't cover the other tags.

I disagree with the strictness of the interpretation: "including all
personal information I submit with it" covers all the other tags.
Although the expectation is the permission was obtained by one of the
people adding the sign off because that's how the DCO flows, which
might be a bit wishful thinking, we've always thought that it covers
the additional tags for the use case section (d) was created for:
national data protection acts and if it covers that case, it surely
covers the CoC permission case.

Additionally, as others have said, if the tag was added from
information in the public mailing list, it's not private within the
meaning of the CoC.  I think the electronic mail example in the CoC is
simply because it's more used in a github type environment where email
addresses are private and not necessarily part of the workflow.

James

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Wed, 19 Sep 2018 07:28:02 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > Em Tue, 18 Sep 2018 10:02:08 -0400
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> >   
> > > > After the past 2-3 days I get the feeling there are maintainers
> > > > unsure about how this affects them and I think assuaging those
> > > > fears might be a good thing.
> > > >   
> > > 
> > > From my perspective, which is probably fairly widespread: we're
> > > already pretty much policing the lists using a set of rules which
> > > match fairly closely to the new CoC, so there should really be no
> > > huge impact.  
> > 
> > After carefully reading it a couple of times, I think it has a huge
> > impact.
> > 
> > The more immediate impact is with regards to this wording:
> > 
> > 	"Examples of unacceptable behavior by participants include:
> > 	...
> > 	* Publishing others’ private information, such as a physical or
> > electronic
> > 	  address, without explicit permission"
> > 
> > When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> > Requested-by, Suggested-by, etc, we are actually publishing an
> > electronic address.
> > 
> > The DCO 1.1 has an explicit clause that would allow to publish the
> > email address from the SOB's, together to its redistribution:
> > 
> > "       (d) I understand and agree that this project and the
> > contribution
> >             are public and that a record of the contribution
> > (including all
> >             personal information I submit with it, including my sign-
> > off) is
> >             maintained indefinitely and may be redistributed
> > consistent with
> >             this project or the open source license(s) involved."
> > 
> > But that doesn't cover the other tags.  
> 
> I disagree with the strictness of the interpretation: "including all
> personal information I submit with it" covers all the other tags.
> Although the expectation is the permission was obtained by one of the
> people adding the sign off because that's how the DCO flows, which
> might be a bit wishful thinking, we've always thought that it covers
> the additional tags for the use case section (d) was created for:
> national data protection acts and if it covers that case, it surely
> covers the CoC permission case.

I see your point. Yes, that places the SOB signer's as^W backs 
responsible for such thing.

> Additionally, as others have said, if the tag was added from
> information in the public mailing list, it's not private within the
> meaning of the CoC.  I think the electronic mail example in the CoC is
> simply because it's more used in a github type environment where email
> addresses are private and not necessarily part of the workflow.

If it doesn't apply, it should be removed. Legal documents with
unneeded terms only cause confusion (and this *is* a legal document - a
IMHO very badly written Contract of Adhesion - as it creates a lot of
new duties to maintainers and establishes punishment measures if the
terms of such contract are violated).

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Wed, 19 Sep 2018 08:37:49 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:

> Em Wed, 19 Sep 2018 07:28:02 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
> > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > >   
> > > > > After the past 2-3 days I get the feeling there are maintainers
> > > > > unsure about how this affects them and I think assuaging those
> > > > > fears might be a good thing.
> > > > >   
> > > > 
> > > > From my perspective, which is probably fairly widespread: we're
> > > > already pretty much policing the lists using a set of rules which
> > > > match fairly closely to the new CoC, so there should really be no
> > > > huge impact.  
> > > 
> > > After carefully reading it a couple of times, I think it has a huge
> > > impact.
> > > 
> > > The more immediate impact is with regards to this wording:
> > > 
> > > 	"Examples of unacceptable behavior by participants include:
> > > 	...
> > > 	* Publishing others’ private information, such as a physical or
> > > electronic
> > > 	  address, without explicit permission"
> > > 
> > > When we publish a patch with a Signed-off-by, Reviewed-by, Acked-by,
> > > Requested-by, Suggested-by, etc, we are actually publishing an
> > > electronic address.
> > > 
> > > The DCO 1.1 has an explicit clause that would allow to publish the
> > > email address from the SOB's, together to its redistribution:
> > > 
> > > "       (d) I understand and agree that this project and the
> > > contribution
> > >             are public and that a record of the contribution
> > > (including all
> > >             personal information I submit with it, including my sign-
> > > off) is
> > >             maintained indefinitely and may be redistributed
> > > consistent with
> > >             this project or the open source license(s) involved."
> > > 
> > > But that doesn't cover the other tags.  
> > 
> > I disagree with the strictness of the interpretation: "including all
> > personal information I submit with it" covers all the other tags.
> > Although the expectation is the permission was obtained by one of the
> > people adding the sign off because that's how the DCO flows, which
> > might be a bit wishful thinking, we've always thought that it covers
> > the additional tags for the use case section (d) was created for:
> > national data protection acts and if it covers that case, it surely
> > covers the CoC permission case.
> 
> I see your point. Yes, that places the SOB signer's as^W backs 
> responsible for such thing.
> 
> > Additionally, as others have said, if the tag was added from
> > information in the public mailing list, it's not private within the
> > meaning of the CoC.  I think the electronic mail example in the CoC is
> > simply because it's more used in a github type environment where email
> > addresses are private and not necessarily part of the workflow.
> 
> If it doesn't apply, it should be removed. Legal documents with
> unneeded terms only cause confusion (and this *is* a legal document - a

In time:
	and this *is* a legal document -> I believe that this is a legal document

I'm actually waiting for a legal advice about this under US laws.
Under Brazilian laws (and probably other civil law system), I'm almost
sure it is a contract - if this is a valid or a void one has yet to be
seen.

> IMHO very badly written Contract of Adhesion - as it creates a lot of
> new duties to maintainers and establishes punishment measures if the
> terms of such contract are violated).
> 
> Thanks,
> Mauro



Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[James Bottomley]

On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 19 Sep 2018 08:37:49 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> 
> > Em Wed, 19 Sep 2018 07:28:02 -0400
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > 
> > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > escreveu:
> > > >   
> > > > > > After the past 2-3 days I get the feeling there are
> > > > > > maintainers unsure about how this affects them and I think
> > > > > > assuaging those fears might be a good thing.
> > > > > >   
> > > > > 
> > > > > From my perspective, which is probably fairly widespread:
> > > > > we're already pretty much policing the lists using a set of
> > > > > rules which match fairly closely to the new CoC, so there
> > > > > should really be no huge impact.  
> > > > 
> > > > After carefully reading it a couple of times, I think it has a
> > > > huge impact.
> > > > 
> > > > The more immediate impact is with regards to this wording:
> > > > 
> > > > 	"Examples of unacceptable behavior by participants
> > > > include:
> > > > 	...
> > > > 	* Publishing others’ private information, such as a
> > > > physical or electronic
> > > > 	  address, without explicit permission"
> > > > 
> > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > publishing an electronic address.
> > > > 
> > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > the email address from the SOB's, together to its
> > > > redistribution:
> > > > 
> > > > "       (d) I understand and agree that this project and the
> > > > contribution
> > > >             are public and that a record of the contribution
> > > > (including all
> > > >             personal information I submit with it, including my
> > > > sign-off) is
> > > >             maintained indefinitely and may be redistributed
> > > > consistent with
> > > >             this project or the open source license(s)
> > > > involved."
> > > > 
> > > > But that doesn't cover the other tags.  
> > > 
> > > I disagree with the strictness of the interpretation: "including
> > > all personal information I submit with it" covers all the other
> > > tags. Although the expectation is the permission was obtained by
> > > one of the people adding the sign off because that's how the DCO
> > > flows, which might be a bit wishful thinking, we've always
> > > thought that it covers the additional tags for the use case
> > > section (d) was created for: national data protection acts and if
> > > it covers that case, it surely covers the CoC permission case.
> > 
> > I see your point. Yes, that places the SOB signer's as^W backs 
> > responsible for such thing.
> > 
> > > Additionally, as others have said, if the tag was added from
> > > information in the public mailing list, it's not private within
> > > the meaning of the CoC.  I think the electronic mail example in
> > > the CoC is simply because it's more used in a github type
> > > environment where email addresses are private and not necessarily
> > > part of the workflow.
> > 
> > If it doesn't apply, it should be removed. Legal documents with
> > unneeded terms only cause confusion (and this *is* a legal document
> > - a
> 
> In time:
> 	and this *is* a legal document -> I believe that this is a
> legal document
> 
> I'm actually waiting for a legal advice about this under US laws.
> Under Brazilian laws (and probably other civil law system), I'm
> almost sure it is a contract - if this is a valid or a void one has
> yet to be seen.

OK, I can't disagree with this.  It does definitely impose obligations
that are legally meaningful.  However ...

> > IMHO very badly written Contract of Adhesion - as it creates a lot
> > of new duties to maintainers and establishes punishment measures if
> > the terms of such contract are violated).

I can't disagree with that either.  Unfortunately, most codes of
conduct are definitely badly written from a legal point of view because
they're usually constructed by non-lawyers without any legal input. 
I'm not very keen on this one because, as I said somewhere upthread, it
doesn't cover a lot of our problem areas.  However, it's not the worst
I've seen.

To your specific concern, run this thought experiment with me: 
Supposing instead of  "Publishing others’ private information, such as
a physical or electronic address, without explicit permission", it had
said "publishing others non-public information ...." (sorry had to
correct the misplaced apostrophe as well).  I think you can agree with
me that an email address already sent to the list cannot be non-public, 
since it's already been disclosed by the sender in a public forum.  So
with that form of wording it would cover the tags use case, right?

Now let me point out that from a US legal point of view, "non-public"
encompasses a broader range of things than "private", so anything
that's private is also non-public but not everything that's non-public
is also private.  Thus the original wording is actually a narrower duty
which is a strict subset of the form of wording I asked you to
consider.  Thus, I still don't think our use of tags resulting from
public email exchanges can be in any way construed as a violation of
the privacy duty imposed by the CoC.

James

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Wed, 19 Sep 2018 10:16:21 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 19 Sep 2018 08:37:49 -0300
> > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> >   
> > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > >   
> > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:  
> > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > escreveu:
> > > > >     
> > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > assuaging those fears might be a good thing.
> > > > > > >     
> > > > > > 
> > > > > > From my perspective, which is probably fairly widespread:
> > > > > > we're already pretty much policing the lists using a set of
> > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > should really be no huge impact.    
> > > > > 
> > > > > After carefully reading it a couple of times, I think it has a
> > > > > huge impact.
> > > > > 
> > > > > The more immediate impact is with regards to this wording:
> > > > > 
> > > > > 	"Examples of unacceptable behavior by participants
> > > > > include:
> > > > > 	...
> > > > > 	* Publishing others’ private information, such as a
> > > > > physical or electronic
> > > > > 	  address, without explicit permission"
> > > > > 
> > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > publishing an electronic address.
> > > > > 
> > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > the email address from the SOB's, together to its
> > > > > redistribution:
> > > > > 
> > > > > "       (d) I understand and agree that this project and the
> > > > > contribution
> > > > >             are public and that a record of the contribution
> > > > > (including all
> > > > >             personal information I submit with it, including my
> > > > > sign-off) is
> > > > >             maintained indefinitely and may be redistributed
> > > > > consistent with
> > > > >             this project or the open source license(s)
> > > > > involved."
> > > > > 
> > > > > But that doesn't cover the other tags.    
> > > > 
> > > > I disagree with the strictness of the interpretation: "including
> > > > all personal information I submit with it" covers all the other
> > > > tags. Although the expectation is the permission was obtained by
> > > > one of the people adding the sign off because that's how the DCO
> > > > flows, which might be a bit wishful thinking, we've always
> > > > thought that it covers the additional tags for the use case
> > > > section (d) was created for: national data protection acts and if
> > > > it covers that case, it surely covers the CoC permission case.  
> > > 
> > > I see your point. Yes, that places the SOB signer's as^W backs 
> > > responsible for such thing.
> > >   
> > > > Additionally, as others have said, if the tag was added from
> > > > information in the public mailing list, it's not private within
> > > > the meaning of the CoC.  I think the electronic mail example in
> > > > the CoC is simply because it's more used in a github type
> > > > environment where email addresses are private and not necessarily
> > > > part of the workflow.  
> > > 
> > > If it doesn't apply, it should be removed. Legal documents with
> > > unneeded terms only cause confusion (and this *is* a legal document
> > > - a  
> > 
> > In time:
> > 	and this *is* a legal document -> I believe that this is a
> > legal document
> > 
> > I'm actually waiting for a legal advice about this under US laws.
> > Under Brazilian laws (and probably other civil law system), I'm
> > almost sure it is a contract - if this is a valid or a void one has
> > yet to be seen.  
> 
> OK, I can't disagree with this.  It does definitely impose obligations
> that are legally meaningful.  However ...
> 
> > > IMHO very badly written Contract of Adhesion - as it creates a lot
> > > of new duties to maintainers and establishes punishment measures if
> > > the terms of such contract are violated).  
> 
> I can't disagree with that either.  Unfortunately, most codes of
> conduct are definitely badly written from a legal point of view because
> they're usually constructed by non-lawyers without any legal input. 
> I'm not very keen on this one because, as I said somewhere upthread, it
> doesn't cover a lot of our problem areas.  However, it's not the worst
> I've seen.

Well, we don't need to stick with it. If it has solvable problems,
they should be fixed. Otherwise, better to revert this patch and keep
using the old CoC, where the major ideas are already covered, but with
a language that won't cause too much legal problems.

Every time I read the new CoC I become more convinced that it is
utter crap (can I say it with this new Coc?). The email address
issue is just the tip of the iceberg.

> To your specific concern, run this thought experiment with me: 
> Supposing instead of  "Publishing others’ private information, such as
> a physical or electronic address, without explicit permission", it had
> said "publishing others non-public information ...." (sorry had to
> correct the misplaced apostrophe as well).  I think you can agree with
> me that an email address already sent to the list cannot be non-public, 
> since it's already been disclosed by the sender in a public forum.  So
> with that form of wording it would cover the tags use case, right?
> 
> Now let me point out that from a US legal point of view, "non-public"
> encompasses a broader range of things than "private", so anything
> that's private is also non-public but not everything that's non-public
> is also private.  Thus the original wording is actually a narrower duty
> which is a strict subset of the form of wording I asked you to
> consider.  Thus, I still don't think our use of tags resulting from
> public email exchanges can be in any way construed as a violation of
> the privacy duty imposed by the CoC.

I understand your point, but the concept of "public/non-public",
"private", "personal information", etc actually depends on how it
is defined. It should either be clearly stated or the document, 
or whatever the legislation says would be valid (or judge's mind).

I suspect that, in US, the concept of non-public and private can
even vary from state to state, or even from district to district,
as local legislators may have approved laws defining it for
electronic communications. It is even worse if we consider other
Countries with a different ruleset.

That's why, on most legal contracts there are clauses that specify
what it actually cover, instead of too broader terms like the ones
used on this CoC.

For example LF web site privacy policy - with very likely it was
written by some lawyers[1] states that e-mail addresses are 
Personal information.

[1] https://www.linuxfoundation.org/privacy/

At the "Sharing of Personal Information" chapter, it then defines
a concept of "Publicly Available Information", saying that those
can be disclosed.

-

What I'm trying to say that, while I'm fine with the idea of having
a CoC, it should either be prepared by someone that understands
what legal impacts it will cause (e. g. some lawyers that understands
open source), or it shouldn't be adding stuff that will just cause
more evil than good.

See, the points that this new CoC tries to address (on a very bad
way) were already covered by the past CoC:

-Code of Conflict
-----------------
-
-The Linux kernel development effort is a very personal process compared
-to "traditional" ways of developing software.  Your code and ideas
-behind it will be carefully reviewed, often resulting in critique and
-criticism.  The review will almost always require improvements to the
-code before it can be included in the kernel.  Know that this happens
-because everyone involved wants to see the best possible solution for
-the overall success of Linux.  This development process has been proven
-to create the most robust operating system kernel ever, and we do not
-want to do anything to cause the quality of submission and eventual
-result to ever decrease.
-
-If however, anyone feels personally abused, threatened, or otherwise
-uncomfortable due to this process, that is not acceptable.  If so,
-please contact the Linux Foundation's Technical Advisory Board at
-<tab@lists.linux-foundation.org>, or the individual members, and they
-will work to resolve the issue to the best of their ability.  For more
-information on who is on the Technical Advisory Board and what their
-role is, please see:
-
-	- http://www.linuxfoundation.org/projects/linux/tab
-
-As a reviewer of code, please strive to keep things civil and focused on
-the technical issues involved.  We are all humans, and frustrations can
-be high on both sides of the process.  Try to keep in mind the immortal
-words of Bill and Ted, "Be excellent to each other."

The old one doesn't prevent using Reviewed-by/Acked-by/... tags.

It also doesn't turn maintainers into baby sitters, making them
accountable for any bad behavior on every place where a member
of the community misbehaves.

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Wed, 19 Sep 2018 10:16:21 -0400
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 19 Sep 2018 08:37:49 -0300
> > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> > 
> > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > > 
> > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > escreveu:
> > > > >   
> > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > assuaging those fears might be a good thing.
> > > > > > >   
> > > > > > 
> > > > > > From my perspective, which is probably fairly widespread:
> > > > > > we're already pretty much policing the lists using a set of
> > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > should really be no huge impact.  
> > > > > 
> > > > > After carefully reading it a couple of times, I think it has a
> > > > > huge impact.
> > > > > 
> > > > > The more immediate impact is with regards to this wording:
> > > > > 
> > > > > 	"Examples of unacceptable behavior by participants
> > > > > include:
> > > > > 	...
> > > > > 	* Publishing others’ private information, such as a
> > > > > physical or electronic
> > > > > 	  address, without explicit permission"
> > > > > 
> > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > publishing an electronic address.
> > > > > 
> > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > the email address from the SOB's, together to its
> > > > > redistribution:
> > > > > 
> > > > > "       (d) I understand and agree that this project and the
> > > > > contribution
> > > > >             are public and that a record of the contribution
> > > > > (including all
> > > > >             personal information I submit with it, including my
> > > > > sign-off) is
> > > > >             maintained indefinitely and may be redistributed
> > > > > consistent with
> > > > >             this project or the open source license(s)
> > > > > involved."
> > > > > 
> > > > > But that doesn't cover the other tags.  
> > > > 
> > > > I disagree with the strictness of the interpretation: "including
> > > > all personal information I submit with it" covers all the other
> > > > tags. Although the expectation is the permission was obtained by
> > > > one of the people adding the sign off because that's how the DCO
> > > > flows, which might be a bit wishful thinking, we've always
> > > > thought that it covers the additional tags for the use case
> > > > section (d) was created for: national data protection acts and if
> > > > it covers that case, it surely covers the CoC permission case.
> > > 
> > > I see your point. Yes, that places the SOB signer's as^W backs 
> > > responsible for such thing.
> > > 
> > > > Additionally, as others have said, if the tag was added from
> > > > information in the public mailing list, it's not private within
> > > > the meaning of the CoC.  I think the electronic mail example in
> > > > the CoC is simply because it's more used in a github type
> > > > environment where email addresses are private and not necessarily
> > > > part of the workflow.
> > > 
> > > If it doesn't apply, it should be removed. Legal documents with
> > > unneeded terms only cause confusion (and this *is* a legal document
> > > - a
> > 
> > In time:
> > 	and this *is* a legal document -> I believe that this is a
> > legal document
> > 
> > I'm actually waiting for a legal advice about this under US laws.
> > Under Brazilian laws (and probably other civil law system), I'm
> > almost sure it is a contract - if this is a valid or a void one has
> > yet to be seen.
> 
> OK, I can't disagree with this.  It does definitely impose obligations
> that are legally meaningful.  However ...
> 
> > > IMHO very badly written Contract of Adhesion - as it creates a lot
> > > of new duties to maintainers and establishes punishment measures if
> > > the terms of such contract are violated).
> 
> I can't disagree with that either.  Unfortunately, most codes of
> conduct are definitely badly written from a legal point of view because
> they're usually constructed by non-lawyers without any legal input. 
> I'm not very keen on this one because, as I said somewhere upthread, it
> doesn't cover a lot of our problem areas.  However, it's not the worst
> I've seen.
> 
> To your specific concern, run this thought experiment with me: 
> Supposing instead of  "Publishing others’ private information, such as
> a physical or electronic address, without explicit permission", it had
> said "publishing others non-public information ...." (sorry had to
> correct the misplaced apostrophe as well).  I think you can agree with
> me that an email address already sent to the list cannot be non-public, 
> since it's already been disclosed by the sender in a public forum.  So
> with that form of wording it would cover the tags use case, right?
> 
> Now let me point out that from a US legal point of view, "non-public"
> encompasses a broader range of things than "private", so anything
> that's private is also non-public but not everything that's non-public
> is also private.  Thus the original wording is actually a narrower duty
> which is a strict subset of the form of wording I asked you to
> consider.  Thus, I still don't think our use of tags resulting from
> public email exchanges can be in any way construed as a violation of
> the privacy duty imposed by the CoC.

After re-reading it, I'm pretty sure that, the way it is, publishing
e-mails violate this CoC.

The thing is that, when it uses the commas there:

	"private information, such as a physical or electronic address," 

The commas actually defines what "private information" is. Even if
this would be changed by "foo information", what we have here is actually two
English sentences that were merged together:

First sentence:
	"Private information, such as a physical or electronic address."

Second sentence:
	"Publishing others’ private information without explicit permission"

See, replace it by foo at the original text:
	"Publishing others’ *foo* information, such as a physical 
	 or electronic address, without explicit permission"

You'll see that "*foo* information" becomes defined.


Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Luck, Tony]

On Wed, Sep 19, 2018 at 04:55:52PM -0300, Mauro Carvalho Chehab wrote:
> After re-reading it, I'm pretty sure that, the way it is, publishing
> e-mails violate this CoC.
> 
> The thing is that, when it uses the commas there:
> 
> 	"private information, such as a physical or electronic address," 
> 
> The commas actually defines what "private information" is. Even if
> this would be changed by "foo information", what we have here is actually two
> English sentences that were merged together:
> 
> First sentence:
> 	"Private information, such as a physical or electronic address."
> 
> Second sentence:
> 	"Publishing others’ private information without explicit permission"
> 
> See, replace it by foo at the original text:
> 	"Publishing others’ *foo* information, such as a physical 
> 	 or electronic address, without explicit permission"
> 
> You'll see that "*foo* information" becomes defined.

So perhaps we can move on to discussing a patch to fix it?


diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..ec99a17ab646 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -31,10 +31,13 @@ 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[1], without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
+[1] Note that e-mail addresses used on public mailing lists are not
+considered to be private information and can (in fact should) be used
+to give credit in Reported-by, Acked-by, Tested-by etc. tags.
 
 Our Responsibilities
 ====================

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Dave Airlie]

On Thu, 20 Sep 2018 at 05:56, Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Em Wed, 19 Sep 2018 10:16:21 -0400
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
>
> > On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> > > Em Wed, 19 Sep 2018 08:37:49 -0300
> > > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> > >
> > > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > > >
> > > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > > escreveu:
> > > > > >
> > > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > > assuaging those fears might be a good thing.
> > > > > > > >
> > > > > > >
> > > > > > > From my perspective, which is probably fairly widespread:
> > > > > > > we're already pretty much policing the lists using a set of
> > > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > > should really be no huge impact.
> > > > > >
> > > > > > After carefully reading it a couple of times, I think it has a
> > > > > > huge impact.
> > > > > >
> > > > > > The more immediate impact is with regards to this wording:
> > > > > >
> > > > > >       "Examples of unacceptable behavior by participants
> > > > > > include:
> > > > > >       ...
> > > > > >       * Publishing others’ private information, such as a
> > > > > > physical or electronic
> > > > > >         address, without explicit permission"
> > > > > >
> > > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > > publishing an electronic address.
> > > > > >
> > > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > > the email address from the SOB's, together to its
> > > > > > redistribution:
> > > > > >
> > > > > > "       (d) I understand and agree that this project and the
> > > > > > contribution
> > > > > >             are public and that a record of the contribution
> > > > > > (including all
> > > > > >             personal information I submit with it, including my
> > > > > > sign-off) is
> > > > > >             maintained indefinitely and may be redistributed
> > > > > > consistent with
> > > > > >             this project or the open source license(s)
> > > > > > involved."
> > > > > >
> > > > > > But that doesn't cover the other tags.
> > > > >
> > > > > I disagree with the strictness of the interpretation: "including
> > > > > all personal information I submit with it" covers all the other
> > > > > tags. Although the expectation is the permission was obtained by
> > > > > one of the people adding the sign off because that's how the DCO
> > > > > flows, which might be a bit wishful thinking, we've always
> > > > > thought that it covers the additional tags for the use case
> > > > > section (d) was created for: national data protection acts and if
> > > > > it covers that case, it surely covers the CoC permission case.
> > > >
> > > > I see your point. Yes, that places the SOB signer's as^W backs
> > > > responsible for such thing.
> > > >
> > > > > Additionally, as others have said, if the tag was added from
> > > > > information in the public mailing list, it's not private within
> > > > > the meaning of the CoC.  I think the electronic mail example in
> > > > > the CoC is simply because it's more used in a github type
> > > > > environment where email addresses are private and not necessarily
> > > > > part of the workflow.
> > > >
> > > > If it doesn't apply, it should be removed. Legal documents with
> > > > unneeded terms only cause confusion (and this *is* a legal document
> > > > - a
> > >
> > > In time:
> > >     and this *is* a legal document -> I believe that this is a
> > > legal document
> > >
> > > I'm actually waiting for a legal advice about this under US laws.
> > > Under Brazilian laws (and probably other civil law system), I'm
> > > almost sure it is a contract - if this is a valid or a void one has
> > > yet to be seen.
> >
> > OK, I can't disagree with this.  It does definitely impose obligations
> > that are legally meaningful.  However ...

A legal document would mean there were legal repercussions for
violating it, like violating copyright laws or getting fired for
violating your employment contract.

This doesn't seem to stand on that, this is a set of guidelines for
how a community should act. The people interpreting the document are
members of the community that we in theory trust (via TAB elections).
These are examples of things that cause problems, and guidelines to
follow to avoid bad behaviours, but the intent still matters at the
end of the day. If someone complains you accidentally tagged their
email, the people on the complaints review will figure that out.

It's funny we don't really have this problem with the drm so far, due
to mainly group maintainership. If someone sends me a private email
unless it's a security issue, I ask them to resend it to the public
lists and/or use a public bugzilla, before I action it. This ensures
that members of group teams can engage as a group instead of one
maintainer having the primary inbox load.

I've no objections to clarifying this sort of thing and I think it's
important that we do, but trying to turn this document into something
like an legal employment contract isn't going to be helpful.

Dave.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Wed, 19 Sep 2018 13:10:15 -0700
"Luck, Tony" <tony.luck@intel.com> escreveu:

> On Wed, Sep 19, 2018 at 04:55:52PM -0300, Mauro Carvalho Chehab wrote:
> > After re-reading it, I'm pretty sure that, the way it is, publishing
> > e-mails violate this CoC.
> > 
> > The thing is that, when it uses the commas there:
> > 
> > 	"private information, such as a physical or electronic address," 
> > 
> > The commas actually defines what "private information" is. Even if
> > this would be changed by "foo information", what we have here is actually two
> > English sentences that were merged together:
> > 
> > First sentence:
> > 	"Private information, such as a physical or electronic address."
> > 
> > Second sentence:
> > 	"Publishing others’ private information without explicit permission"
> > 
> > See, replace it by foo at the original text:
> > 	"Publishing others’ *foo* information, such as a physical 
> > 	 or electronic address, without explicit permission"
> > 
> > You'll see that "*foo* information" becomes defined.  
> 
> So perhaps we can move on to discussing a patch to fix it?
> 
> 
> diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..ec99a17ab646 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -31,10 +31,13 @@ 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[1], without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting
>  
> +[1] Note that e-mail addresses used on public mailing lists are not
> +considered to be private information and can (in fact should) be used
> +to give credit in Reported-by, Acked-by, Tested-by etc. tags.
>  
>  Our Responsibilities
>  ====================

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


Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Tim.Bird]

> -----Original Message-----
> From: Mauro Carvalho Chehab
> 
> Em Wed, 19 Sep 2018 13:10:15 -0700
> "Luck, Tony" <tony.luck@intel.com> escreveu:
> 
> > On Wed, Sep 19, 2018 at 04:55:52PM -0300, Mauro Carvalho Chehab wrote:
> > > After re-reading it, I'm pretty sure that, the way it is, publishing
> > > e-mails violate this CoC.
> > >
> > > The thing is that, when it uses the commas there:
> > >
> > > 	"private information, such as a physical or electronic address,"
> > >
> > > The commas actually defines what "private information" is. Even if
> > > this would be changed by "foo information", what we have here is
> actually two
> > > English sentences that were merged together:
> > >
> > > First sentence:
> > > 	"Private information, such as a physical or electronic address."
> > >
> > > Second sentence:
> > > 	"Publishing others’ private information without explicit permission"
> > >
> > > See, replace it by foo at the original text:
> > > 	"Publishing others’ *foo* information, such as a physical
> > > 	 or electronic address, without explicit permission"
> > >
> > > You'll see that "*foo* information" becomes defined.
> >
> > So perhaps we can move on to discussing a patch to fix it?
> >
> >
> > diff --git a/Documentation/process/code-of-conduct.rst
> b/Documentation/process/code-of-conduct.rst
> > index ab7c24b5478c..ec99a17ab646 100644
> > --- a/Documentation/process/code-of-conduct.rst
> > +++ b/Documentation/process/code-of-conduct.rst
> > @@ -31,10 +31,13 @@ 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[1], without explicit permission
> >  * Other conduct which could reasonably be considered inappropriate in a
> >    professional setting
> >
> > +[1] Note that e-mail addresses used on public mailing lists are not
> > +considered to be private information and can (in fact should) be used
> > +to give credit in Reported-by, Acked-by, Tested-by etc. tags.
> >
> >  Our Responsibilities
> >  ====================
> 
> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>

This looks like a straightforward way to address the ambiguity.  It does a bit 
of extra social engineering, with the "(in fact should)" part, but personally
I find that OK.

I don't know if the CoC changes are supposed to be considered rather more
cautiously than other changes or not (well - after the initial somewhat rushed
inclusion).  Do you have to wait for a merge window?  What is
the severity of a "bug" in the CoC, and does it merit a quick change or more
slow deliberation?  Who knows? It's up to Greg to decide for the time being I guess.

Luckily this won't break anything in user space, so even if this is not exactly
the fix we're looking for, it's probably not a big deal to accept this now.  ;-)

Anyway - that's my 2 cents.
 -- Tim

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Thu, 20 Sep 2018 06:23:05 +1000
Dave Airlie <airlied@gmail.com> escreveu:

> On Thu, 20 Sep 2018 at 05:56, Mauro Carvalho Chehab
> <mchehab+samsung@kernel.org> wrote:
> >
> > Em Wed, 19 Sep 2018 10:16:21 -0400
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> >  
> > > On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:  
> > > > Em Wed, 19 Sep 2018 08:37:49 -0300
> > > > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> > > >  
> > > > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > > > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > > > >  
> > > > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:  
> > > > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > > > escreveu:
> > > > > > >  
> > > > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > > > assuaging those fears might be a good thing.
> > > > > > > > >  
> > > > > > > >
> > > > > > > > From my perspective, which is probably fairly widespread:
> > > > > > > > we're already pretty much policing the lists using a set of
> > > > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > > > should really be no huge impact.  
> > > > > > >
> > > > > > > After carefully reading it a couple of times, I think it has a
> > > > > > > huge impact.
> > > > > > >
> > > > > > > The more immediate impact is with regards to this wording:
> > > > > > >
> > > > > > >       "Examples of unacceptable behavior by participants
> > > > > > > include:
> > > > > > >       ...
> > > > > > >       * Publishing others’ private information, such as a
> > > > > > > physical or electronic
> > > > > > >         address, without explicit permission"
> > > > > > >
> > > > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > > > publishing an electronic address.
> > > > > > >
> > > > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > > > the email address from the SOB's, together to its
> > > > > > > redistribution:
> > > > > > >
> > > > > > > "       (d) I understand and agree that this project and the
> > > > > > > contribution
> > > > > > >             are public and that a record of the contribution
> > > > > > > (including all
> > > > > > >             personal information I submit with it, including my
> > > > > > > sign-off) is
> > > > > > >             maintained indefinitely and may be redistributed
> > > > > > > consistent with
> > > > > > >             this project or the open source license(s)
> > > > > > > involved."
> > > > > > >
> > > > > > > But that doesn't cover the other tags.  
> > > > > >
> > > > > > I disagree with the strictness of the interpretation: "including
> > > > > > all personal information I submit with it" covers all the other
> > > > > > tags. Although the expectation is the permission was obtained by
> > > > > > one of the people adding the sign off because that's how the DCO
> > > > > > flows, which might be a bit wishful thinking, we've always
> > > > > > thought that it covers the additional tags for the use case
> > > > > > section (d) was created for: national data protection acts and if
> > > > > > it covers that case, it surely covers the CoC permission case.  
> > > > >
> > > > > I see your point. Yes, that places the SOB signer's as^W backs
> > > > > responsible for such thing.
> > > > >  
> > > > > > Additionally, as others have said, if the tag was added from
> > > > > > information in the public mailing list, it's not private within
> > > > > > the meaning of the CoC.  I think the electronic mail example in
> > > > > > the CoC is simply because it's more used in a github type
> > > > > > environment where email addresses are private and not necessarily
> > > > > > part of the workflow.  
> > > > >
> > > > > If it doesn't apply, it should be removed. Legal documents with
> > > > > unneeded terms only cause confusion (and this *is* a legal document
> > > > > - a  
> > > >
> > > > In time:
> > > >     and this *is* a legal document -> I believe that this is a
> > > > legal document
> > > >
> > > > I'm actually waiting for a legal advice about this under US laws.
> > > > Under Brazilian laws (and probably other civil law system), I'm
> > > > almost sure it is a contract - if this is a valid or a void one has
> > > > yet to be seen.  
> > >
> > > OK, I can't disagree with this.  It does definitely impose obligations
> > > that are legally meaningful.  However ...  
> 
> A legal document would mean there were legal repercussions for
> violating it, like violating copyright laws or getting fired for
> violating your employment contract.
> 
> This doesn't seem to stand on that, this is a set of guidelines for
> how a community should act. 

The previous CoC were a set of guidelines. That's not the case of
this one anymore. It has a legal language, defining a mediation forum
(TAB), improper conducts, penalties, scope, responsibilities, etc.

> The people interpreting the document are
> members of the community that we in theory trust (via TAB elections).

My view is that, the way it is, if someone is not happy with TAB
decisions, it can use CoC to fill a suit in court. If this happens,
I suspect that it will turn very badly, as the improper conducts
are too wide. The ones that will be hurt are the maintainers
(as about half of the document is about duties and penalties to
maintainers).

I don't see there a single word about penalties for false claims.

> These are examples of things that cause problems, and guidelines to
> follow to avoid bad behaviours, but the intent still matters at the
> end of the day. If someone complains you accidentally tagged their
> email, the people on the complaints review will figure that out.
> 
> It's funny we don't really have this problem with the drm so far, due
> to mainly group maintainership. If someone sends me a private email
> unless it's a security issue, I ask them to resend it to the public
> lists and/or use a public bugzilla, before I action it. This ensures
> that members of group teams can engage as a group instead of one
> maintainer having the primary inbox load.
> 
> I've no objections to clarifying this sort of thing and I think it's
> important that we do, but trying to turn this document into something
> like an legal employment contract isn't going to be helpful.

I'm actually in favor of the opposite: to remove everything that looks
like a legal contract.

Something like the patch below.

PS. It incorporates Tony's suggestions, with an addition with regards
to IRC public channels. It is not common, but sometimes we give
credits on some patches from people that commented on IRC chats,
and that sometimes we don't know their emails.

I opted to not realign the document, in order to make easier to review.

Thanks,
Mauro

diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..aa763c51f421 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -30,50 +30,48 @@ Examples of unacceptable behavior by participants include:
   advances
 * 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
+* Publishing others' private information, such as a physical or electronic
+  address[1], without explicit permission
 * Other conduct which could reasonably be considered inappropriate in a
   professional setting
 
+[1] Note that electronic addresses used on public mailing lists and public
+IRC channels associated with the Kernel community are not considered to be
+private information and can (in fact should) be used to give credit in
+Reported-by, Acked-by, Tested-by etc. tags.
 
 Our Responsibilities
 ====================
 
 Maintainers are responsible for clarifying the standards of acceptable behavior
-and are expected to take appropriate and fair corrective action in response to
+and are asked 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
-comments, commits, code, wiki edits, issues, and other contributions that are
+Maintainers have the right to 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,
-offensive, or harmful.
+offensive or harmful.
 
 Scope
 =====
 
 This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-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
+when an individual is representing the project or its community. It also
+applies to e-mails using kernel.org address. Representation of a project may be
 further defined and clarified by project maintainers.
 
 Enforcement
 ===========
 
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
+Instances of abusive, harassing, or otherwise unacceptable behavior should 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
+appropriate to the circumstances. The TAB will maintain
+confidentiality with regards 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] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Tim.Bird]

> -----Original Message-----
> From: Mauro Carvalho Chehab
> Em Thu, 20 Sep 2018 06:23:05 +1000
> Dave Airlie <airlied@gmail.com> escreveu:
> 
> > On Thu, 20 Sep 2018 at 05:56, Mauro Carvalho Chehab
> > <mchehab+samsung@kernel.org> wrote:
> > >
> > > Em Wed, 19 Sep 2018 10:16:21 -0400
> > > James Bottomley <James.Bottomley@HansenPartnership.com>
> escreveu:
> > >
> > > > On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> > > > > Em Wed, 19 Sep 2018 08:37:49 -0300
> > > > > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> > > > >
> > > > > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> escreveu:
> > > > > >
> > > > > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > > > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > > > > escreveu:
> > > > > > > >
> > > > > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > > > > assuaging those fears might be a good thing.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > From my perspective, which is probably fairly widespread:
> > > > > > > > > we're already pretty much policing the lists using a set of
> > > > > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > > > > should really be no huge impact.
> > > > > > > >
> > > > > > > > After carefully reading it a couple of times, I think it has a
> > > > > > > > huge impact.
> > > > > > > >
> > > > > > > > The more immediate impact is with regards to this wording:
> > > > > > > >
> > > > > > > >       "Examples of unacceptable behavior by participants
> > > > > > > > include:
> > > > > > > >       ...
> > > > > > > >       * Publishing others’ private information, such as a
> > > > > > > > physical or electronic
> > > > > > > >         address, without explicit permission"
> > > > > > > >
> > > > > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > > > > publishing an electronic address.
> > > > > > > >
> > > > > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > > > > the email address from the SOB's, together to its
> > > > > > > > redistribution:
> > > > > > > >
> > > > > > > > "       (d) I understand and agree that this project and the
> > > > > > > > contribution
> > > > > > > >             are public and that a record of the contribution
> > > > > > > > (including all
> > > > > > > >             personal information I submit with it, including my
> > > > > > > > sign-off) is
> > > > > > > >             maintained indefinitely and may be redistributed
> > > > > > > > consistent with
> > > > > > > >             this project or the open source license(s)
> > > > > > > > involved."
> > > > > > > >
> > > > > > > > But that doesn't cover the other tags.
> > > > > > >
> > > > > > > I disagree with the strictness of the interpretation: "including
> > > > > > > all personal information I submit with it" covers all the other
> > > > > > > tags. Although the expectation is the permission was obtained by
> > > > > > > one of the people adding the sign off because that's how the DCO
> > > > > > > flows, which might be a bit wishful thinking, we've always
> > > > > > > thought that it covers the additional tags for the use case
> > > > > > > section (d) was created for: national data protection acts and if
> > > > > > > it covers that case, it surely covers the CoC permission case.
> > > > > >
> > > > > > I see your point. Yes, that places the SOB signer's as^W backs
> > > > > > responsible for such thing.
> > > > > >
> > > > > > > Additionally, as others have said, if the tag was added from
> > > > > > > information in the public mailing list, it's not private within
> > > > > > > the meaning of the CoC.  I think the electronic mail example in
> > > > > > > the CoC is simply because it's more used in a github type
> > > > > > > environment where email addresses are private and not
> necessarily
> > > > > > > part of the workflow.
> > > > > >
> > > > > > If it doesn't apply, it should be removed. Legal documents with
> > > > > > unneeded terms only cause confusion (and this *is* a legal
> document
> > > > > > - a
> > > > >
> > > > > In time:
> > > > >     and this *is* a legal document -> I believe that this is a
> > > > > legal document
> > > > >
> > > > > I'm actually waiting for a legal advice about this under US laws.
> > > > > Under Brazilian laws (and probably other civil law system), I'm
> > > > > almost sure it is a contract - if this is a valid or a void one has
> > > > > yet to be seen.
> > > >
> > > > OK, I can't disagree with this.  It does definitely impose obligations
> > > > that are legally meaningful.  However ...
> >
> > A legal document would mean there were legal repercussions for
> > violating it, like violating copyright laws or getting fired for
> > violating your employment contract.
> >
> > This doesn't seem to stand on that, this is a set of guidelines for
> > how a community should act.
> 
> The previous CoC were a set of guidelines. That's not the case of
> this one anymore. It has a legal language, defining a mediation forum
> (TAB), improper conducts, penalties, scope, responsibilities, etc.
Just because it has these sections, and language that is also used
in legal documents, does not make it a legal document.

My view is that it's intended to be a social document, with guidelines
for actions within the community  (Actions by maintainers, actions
by contributors, actions by the TAB).  To me it's more like rules for
a party at my house.  If someone doesn't abide by the rules, I'll ask
them to leave the party.  And I'll ask others at the party to remind people
to abide by the rules.  But the person kicked out can hardly call the cops
on me for doing so.
   -- Tim

> 
> > The people interpreting the document are
> > members of the community that we in theory trust (via TAB elections).
> 
> My view is that, the way it is, if someone is not happy with TAB
> decisions, it can use CoC to fill a suit in court.

Is there an example where this has happened, or even come close to
happening (e.g. someone verbally threatened to sue based on a 
CoC action like e-mail banning?)  If so, I'd like to look at the details.
The only things I can think of are cases where there actually is a legal
document governing granting access to, for example, a social media
site.

> If this happens,
> I suspect that it will turn very badly, as the improper conducts
> are too wide. The ones that will be hurt are the maintainers
> (as about half of the document is about duties and penalties to
> maintainers).
> 
> I don't see there a single word about penalties for false claims.
Demonstrably false claims, made in bad faith, would violate the
CoC, IMHO.  So they'd be covered.
> 
> > These are examples of things that cause problems, and guidelines to
> > follow to avoid bad behaviours, but the intent still matters at the
> > end of the day. If someone complains you accidentally tagged their
> > email, the people on the complaints review will figure that out.
> >
> > It's funny we don't really have this problem with the drm so far, due
> > to mainly group maintainership. If someone sends me a private email
> > unless it's a security issue, I ask them to resend it to the public
> > lists and/or use a public bugzilla, before I action it. This ensures
> > that members of group teams can engage as a group instead of one
> > maintainer having the primary inbox load.
> >
> > I've no objections to clarifying this sort of thing and I think it's
> > important that we do, but trying to turn this document into something
> > like an legal employment contract isn't going to be helpful.
> 
> I'm actually in favor of the opposite: to remove everything that looks
> like a legal contract.
> 
> Something like the patch below.

Since this CoC has been used by a LOT of projects, it might be worth
researching the discussions leading to the adoption of it in those
other projects, to see if similar issues were raised, and what  the response
was.  I'm not sure if I'll have time to do that myself in the short term,
but I'll try to at least look at some of the public revision history of the CoC
to see if there's any enlightenment there.

Regards,
 -- Tim


> 
> PS. It incorporates Tony's suggestions, with an addition with regards
> to IRC public channels. It is not common, but sometimes we give
> credits on some patches from people that commented on IRC chats,
> and that sometimes we don't know their emails.
> 
> I opted to not realign the document, in order to make easier to review.
> 
> Thanks,
> Mauro
> 
> diff --git a/Documentation/process/code-of-conduct.rst
> b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa763c51f421 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -30,50 +30,48 @@ Examples of unacceptable behavior by participants
> include:
>    advances
>  * 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
> +* Publishing others' private information, such as a physical or electronic
> +  address[1], without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting
> 
> +[1] Note that electronic addresses used on public mailing lists and public
> +IRC channels associated with the Kernel community are not considered to
> be
> +private information and can (in fact should) be used to give credit in
> +Reported-by, Acked-by, Tested-by etc. tags.
> 
>  Our Responsibilities
>  ====================
> 
>  Maintainers are responsible for clarifying the standards of acceptable
> behavior
> -and are expected to take appropriate and fair corrective action in response
> to
> +and are asked 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
> -comments, commits, code, wiki edits, issues, and other contributions that
> are
> +Maintainers have the right to 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,
> -offensive, or harmful.
> +offensive or harmful.
> 
>  Scope
>  =====
> 
>  This Code of Conduct applies both within project spaces and in public spaces
> -when an individual is representing the project or its community. Examples of
> -representing a project or community include using an official project e-mail
> -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
> +when an individual is representing the project or its community. It also
> +applies to e-mails using kernel.org address. Representation of a project may
> be
>  further defined and clarified by project maintainers.
> 
>  Enforcement
>  ===========
> 
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> +Instances of abusive, harassing, or otherwise unacceptable behavior should
> 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
> +appropriate to the circumstances. The TAB will maintain
> +confidentiality with regards 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
>  ===========
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.linuxfoundation.org_mailman_listinfo_ksummit-
> 2Ddiscuss&d=DwIGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=n5VBZF5ShttXTIqCERDxd88PVFiYKmeFXfyy5oZcCck&s=zc
> 7vcXOl4dMEPO_2XDmFX0UNg6up4d7ZMKLKFwSaiKQ&e=

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Joe Perches]

On Wed, 2018-09-19 at 21:01 -0300, Mauro Carvalho Chehab wrote:
> I'm actually in favor of the opposite: to remove everything that looks
> like a legal contract.

Yes please.

 Our Responsibilities
>  ====================
>  
>  Maintainers are responsible for clarifying the standards of acceptable behavior
> -and are expected to take appropriate and fair corrective action in response to
> +and are asked 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
> -comments, commits, code, wiki edits, issues, and other contributions that are
> +Maintainers have the right to 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,
> -offensive, or harmful.
> +offensive or harmful.

This paragraph is unnecessary.

Maintainers are responsible for code.
Community is responsible for behavior.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Stephen Hemminger]

On Wed, 19 Sep 2018 21:01:22 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:

> -offensive, or harmful.
> +offensive or harmful.

Please keep the Oxford comma.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Jani Nikula]

On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
> My view is that it's intended to be a social document, with guidelines
> for actions within the community  (Actions by maintainers, actions
> by contributors, actions by the TAB).  To me it's more like rules for
> a party at my house.  If someone doesn't abide by the rules, I'll ask
> them to leave the party.  And I'll ask others at the party to remind people
> to abide by the rules.  But the person kicked out can hardly call the cops
> on me for doing so.

Agreed.

I think there's much more value in adopting a widely used code of
conduct than writing your own, or even trying to tweak it. If a project
uses the Contributor Covenant, you pretty much know the rules without
actually having to read another document and wonder what this all means.
In this regard, it's really not unlike the GPL for copyleft licenses;
one acronym tells you what you can and can't do.

With that perspective, I think the changes proposed in this thread do
more harm than good. If people still insist the text should be improved,
I think the proper flow is to file issues or pull requests to
Contributor Covenant upstream [1], and later update to a new version of
the document.

BR,
Jani.


[1] https://github.com/ContributorCovenant/contributor_covenant


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Josh Triplett]

On Thu, Sep 20, 2018 at 09:33:05AM +0300, Jani Nikula wrote:
> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
> > My view is that it's intended to be a social document, with guidelines
> > for actions within the community  (Actions by maintainers, actions
> > by contributors, actions by the TAB).  To me it's more like rules for
> > a party at my house.  If someone doesn't abide by the rules, I'll ask
> > them to leave the party.  And I'll ask others at the party to remind people
> > to abide by the rules.  But the person kicked out can hardly call the cops
> > on me for doing so.
> 
> Agreed.
> 
> I think there's much more value in adopting a widely used code of
> conduct than writing your own, or even trying to tweak it. If a project
> uses the Contributor Covenant, you pretty much know the rules without
> actually having to read another document and wonder what this all means.
> In this regard, it's really not unlike the GPL for copyleft licenses;
> one acronym tells you what you can and can't do.
> 
> With that perspective, I think the changes proposed in this thread do
> more harm than good. If people still insist the text should be improved,
> I think the proper flow is to file issues or pull requests to
> Contributor Covenant upstream [1], and later update to a new version of
> the document.

Seconded. I've seen many changes accepted upstream, and it seems
reasonable to start there first.

To the extent we need any kernel-specific process clarifications that
*can't* usefully go upstream, I would suggest keeping them in a separate
document.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[David Woodhouse]

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

On Thu, 2018-09-20 at 09:33 +0300, Jani Nikula wrote:
> Agreed.
> 
> I think there's much more value in adopting a widely used code of
> conduct than writing your own, or even trying to tweak it. If a project
> uses the Contributor Covenant, you pretty much know the rules without
> actually having to read another document and wonder what this all means.
> In this regard, it's really not unlike the GPL for copyleft licenses;
> one acronym tells you what you can and can't do.
> 
> With that perspective, I think the changes proposed in this thread do
> more harm than good. If people still insist the text should be improved,
> I think the proper flow is to file issues or pull requests to
> Contributor Covenant upstream [1], and later update to a new version of
> the document.

I'll note that isn't what Linus did with the GPL.

But perhaps there's a possible solution: Instead of editing the text of
the covenant, just preface it with a statement that email addresses
used on mailing lists are not considered to be private and that it is
acceptable (and indeed recommended) to credit individuals who have
contributed to reporting and testing by using their email addresses.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Daniel Vetter]

On Thu, Sep 20, 2018 at 9:01 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Thu, Sep 20, 2018 at 09:33:05AM +0300, Jani Nikula wrote:
>> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
>> > My view is that it's intended to be a social document, with guidelines
>> > for actions within the community  (Actions by maintainers, actions
>> > by contributors, actions by the TAB).  To me it's more like rules for
>> > a party at my house.  If someone doesn't abide by the rules, I'll ask
>> > them to leave the party.  And I'll ask others at the party to remind people
>> > to abide by the rules.  But the person kicked out can hardly call the cops
>> > on me for doing so.
>>
>> Agreed.
>>
>> I think there's much more value in adopting a widely used code of
>> conduct than writing your own, or even trying to tweak it. If a project
>> uses the Contributor Covenant, you pretty much know the rules without
>> actually having to read another document and wonder what this all means.
>> In this regard, it's really not unlike the GPL for copyleft licenses;
>> one acronym tells you what you can and can't do.

Yup, this matches the universal recommendation we've received when
looking into what CoC to wrap freedesktop.org in.

>> With that perspective, I think the changes proposed in this thread do
>> more harm than good. If people still insist the text should be improved,
>> I think the proper flow is to file issues or pull requests to
>> Contributor Covenant upstream [1], and later update to a new version of
>> the document.
>
> Seconded. I've seen many changes accepted upstream, and it seems
> reasonable to start there first.
>
> To the extent we need any kernel-specific process clarifications that
> *can't* usefully go upstream, I would suggest keeping them in a separate
> document.

This is the same approach we're picking on the freedesktop.org/x.org
foundation side (the freedesktop.org CoC applied to a lot more than
just drm). We're still working on some of the process and
implementation details (e.g. the exact appeals procudures isn't
defined yet). But that's all going to be written out in a separate
policy, not in the code of conduct itself.

I think that's also a good place to put clarifications (along the line
of what David Woodhouse just suggested in another reply), like that we
don't consider email addresses that showed up on public mailing lists
as private data. Which is also what the freedesktop.org privacy policy
spells out: If you send mails to mailing lists, everything in there is
public (and due to the nature of distributed archives, can't be taken
down again, since freedesktop.org doesn't even control them). If you
don't like that, don't send mails to mailing lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Rafael J. Wysocki]

On Tuesday, September 18, 2018 3:43:32 PM CEST Steven Rostedt wrote:
> On Tue, 18 Sep 2018 15:55:23 +1000
> Dave Airlie <airlied@gmail.com> wrote:
> 
> > I think there might be place for a report from the people who did sign
> > off the CoC about the thoughts/process involved in updating it (and/or
> > urgency) to the rest of the Maintainer group.
> > 
> > Now I understand that having a public talk about such a thing will
> > likely descend into farce, there may be scope for something of a
> > Chatham House Rule style meeting, or just a non-recorded, non-public
> > session like we've done for sensitive subjects are previous kernel
> > summits.
> 
> I believe this topic merits a discussion at Maintainer's Summit. It can
> probably be much more productive face to face with several maintainers
> in one room than what would result in a mailing list (both public and
> private) discussion.
> 
> I'm willing to lead this if nobody else wants to do it.
> 
>   (I don't know why I do this to myself)
> 
> 
> > 
> > It might just be a readout from a similar meeting at Edinburgh summit
> > (maybe someone else can propose that), or maybe some sort of Q&A
> > session. Maybe Linus could record a piece to camera for the
> > maintainers that can't make Edinburgh, but would still like to
> > understand where everything currently sits. Said piece would of course
> > be burned afterwards.
> 
> I would like to get an honest opinion from everyone involved, and
> remove any of the ambiguities that people still have.
> 
> > 
> > After the past 2-3 days I get the feeling there are maintainers unsure
> > about how this affects them and I think assuaging those fears might be
> > a good thing.
> 
> Agreed.
> 
> > 
> > I'm also equally happy nailing the lid back on the can of worms and
> > never discussing it again.
> 
> No no, the can is now open and you have released the worms ;-)

Well, let's just pick one for that matter.

Can anyone explain the exact meaning of the "Our Responsibilities" section of
the new CoC to me, please?

Like what *exactly* am I expected to do, as a subsystem maintainer, when I spot
"unacceptable behavior" on a mailing list or elsewhere?  What would be generally
regarded as a "fair corrective action", in particular?

Also, the second paragraph in there openly suggests that maintainers are now
expected to reject contributions from the people who behave inappropriately
in their view.  Does this mean that I'm expected to reject correct code changes
(maybe including bug fixes and maybe even security-critical ones) from a person
whose behaviors "deem inappropriate, threatening, offensive, or harmful" in
my view?

Cheers,
Rafael

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Daniel Vetter]

On Thu, Sep 20, 2018 at 11:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, September 18, 2018 3:43:32 PM CEST Steven Rostedt wrote:
>> On Tue, 18 Sep 2018 15:55:23 +1000
>> Dave Airlie <airlied@gmail.com> wrote:
>>
>> > I think there might be place for a report from the people who did sign
>> > off the CoC about the thoughts/process involved in updating it (and/or
>> > urgency) to the rest of the Maintainer group.
>> >
>> > Now I understand that having a public talk about such a thing will
>> > likely descend into farce, there may be scope for something of a
>> > Chatham House Rule style meeting, or just a non-recorded, non-public
>> > session like we've done for sensitive subjects are previous kernel
>> > summits.
>>
>> I believe this topic merits a discussion at Maintainer's Summit. It can
>> probably be much more productive face to face with several maintainers
>> in one room than what would result in a mailing list (both public and
>> private) discussion.
>>
>> I'm willing to lead this if nobody else wants to do it.
>>
>>   (I don't know why I do this to myself)
>>
>>
>> >
>> > It might just be a readout from a similar meeting at Edinburgh summit
>> > (maybe someone else can propose that), or maybe some sort of Q&A
>> > session. Maybe Linus could record a piece to camera for the
>> > maintainers that can't make Edinburgh, but would still like to
>> > understand where everything currently sits. Said piece would of course
>> > be burned afterwards.
>>
>> I would like to get an honest opinion from everyone involved, and
>> remove any of the ambiguities that people still have.
>>
>> >
>> > After the past 2-3 days I get the feeling there are maintainers unsure
>> > about how this affects them and I think assuaging those fears might be
>> > a good thing.
>>
>> Agreed.
>>
>> >
>> > I'm also equally happy nailing the lid back on the can of worms and
>> > never discussing it again.
>>
>> No no, the can is now open and you have released the worms ;-)
>
> Well, let's just pick one for that matter.
>
> Can anyone explain the exact meaning of the "Our Responsibilities" section of
> the new CoC to me, please?
>
> Like what *exactly* am I expected to do, as a subsystem maintainer, when I spot
> "unacceptable behavior" on a mailing list or elsewhere?  What would be generally
> regarded as a "fair corrective action", in particular?

We have a few years of operational experience on this in dri-devel
(since defacto the fd.o CoC just encoded existing informal community
norms of the drm subsystem). Generally what we do is send a public
reply, pointing out what's problematic, quickly explaing why, and
that's it. Generally, what happens then is a "oh right, that was too
much, apologies" reply.

If the problematic behaviour doesn't stop, tougher measure might be
necessary. In some cases also a private chat helps a lot, when people
never really thought about some topics and issues before.

It's also important to note that this isn't just done by maintainers,
but by (generally more senior) contributors all around.

For a working community, where the CoC is solidly established (like I
think it is on dri-devel), the next-level fd.o team essentially only
serves as appeals body.

> Also, the second paragraph in there openly suggests that maintainers are now
> expected to reject contributions from the people who behave inappropriately
> in their view.  Does this mean that I'm expected to reject correct code changes
> (maybe including bug fixes and maybe even security-critical ones) from a person
> whose behaviors "deem inappropriate, threatening, offensive, or harmful" in
> my view?

Ultimately, yes. On dri-devel we didn't yet have to pull out that
threat yet. If you look at other communities, a permanent ban (which
is what you defacto do if you reject all contributions from someone)
is an extremely rare measure.

What we have done is temporarily suspend people's commit rights, so
they can cool down a bit. Or making it clear that we might remove them
from maintainer duties. The amount of damage a maintainer/committer
can do is much bigger than someone just submitting patches, so usually
that's all that's needed. All while making it clear that their
contributions are still very much welcome. But someone who really only
wreaks a massive wake of destruction, even if their patches themselves
are fine, will be thrown out completely from dri-devel. Just not worth
to deal with.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Daniel Vetter]

On Thu, Sep 20, 2018 at 11:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Thu, Sep 20, 2018 at 11:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> On Tuesday, September 18, 2018 3:43:32 PM CEST Steven Rostedt wrote:
>>> On Tue, 18 Sep 2018 15:55:23 +1000
>>> Dave Airlie <airlied@gmail.com> wrote:
>>>
>>> > I think there might be place for a report from the people who did sign
>>> > off the CoC about the thoughts/process involved in updating it (and/or
>>> > urgency) to the rest of the Maintainer group.
>>> >
>>> > Now I understand that having a public talk about such a thing will
>>> > likely descend into farce, there may be scope for something of a
>>> > Chatham House Rule style meeting, or just a non-recorded, non-public
>>> > session like we've done for sensitive subjects are previous kernel
>>> > summits.
>>>
>>> I believe this topic merits a discussion at Maintainer's Summit. It can
>>> probably be much more productive face to face with several maintainers
>>> in one room than what would result in a mailing list (both public and
>>> private) discussion.
>>>
>>> I'm willing to lead this if nobody else wants to do it.
>>>
>>>   (I don't know why I do this to myself)
>>>
>>>
>>> >
>>> > It might just be a readout from a similar meeting at Edinburgh summit
>>> > (maybe someone else can propose that), or maybe some sort of Q&A
>>> > session. Maybe Linus could record a piece to camera for the
>>> > maintainers that can't make Edinburgh, but would still like to
>>> > understand where everything currently sits. Said piece would of course
>>> > be burned afterwards.
>>>
>>> I would like to get an honest opinion from everyone involved, and
>>> remove any of the ambiguities that people still have.
>>>
>>> >
>>> > After the past 2-3 days I get the feeling there are maintainers unsure
>>> > about how this affects them and I think assuaging those fears might be
>>> > a good thing.
>>>
>>> Agreed.
>>>
>>> >
>>> > I'm also equally happy nailing the lid back on the can of worms and
>>> > never discussing it again.
>>>
>>> No no, the can is now open and you have released the worms ;-)
>>
>> Well, let's just pick one for that matter.
>>
>> Can anyone explain the exact meaning of the "Our Responsibilities" section of
>> the new CoC to me, please?
>>
>> Like what *exactly* am I expected to do, as a subsystem maintainer, when I spot
>> "unacceptable behavior" on a mailing list or elsewhere?  What would be generally
>> regarded as a "fair corrective action", in particular?
>
> We have a few years of operational experience on this in dri-devel
> (since defacto the fd.o CoC just encoded existing informal community
> norms of the drm subsystem). Generally what we do is send a public
> reply, pointing out what's problematic, quickly explaing why, and
> that's it. Generally, what happens then is a "oh right, that was too
> much, apologies" reply.
>
> If the problematic behaviour doesn't stop, tougher measure might be
> necessary. In some cases also a private chat helps a lot, when people
> never really thought about some topics and issues before.
>
> It's also important to note that this isn't just done by maintainers,
> but by (generally more senior) contributors all around.
>
> For a working community, where the CoC is solidly established (like I
> think it is on dri-devel), the next-level fd.o team essentially only
> serves as appeals body.
>
>> Also, the second paragraph in there openly suggests that maintainers are now
>> expected to reject contributions from the people who behave inappropriately
>> in their view.  Does this mean that I'm expected to reject correct code changes
>> (maybe including bug fixes and maybe even security-critical ones) from a person
>> whose behaviors "deem inappropriate, threatening, offensive, or harmful" in
>> my view?
>
> Ultimately, yes. On dri-devel we didn't yet have to pull out that
> threat yet. If you look at other communities, a permanent ban (which
> is what you defacto do if you reject all contributions from someone)
> is an extremely rare measure.
>
> What we have done is temporarily suspend people's commit rights, so
> they can cool down a bit. Or making it clear that we might remove them
> from maintainer duties. The amount of damage a maintainer/committer
> can do is much bigger than someone just submitting patches, so usually
> that's all that's needed. All while making it clear that their
> contributions are still very much welcome. But someone who really only
> wreaks a massive wake of destruction, even if their patches themselves
> are fine, will be thrown out completely from dri-devel. Just not worth
> to deal with.

Slightly more high level take: CoC enforcement is a skill like any
other. Takes a bit of learning and practice to get good enough at it.
There's also lots of people offering trainings, to walk through very
specific scenarios and discusss all these details. This might be
something we should consider for kernel summit.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Laurent Pinchart]

On Thursday, 20 September 2018 09:33:05 EEST Jani Nikula wrote:
> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
> > My view is that it's intended to be a social document, with guidelines
> > for actions within the community  (Actions by maintainers, actions
> > by contributors, actions by the TAB).  To me it's more like rules for
> > a party at my house.  If someone doesn't abide by the rules, I'll ask
> > them to leave the party.  And I'll ask others at the party to remind
> > people to abide by the rules.  But the person kicked out can hardly call
> > the cops on me for doing so.
> 
> Agreed.
> 
> I think there's much more value in adopting a widely used code of
> conduct than writing your own, or even trying to tweak it. If a project
> uses the Contributor Covenant, you pretty much know the rules without
> actually having to read another document and wonder what this all means.
> In this regard, it's really not unlike the GPL for copyleft licenses;
> one acronym tells you what you can and can't do.
> 
> With that perspective, I think the changes proposed in this thread do
> more harm than good. If people still insist the text should be improved,
> I think the proper flow is to file issues or pull requests to
> Contributor Covenant upstream [1], and later update to a new version of
> the document.

Or to add a FAQ next to the document that clarifies how the Linux kernel 
community interprets it.

> [1] https://github.com/ContributorCovenant/contributor_covenant

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Thu, 20 Sep 2018 09:33:05 +0300
Jani Nikula <jani.nikula@intel.com> escreveu:

> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
> > My view is that it's intended to be a social document, with guidelines
> > for actions within the community  (Actions by maintainers, actions
> > by contributors, actions by the TAB).  To me it's more like rules for
> > a party at my house.  If someone doesn't abide by the rules, I'll ask
> > them to leave the party.  And I'll ask others at the party to remind people
> > to abide by the rules.  But the person kicked out can hardly call the cops
> > on me for doing so.  
> 
> Agreed.
> 
> I think there's much more value in adopting a widely used code of
> conduct than writing your own, or even trying to tweak it. If a project
> uses the Contributor Covenant, you pretty much know the rules without
> actually having to read another document and wonder what this all means.
> In this regard, it's really not unlike the GPL for copyleft licenses;
> one acronym tells you what you can and can't do.
> 
> With that perspective, I think the changes proposed in this thread do
> more harm than good. If people still insist the text should be improved,
> I think the proper flow is to file issues or pull requests to
> Contributor Covenant upstream [1], and later update to a new version of
> the document.

The main experience of the Contributor Covenant's author seems to be
on Github. There is a fundamental difference between a Github-based
project workflow and the Kernel: there, everything happens inside a GUI
interface. Usually, those projects don't have a large number of
maintainers, nor contributors. Message traffic is typically not high.

On such kind of interface, the maintainers can edit or delete all
kinds of messages, even posted by a third party. So, a text like:

	"Maintainers have the right and responsibility to remove, edit,..."

would work. If the number of messages are small, it is also an easy
task.

It could also work on a smaller e-mail-based project where there is
just one or two moderated ML.

However, on a higly e-mail based project like the Kernel, where we receive
hundreds to thousands of messages per day, and we have a large
number of mailing lists, in order to comply with that CoC statement, 
all email lists should be moderated. I can't imagine any way to have
a list like LKML moderated. Even moderating the linux-media ML nowadays
would be really hard, and would be someone's full time job.

Even if LF hires a team of moderators for all Kernel mailing lists,
if someone cross-post a message on more than one list, different
moderators could take different measurements, with could be a problem,
if the same email is threated different by the different moderators.

Not practical (and it comes with a cost).

Using the terms of the CoC, by not taking any measure to stop
offensive posts, maintainers wouldn't be "acting in good faith".
So, maintainers are violating the policy.

Also, if someone felt abused, the "unacceptable behavior may be
reported by contacting the Technical Advisory Board (TAB)".
The *may* word indicates that he can also go to other places to
do a similar complain. Implicitly, it opens space to go to court.

So, the practical effect is that, if someone wants to fire
a random maintainer, all it has to do is to create a fake account,
send a bunch of random offensive messages to himself on his real
account, and then complain - first on TAB - then filing a lawsuit
(with can envolve both the TAB and the maintainer).

That's why I don't think that, the way it is, this CoC applies
to us. The way it is, it is just FUD. I can see a few 
alternatives:

1) Revert the CoC patch;
2) Use another CoC that would work for e-mail-based workflows;
3) Patch it - either changing the text of the CoC or adding
   a prologue adding ammendments to prevent the above risk
   and solving the e-mail addresses on review tags.

My view is that, currently, we have a major issue at the 
contributing process. So, if nothing happens, I may wait until
the Maintainer's Summit before sending any pull requests
upstream.

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Laurent Pinchart]

Hi Joe,

On Thursday, 20 September 2018 05:44:44 EEST Joe Perches wrote:
> On Wed, 2018-09-19 at 21:01 -0300, Mauro Carvalho Chehab wrote:
> > I'm actually in favor of the opposite: to remove everything that looks
> > like a legal contract.
> 
> Yes please.
> 
>  Our Responsibilities
> 
> >  ====================
> >  
> >  Maintainers are responsible for clarifying the standards of acceptable
> >  behavior
> > -and are expected to take appropriate and fair corrective action in
> > response to +and are asked 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
> > -comments, commits, code, wiki edits, issues, and other contributions that
> > are +Maintainers have the right to 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,
> > -offensive, or harmful.
> > +offensive or harmful.
> 
> This paragraph is unnecessary.
> 
> Maintainers are responsible for code.
> Community is responsible for behavior.

Who is "the community", aren't maintainers part of it ?

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Eric W. Biederman]

Dave Airlie <airlied@gmail.com> writes:

> I think there might be place for a report from the people who did sign
> off the CoC about the thoughts/process involved in updating it (and/or
> urgency) to the rest of the Maintainer group.

I would very much appreciate that.

> After the past 2-3 days I get the feeling there are maintainers unsure
> about how this affects them and I think assuaging those fears might be
> a good thing.

I definitely uncertain about this proposed code of conduct.  Judging
8a104f8b5867 ("Code of Conduct: Let's revamp it.") as an oridnary patch
I am concerned that we just merged a bad patch.

My least concern is that it is not an obviously correct bug fix making
rc4 an inappropriate time to merge the change.

There has been no discussion that I can see leading up to the new CoC.

No motiviation for the change have presented in the changelog.

The presumably failing remedies (escalation to the TAB) have not
changed.  Which makes me wonder (since there is no description) how
anything will change.

The document appears to be a horrible sign of leadership in the Linux
kernel where the only real power maintainers have is to include or not
to include code.  As has been pointed out we can't police mailing lists
and even if we could maintainers don't have the time.

If the new CoC acts as a legal document as Mauro has suggested those
extra requirements on the edge of being a GPL violation.

This concept of official project anything is just plain strange.  We
have kernel.org but it isn't official, it is just the infrastructure
that HPA put together one day and formed a non-profit to run.  That
makes kernel.org a project in itself but not the linux-kernel project
per se.  Similarly there is the Linux Foundation that exists to support
the work of linux development and give suits someone to interact with,
but is not actually the linux kernel project.  The Linux Foundation
requires the TAB to keep it from getting out of line and harming the
kernel development.

So as a whole I don't think this change has been well explained or well
thought through.  As human beings if we need a change we need some real
communication about what is trying to be fixed and some real discussions
about how to fix things.

Eric

p.s.  As a maintainer I am concerned that the most frequent kind of
abuse I see:  Submitting code endlessly without listening to feedback
is not dealt with.  To my knowledge that is the only kind of abusive
behavior that has every gotten anyone banned from linux mailing lists.

A similar abuse is maintainers pushing too hard for their changes and
pushing code to be included without listening to feedback.  It is very
human but certainly something we should strive to avoid.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Jani Nikula]

On Thu, 20 Sep 2018, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Em Thu, 20 Sep 2018 09:33:05 +0300
> Jani Nikula <jani.nikula@intel.com> escreveu:
>
>> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
>> > My view is that it's intended to be a social document, with guidelines
>> > for actions within the community  (Actions by maintainers, actions
>> > by contributors, actions by the TAB).  To me it's more like rules for
>> > a party at my house.  If someone doesn't abide by the rules, I'll ask
>> > them to leave the party.  And I'll ask others at the party to remind people
>> > to abide by the rules.  But the person kicked out can hardly call the cops
>> > on me for doing so.  
>> 
>> Agreed.
>> 
>> I think there's much more value in adopting a widely used code of
>> conduct than writing your own, or even trying to tweak it. If a project
>> uses the Contributor Covenant, you pretty much know the rules without
>> actually having to read another document and wonder what this all means.
>> In this regard, it's really not unlike the GPL for copyleft licenses;
>> one acronym tells you what you can and can't do.
>> 
>> With that perspective, I think the changes proposed in this thread do
>> more harm than good. If people still insist the text should be improved,
>> I think the proper flow is to file issues or pull requests to
>> Contributor Covenant upstream [1], and later update to a new version of
>> the document.
>
> The main experience of the Contributor Covenant's author seems to be
> on Github. There is a fundamental difference between a Github-based
> project workflow and the Kernel: there, everything happens inside a GUI
> interface. Usually, those projects don't have a large number of
> maintainers, nor contributors. Message traffic is typically not high.
>
> On such kind of interface, the maintainers can edit or delete all
> kinds of messages, even posted by a third party. So, a text like:
>
> 	"Maintainers have the right and responsibility to remove, edit,..."
>
> would work. If the number of messages are small, it is also an easy
> task.
>
> It could also work on a smaller e-mail-based project where there is
> just one or two moderated ML.
>
> However, on a higly e-mail based project like the Kernel, where we receive
> hundreds to thousands of messages per day, and we have a large
> number of mailing lists, in order to comply with that CoC statement, 
> all email lists should be moderated. I can't imagine any way to have
> a list like LKML moderated. Even moderating the linux-media ML nowadays
> would be really hard, and would be someone's full time job.
>
> Even if LF hires a team of moderators for all Kernel mailing lists,
> if someone cross-post a message on more than one list, different
> moderators could take different measurements, with could be a problem,
> if the same email is threated different by the different moderators.
>
> Not practical (and it comes with a cost).
>
> Using the terms of the CoC, by not taking any measure to stop
> offensive posts, maintainers wouldn't be "acting in good faith".
> So, maintainers are violating the policy.
>
> Also, if someone felt abused, the "unacceptable behavior may be
> reported by contacting the Technical Advisory Board (TAB)".
> The *may* word indicates that he can also go to other places to
> do a similar complain. Implicitly, it opens space to go to court.
>
> So, the practical effect is that, if someone wants to fire
> a random maintainer, all it has to do is to create a fake account,
> send a bunch of random offensive messages to himself on his real
> account, and then complain - first on TAB - then filing a lawsuit
> (with can envolve both the TAB and the maintainer).
>
> That's why I don't think that, the way it is, this CoC applies
> to us. The way it is, it is just FUD. I can see a few 
> alternatives:
>
> 1) Revert the CoC patch;
> 2) Use another CoC that would work for e-mail-based workflows;
> 3) Patch it - either changing the text of the CoC or adding
>    a prologue adding ammendments to prevent the above risk
>    and solving the e-mail addresses on review tags.
>
> My view is that, currently, we have a major issue at the 
> contributing process. So, if nothing happens, I may wait until
> the Maintainer's Summit before sending any pull requests
> upstream.

I think most of what you write here is FUD.

At the most basic level it says as a maintainer you can't ignore
unacceptable behaviour when you see it or are pointed at it.

Surely there are discussions to be had about what enforcement methods
maintainers have at their disposal, beyond just asking people to behave
themselves, and this may well be subsystem specific. For example, the
drm subsystem operates under freedesktop.org infrastructure, also using
the Contributor Covenant, and we can trivially escalate there to ban
people if asking them is not enough.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Thu, 20 Sep 2018 15:31:03 +0300
Jani Nikula <jani.nikula@intel.com> escreveu:

> On Thu, 20 Sep 2018, Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > Em Thu, 20 Sep 2018 09:33:05 +0300
> > Jani Nikula <jani.nikula@intel.com> escreveu:
> >  
> >> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:  
> >> > My view is that it's intended to be a social document, with guidelines
> >> > for actions within the community  (Actions by maintainers, actions
> >> > by contributors, actions by the TAB).  To me it's more like rules for
> >> > a party at my house.  If someone doesn't abide by the rules, I'll ask
> >> > them to leave the party.  And I'll ask others at the party to remind people
> >> > to abide by the rules.  But the person kicked out can hardly call the cops
> >> > on me for doing so.    
> >> 
> >> Agreed.
> >> 
> >> I think there's much more value in adopting a widely used code of
> >> conduct than writing your own, or even trying to tweak it. If a project
> >> uses the Contributor Covenant, you pretty much know the rules without
> >> actually having to read another document and wonder what this all means.
> >> In this regard, it's really not unlike the GPL for copyleft licenses;
> >> one acronym tells you what you can and can't do.
> >> 
> >> With that perspective, I think the changes proposed in this thread do
> >> more harm than good. If people still insist the text should be improved,
> >> I think the proper flow is to file issues or pull requests to
> >> Contributor Covenant upstream [1], and later update to a new version of
> >> the document.  
> >
> > The main experience of the Contributor Covenant's author seems to be
> > on Github. There is a fundamental difference between a Github-based
> > project workflow and the Kernel: there, everything happens inside a GUI
> > interface. Usually, those projects don't have a large number of
> > maintainers, nor contributors. Message traffic is typically not high.
> >
> > On such kind of interface, the maintainers can edit or delete all
> > kinds of messages, even posted by a third party. So, a text like:
> >
> > 	"Maintainers have the right and responsibility to remove, edit,..."
> >
> > would work. If the number of messages are small, it is also an easy
> > task.
> >
> > It could also work on a smaller e-mail-based project where there is
> > just one or two moderated ML.
> >
> > However, on a higly e-mail based project like the Kernel, where we receive
> > hundreds to thousands of messages per day, and we have a large
> > number of mailing lists, in order to comply with that CoC statement, 
> > all email lists should be moderated. I can't imagine any way to have
> > a list like LKML moderated. Even moderating the linux-media ML nowadays
> > would be really hard, and would be someone's full time job.
> >
> > Even if LF hires a team of moderators for all Kernel mailing lists,
> > if someone cross-post a message on more than one list, different
> > moderators could take different measurements, with could be a problem,
> > if the same email is threated different by the different moderators.
> >
> > Not practical (and it comes with a cost).
> >
> > Using the terms of the CoC, by not taking any measure to stop
> > offensive posts, maintainers wouldn't be "acting in good faith".
> > So, maintainers are violating the policy.
> >
> > Also, if someone felt abused, the "unacceptable behavior may be
> > reported by contacting the Technical Advisory Board (TAB)".
> > The *may* word indicates that he can also go to other places to
> > do a similar complain. Implicitly, it opens space to go to court.
> >
> > So, the practical effect is that, if someone wants to fire
> > a random maintainer, all it has to do is to create a fake account,
> > send a bunch of random offensive messages to himself on his real
> > account, and then complain - first on TAB - then filing a lawsuit
> > (with can envolve both the TAB and the maintainer).
> >
> > That's why I don't think that, the way it is, this CoC applies
> > to us. The way it is, it is just FUD. I can see a few 
> > alternatives:
> >
> > 1) Revert the CoC patch;
> > 2) Use another CoC that would work for e-mail-based workflows;
> > 3) Patch it - either changing the text of the CoC or adding
> >    a prologue adding ammendments to prevent the above risk
> >    and solving the e-mail addresses on review tags.
> >
> > My view is that, currently, we have a major issue at the 
> > contributing process. So, if nothing happens, I may wait until
> > the Maintainer's Summit before sending any pull requests
> > upstream.  
> 
> I think most of what you write here is FUD.

And I think the current CoC maintainer duties are FUD.

> At the most basic level it says as a maintainer you can't ignore
> unacceptable behaviour when you see it or are pointed at it.

That's what the CoC says, not me.

> Surely there are discussions to be had about what enforcement methods
> maintainers have at their disposal, beyond just asking people to behave
> themselves, and this may well be subsystem specific. 

The point is not what maintainers can do. The point is that this
CoC *force* us to take actions. If we don't do:

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

See the word *enforce*. According to it, we're forced to take
actions, or otherwise, we'll suffer repercussions (and not the violators).

The only part of this CoC that mentions what would happen with
a CoC-violator is this:

+Maintainers have the right and responsibility to 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,
+offensive, or harmful.

From what I understood about this CoC, the enforcement happens using
this workflow:

+-------------------------+     +--------------------------------------+     +------------------------+
| maintainer's censorship | --> | bad behavior noticed by a maintainer | --> | maintainer take action |
+-------------------------+     +--------------------------------------+     +------------------------+

+-----------------------------------+     +-------------------+    +-----+     +---------------------+ 
| If maintainers didn't take action | --> | someone complains |--> | TAB | --> | maintainer punished |
+-----------------------------------+     +-------------------+    +-----+     +---------------------+ 

No part of it states that the TAB would take any action against the
infractor. 

The penalties to the infractor, are applied by the maintainer:

1) His posts can be removed, edited, or rejected - on  "comments,
   commits, code, wiki edits, issues, and other contributions".

2) be "temporarily or permanently" banned.

Now, if someone sends an e-mail and it gets mirrored on lots of
places, how are you supposed to "remove/edit/reject"? 

That would only work if you forbid sites to mirror your posts,
and you have admin access there at the archives to manually
edit them.

> For example, the
> drm subsystem operates under freedesktop.org infrastructure, also using
> the Contributor Covenant, and we can trivially escalate there to ban
> people if asking them is not enough.

If you just ban people, you're not following the CoC to the letter.
You'll also need to edit all freedesktop.org archives (including the
ones mirrored outside your domains), removing/editing the unacceptable
behavioral emails.

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Joe Perches]

On Thu, 2018-09-20 at 14:11 +0300, Laurent Pinchart wrote:
> Hi Joe,

Hello Laurent.

> > Maintainers are responsible for code.
> > Community is responsible for behavior.
> 
> Who is "the community", aren't maintainers part of it ?

Of course yes.

Maintainers are not the only part of the community
though and more people should be involved in the
nominal policing of inappropriate behaviors.

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Tim.Bird]

> -----Original Message-----
> From: Mauro Carvalho Chehab 
> Em Thu, 20 Sep 2018 09:33:05 +0300
> Jani Nikula <jani.nikula@intel.com> escreveu:
> 
> > On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
> > > My view is that it's intended to be a social document, with guidelines
> > > for actions within the community  (Actions by maintainers, actions
> > > by contributors, actions by the TAB).  To me it's more like rules for
> > > a party at my house.  If someone doesn't abide by the rules, I'll ask
> > > them to leave the party.  And I'll ask others at the party to remind people
> > > to abide by the rules.  But the person kicked out can hardly call the cops
> > > on me for doing so.
> >
> > Agreed.
> >
> > I think there's much more value in adopting a widely used code of
> > conduct than writing your own, or even trying to tweak it. If a project
> > uses the Contributor Covenant, you pretty much know the rules without
> > actually having to read another document and wonder what this all means.
> > In this regard, it's really not unlike the GPL for copyleft licenses;
> > one acronym tells you what you can and can't do.
> >
> > With that perspective, I think the changes proposed in this thread do
> > more harm than good. If people still insist the text should be improved,
> > I think the proper flow is to file issues or pull requests to
> > Contributor Covenant upstream [1], and later update to a new version of
> > the document.
> 
> The main experience of the Contributor Covenant's author seems to be
> on Github. There is a fundamental difference between a Github-based
> project workflow and the Kernel: there, everything happens inside a GUI
> interface. Usually, those projects don't have a large number of
> maintainers, nor contributors. Message traffic is typically not high.
> 
> On such kind of interface, the maintainers can edit or delete all
> kinds of messages, even posted by a third party. So, a text like:
> 
> 	"Maintainers have the right and responsibility to remove, edit,..."
> 
> would work. If the number of messages are small, it is also an easy
> task.
> 
> It could also work on a smaller e-mail-based project where there is
> just one or two moderated ML.
> 
> However, on a higly e-mail based project like the Kernel, where we receive
> hundreds to thousands of messages per day, and we have a large
> number of mailing lists, in order to comply with that CoC statement,
> all email lists should be moderated. I can't imagine any way to have
> a list like LKML moderated. Even moderating the linux-media ML nowadays
> would be really hard, and would be someone's full time job.
> 
> Even if LF hires a team of moderators for all Kernel mailing lists,
> if someone cross-post a message on more than one list, different
> moderators could take different measurements, with could be a problem,
> if the same email is threated different by the different moderators.
> 
> Not practical (and it comes with a cost).
> 
> Using the terms of the CoC, by not taking any measure to stop
> offensive posts, maintainers wouldn't be "acting in good faith".
> So, maintainers are violating the policy.
> 
> Also, if someone felt abused, the "unacceptable behavior may be
> reported by contacting the Technical Advisory Board (TAB)".
> The *may* word indicates that he can also go to other places to
> do a similar complain. Implicitly, it opens space to go to court.
> 
> So, the practical effect is that, if someone wants to fire
> a random maintainer, all it has to do is to create a fake account,
> send a bunch of random offensive messages to himself on his real
> account, and then complain - first on TAB - then filing a lawsuit
> (with can envolve both the TAB and the maintainer).

I think the risk of a lawsuit is blown out of proportion.
But, I think your characterization of the CoC as not a great fit,
due to the issues you describe above, is justified.

I believe that possibly there's a misperception about the
"direction" of responsibility by Maintainers in the CoC.  For most
projects, the Maintainers are the top of the hierarchy, with all 
the power.  And this section reads to most communities like
a pledge that the Maintainers will defend the community
and the rank-and-file members in it from abusive behavior.
That is, they will take it upon themselves to do this, when
they wouldn't face any repercussions for not making
such a pledge.  It's an honorable and noble thing.

The Linux kernel is a bit more complex than that.  Maintainers at
all levels are usually both contributors as well as leaders, and they're
squished in the middle between other contributors and Linus.

No one wants maintainers or reviewers to feel overwhelmed
by more responsibilities. I think it's a well-acknowledged fact that
maintainers and reviewers are a precious and over-taxed resource.
And we certainly don't want maintainers fearing repercussions
for failing to enforce stuff.  I don't believe there is any record of
an extreme action, like banning, for anyone failing to enforce
a CoC.

> That's why I don't think that, the way it is, this CoC applies
> to us. The way it is, it is just FUD. I can see a few
> alternatives:
> 
> 1) Revert the CoC patch;
> 2) Use another CoC that would work for e-mail-based workflows;
> 3) Patch it - either changing the text of the CoC or adding
>    a prologue adding ammendments to prevent the above risk
>    and solving the e-mail addresses on review tags.
> 
> My view is that, currently, we have a major issue at the
> contributing process. So, if nothing happens, I may wait until
> the Maintainer's Summit before sending any pull requests
> upstream.

May I suggest that a more productive way to proceed is to keep
doing what you usually do.  The TAB is working out the details
of enforcement policy, and a FAQ to go along with the CoC, that we
plan to present at the Maintainers Summit.  I think the roll-out of
CoC enforcement will be a long, slow process, with plenty of
time for us to hash out what we, as a community, believe are the
best practices for dealing with violations.  I think the vast majority of
the kernel community consists of respectful and well-meaning
individuals, who will see no negative repercussions personally, from
the adoption of this CoC.
 -- Tim

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Laurent Pinchart]

Hi Tim,

On Thursday, 20 September 2018 16:49:40 EEST Tim.Bird@sony.com wrote:
> On Thu, 20 Sep 2018 09:33:05 +0300 Mauro Carvalho Chehab wrote:
> > Jani Nikula <jani.nikula@intel.com> escreveu:
> >> On Thu, 20 Sep 2018, Tim.Bird@sony.com wrote:
> >>> My view is that it's intended to be a social document, with guidelines
> >>> for actions within the community  (Actions by maintainers, actions
> >>> by contributors, actions by the TAB).  To me it's more like rules for
> >>> a party at my house.  If someone doesn't abide by the rules, I'll ask
> >>> them to leave the party.  And I'll ask others at the party to remind
> >>> people to abide by the rules.  But the person kicked out can hardly call
> >>> the cops on me for doing so.
> >> 
> >> Agreed.
> >> 
> >> I think there's much more value in adopting a widely used code of
> >> conduct than writing your own, or even trying to tweak it. If a project
> >> uses the Contributor Covenant, you pretty much know the rules without
> >> actually having to read another document and wonder what this all means.
> >> In this regard, it's really not unlike the GPL for copyleft licenses;
> >> one acronym tells you what you can and can't do.
> >> 
> >> With that perspective, I think the changes proposed in this thread do
> >> more harm than good. If people still insist the text should be improved,
> >> I think the proper flow is to file issues or pull requests to
> >> Contributor Covenant upstream [1], and later update to a new version of
> >> the document.
> > 
> > The main experience of the Contributor Covenant's author seems to be
> > on Github. There is a fundamental difference between a Github-based
> > project workflow and the Kernel: there, everything happens inside a GUI
> > interface. Usually, those projects don't have a large number of
> > maintainers, nor contributors. Message traffic is typically not high.
> > 
> > On such kind of interface, the maintainers can edit or delete all
> > 
> > kinds of messages, even posted by a third party. So, a text like:
> > 	"Maintainers have the right and responsibility to remove, edit,..."
> > 
> > would work. If the number of messages are small, it is also an easy
> > task.
> > 
> > It could also work on a smaller e-mail-based project where there is
> > just one or two moderated ML.
> > 
> > However, on a higly e-mail based project like the Kernel, where we receive
> > hundreds to thousands of messages per day, and we have a large
> > number of mailing lists, in order to comply with that CoC statement,
> > all email lists should be moderated. I can't imagine any way to have
> > a list like LKML moderated. Even moderating the linux-media ML nowadays
> > would be really hard, and would be someone's full time job.
> > 
> > Even if LF hires a team of moderators for all Kernel mailing lists,
> > if someone cross-post a message on more than one list, different
> > moderators could take different measurements, with could be a problem,
> > if the same email is threated different by the different moderators.
> > 
> > Not practical (and it comes with a cost).
> > 
> > Using the terms of the CoC, by not taking any measure to stop
> > offensive posts, maintainers wouldn't be "acting in good faith".
> > So, maintainers are violating the policy.
> > 
> > Also, if someone felt abused, the "unacceptable behavior may be
> > reported by contacting the Technical Advisory Board (TAB)".
> > The *may* word indicates that he can also go to other places to
> > do a similar complain. Implicitly, it opens space to go to court.
> > 
> > So, the practical effect is that, if someone wants to fire
> > a random maintainer, all it has to do is to create a fake account,
> > send a bunch of random offensive messages to himself on his real
> > account, and then complain - first on TAB - then filing a lawsuit
> > (with can envolve both the TAB and the maintainer).
> 
> I think the risk of a lawsuit is blown out of proportion.
> But, I think your characterization of the CoC as not a great fit,
> due to the issues you describe above, is justified.
> 
> I believe that possibly there's a misperception about the
> "direction" of responsibility by Maintainers in the CoC.  For most
> projects, the Maintainers are the top of the hierarchy, with all
> the power.  And this section reads to most communities like
> a pledge that the Maintainers will defend the community
> and the rank-and-file members in it from abusive behavior.
> That is, they will take it upon themselves to do this, when
> they wouldn't face any repercussions for not making
> such a pledge.  It's an honorable and noble thing.
> 
> The Linux kernel is a bit more complex than that.  Maintainers at
> all levels are usually both contributors as well as leaders, and they're
> squished in the middle between other contributors and Linus.
> 
> No one wants maintainers or reviewers to feel overwhelmed
> by more responsibilities. I think it's a well-acknowledged fact that
> maintainers and reviewers are a precious and over-taxed resource.
> And we certainly don't want maintainers fearing repercussions
> for failing to enforce stuff.  I don't believe there is any record of
> an extreme action, like banning, for anyone failing to enforce
> a CoC.
> 
> > That's why I don't think that, the way it is, this CoC applies
> > to us. The way it is, it is just FUD. I can see a few
> > alternatives:
> > 
> > 1) Revert the CoC patch;
> > 2) Use another CoC that would work for e-mail-based workflows;
> > 3) Patch it - either changing the text of the CoC or adding
> >    a prologue adding ammendments to prevent the above risk
> >    and solving the e-mail addresses on review tags.
> > 
> > My view is that, currently, we have a major issue at the
> > contributing process. So, if nothing happens, I may wait until
> > the Maintainer's Summit before sending any pull requests
> > upstream.
> 
> May I suggest that a more productive way to proceed is to keep
> doing what you usually do.  The TAB is working out the details
> of enforcement policy, and a FAQ to go along with the CoC, that we
> plan to present at the Maintainers Summit.

May I suggest a (public) forum where everybody could post their concerns ? One 
big concern is that the new code of conduct was dumped on the community 
without much warning, dumping a FAQ the same way without consulting the user 
base could produce a similar feeling.

Discussing the FAQ in public would be best but I understand that would be 
difficult as it would very well quickly go in all kinds of random directions. 
A way to report our concerns and feel heard would in my opinion be a good 
middle ground.

> I think the roll-out of CoC enforcement will be a long, slow process, with
> plenty of time for us to hash out what we, as a community, believe are the
> best practices for dealing with violations.  I think the vast majority of
> the kernel community consists of respectful and well-meaning
> individuals, who will see no negative repercussions personally, from
> the adoption of this CoC.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mark Brown]

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

On Thu, Sep 20, 2018 at 11:53:26AM +0200, Daniel Vetter wrote:
> On Thu, Sep 20, 2018 at 11:12 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:

> > Also, the second paragraph in there openly suggests that maintainers are now
> > expected to reject contributions from the people who behave inappropriately
> > in their view.  Does this mean that I'm expected to reject correct code changes
> > (maybe including bug fixes and maybe even security-critical ones) from a person
> > whose behaviors "deem inappropriate, threatening, offensive, or harmful" in
> > my view?

> Ultimately, yes. On dri-devel we didn't yet have to pull out that
> threat yet. If you look at other communities, a permanent ban (which
> is what you defacto do if you reject all contributions from someone)
> is an extremely rare measure.

> What we have done is temporarily suspend people's commit rights, so
> they can cool down a bit. Or making it clear that we might remove them
> from maintainer duties. The amount of damage a maintainer/committer
> can do is much bigger than someone just submitting patches, so usually
> that's all that's needed. All while making it clear that their
> contributions are still very much welcome. But someone who really only
> wreaks a massive wake of destruction, even if their patches themselves
> are fine, will be thrown out completely from dri-devel. Just not worth
> to deal with.

I did once run into a situation where I just flat out refused to apply
what was apparently a bugfix patch from someone due to the fact that the
commit message consisted entirely of abusive comments about everyone
involved in introducing the bug and they refused to improve the commit
message in any way.  It didn't help that they weren't willing to
describe the bug itself other than to make derogatory comments about
those who couldn't see the issue.  This is just an edge case that's
really extreme and really rare.

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

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Tim.Bird]

> -----Original Message-----
> From: Laurent Pinchart 
> On Thursday, 20 September 2018 16:49:40 EEST Tim.Bird@sony.com wrote:
...
> >  The TAB is working out the details
> > of enforcement policy, and a FAQ to go along with the CoC, that we
> > plan to present at the Maintainers Summit.
> 
> May I suggest a (public) forum where everybody could post their concerns ?
> One
> big concern is that the new code of conduct was dumped on the community
> without much warning, dumping a FAQ the same way without consulting the
> user
> base could produce a similar feeling.
> 
> Discussing the FAQ in public would be best but I understand that would be
> difficult as it would very well quickly go in all kinds of random directions.
> A way to report our concerns and feel heard would in my opinion be a good
> middle ground.

I think having something to discuss before the Maintainers Summit
would be a good idea.  My hope is that a FAQ would give the perspective
of the TAB members on what appear to be the "hot issues" with this change, without
leading to endless wrangling or bike-shedding.

I have found people's input on this list to be extremely valuable to find out
concerns and possible remedies, but this is not the only forum.  (It's just more
tractable than following LKML, for me, at least.)  But I'd be open to other venues.
 -- Tim

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Laurent Pinchart]

Hi Tim,

On Thursday, 20 September 2018 22:14:31 EEST Tim.Bird@sony.com wrote:
> From: Laurent Pinchart
> > On Thursday, 20 September 2018 16:49:40 EEST Tim.Bird@sony.com wrote:
> ...
> 
> >> The TAB is working out the details of enforcement policy, and a FAQ to go
> >> along with the CoC, that we plan to present at the Maintainers Summit.
> > 
> > May I suggest a (public) forum where everybody could post their concerns ?
> > One big concern is that the new code of conduct was dumped on the
> > community without much warning, dumping a FAQ the same way without
> > consulting the user base could produce a similar feeling.
> > 
> > Discussing the FAQ in public would be best but I understand that would be
> > difficult as it would very well quickly go in all kinds of random
> > directions. A way to report our concerns and feel heard would in my
> > opinion be a good middle ground.
> 
> I think having something to discuss before the Maintainers Summit
> would be a good idea.  My hope is that a FAQ would give the perspective
> of the TAB members on what appear to be the "hot issues" with this change,
> without leading to endless wrangling or bike-shedding.
> 
> I have found people's input on this list to be extremely valuable to find
> out concerns and possible remedies, but this is not the only forum.  (It's
> just more tractable than following LKML, for me, at least.)  But I'd be
> open to other venues.

There has been some useful feedback, but I've found the silence on the mailing 
list pretty deafening compared to the importance of the announcement. It 
screams of private conversations, and I feel some reluctance to speak 
publicly, possibly due to the uncertainty of what will happen now. After the 
Bastille fell, it was wise not to speak out before knowing what the new power 
to be would consider appropriate. Having an official forum to report 
questions, doubts, fears and other feelings (I would say concrete proposals 
too, but that could turn into a bit of a bikeshedding chaos) to help making 
sure the FAQ will address the questions of the community - and not the 
questions that the TAB believes are the important ones, even if the TAB tries 
to do its best - would in my opinion be useful. It could be the ksummit-
discuss mailing list, I just feel that some sort of green light is needed. I 
might be too optimistic though.

To lead by example, I'll ask a question of mines. Since Linus' announcement 
that took many people by surprise (obviously not everybody as the code of 
conduct patch was signed by several TAB members, but by no means by a vast 
majority of the community), all sort of discussions took place in private, and 
rumours have started spreading regarding the events that led to this 
situation. I believe I'm not the only one who would like to be informed about 
the history of this unusual development. While I understand that not all 
information can (or should) always be disclosed, this isn't a case of 
voyeurism, some sort of official story would in my opinion help giving 
cohesion to the Linux kernel community.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Dmitry Torokhov]

On Thu, Sep 20, 2018 at 12:55 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Tim,
>
> On Thursday, 20 September 2018 22:14:31 EEST Tim.Bird@sony.com wrote:
> > From: Laurent Pinchart
> > > On Thursday, 20 September 2018 16:49:40 EEST Tim.Bird@sony.com wrote:
> > ...
> >
> > >> The TAB is working out the details of enforcement policy, and a FAQ to go
> > >> along with the CoC, that we plan to present at the Maintainers Summit.
> > >
> > > May I suggest a (public) forum where everybody could post their concerns ?
> > > One big concern is that the new code of conduct was dumped on the
> > > community without much warning, dumping a FAQ the same way without
> > > consulting the user base could produce a similar feeling.
> > >
> > > Discussing the FAQ in public would be best but I understand that would be
> > > difficult as it would very well quickly go in all kinds of random
> > > directions. A way to report our concerns and feel heard would in my
> > > opinion be a good middle ground.
> >
> > I think having something to discuss before the Maintainers Summit
> > would be a good idea.  My hope is that a FAQ would give the perspective
> > of the TAB members on what appear to be the "hot issues" with this change,
> > without leading to endless wrangling or bike-shedding.
> >
> > I have found people's input on this list to be extremely valuable to find
> > out concerns and possible remedies, but this is not the only forum.  (It's
> > just more tractable than following LKML, for me, at least.)  But I'd be
> > open to other venues.
>
> There has been some useful feedback, but I've found the silence on the mailing
> list pretty deafening compared to the importance of the announcement. It
> screams of private conversations, and I feel some reluctance to speak
> publicly, possibly due to the uncertainty of what will happen now. After the
> Bastille fell, it was wise not to speak out before knowing what the new power
> to be would consider appropriate. Having an official forum to report
> questions, doubts, fears and other feelings (I would say concrete proposals
> too, but that could turn into a bit of a bikeshedding chaos) to help making
> sure the FAQ will address the questions of the community - and not the
> questions that the TAB believes are the important ones, even if the TAB tries
> to do its best - would in my opinion be useful. It could be the ksummit-
> discuss mailing list, I just feel that some sort of green light is needed. I
> might be too optimistic though.
>
> To lead by example, I'll ask a question of mines. Since Linus' announcement
> that took many people by surprise (obviously not everybody as the code of
> conduct patch was signed by several TAB members, but by no means by a vast
> majority of the community), all sort of discussions took place in private, and
> rumours have started spreading regarding the events that led to this
> situation. I believe I'm not the only one who would like to be informed about
> the history of this unusual development. While I understand that not all
> information can (or should) always be disclosed, this isn't a case of
> voyeurism, some sort of official story would in my opinion help giving
> cohesion to the Linux kernel community.

I also would like to know how this code of conduct was adopted. The
previous "code of conflict" was at least somewhat circulated among
maintainers, this came out of the blue, at least for me.

Thanks.

-- 
Dmitry

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Jonathan Corbet]

On Thu, 20 Sep 2018 22:55:17 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> After the 
> Bastille fell, it was wise not to speak out before knowing what the new power 
> to be would consider appropriate. Having an official forum to report 
> questions, doubts, fears and other feelings (I would say concrete proposals 
> too, but that could turn into a bit of a bikeshedding chaos) to help making 
> sure the FAQ will address the questions of the community - and not the 
> questions that the TAB believes are the important ones, even if the TAB tries 
> to do its best - would in my opinion be useful. It could be the ksummit-
> discuss mailing list, I just feel that some sort of green light is needed. I 
> might be too optimistic though.

[Speaking for myself only, obviously]

As somebody who has spent the day taking a fair amount of criticism for
saying that people have reasons to be worried about a change done in this
manner, I can relate.

But I don't believe there are any guillotines being set up within the
community, and I think it's crucial that we talk about how we want things
to work.  Nobody should count on the TAB - or the maintainers summit - to
come up with all of the right questions, much less all of the right
answers.  There are some *seriously* irrational discussions happening out
there on the wider net, and we sure don't want to reproduce that here.
But, to the extent that we can discuss things rationally, we should.

> To lead by example, I'll ask a question of mines. Since Linus' announcement 
> that took many people by surprise (obviously not everybody as the code of 
> conduct patch was signed by several TAB members, but by no means by a vast 
> majority of the community), all sort of discussions took place in private, and 
> rumours have started spreading regarding the events that led to this 
> situation. I believe I'm not the only one who would like to be informed about 
> the history of this unusual development.

You're not alone.  I think that almost nobody has the complete picture
right now - me included - and that should be rectified.  I will try to
help make this happen; it may take a little while.

Thanks,

jon

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mauro Carvalho Chehab]

Em Thu, 20 Sep 2018 13:49:40 +0000
<Tim.Bird@sony.com> escreveu:

> May I suggest that a more productive way to proceed is to keep
> doing what you usually do.  The TAB is working out the details
> of enforcement policy, and a FAQ to go along with the CoC, that we
> plan to present at the Maintainers Summit.  I think the roll-out of
> CoC enforcement will be a long, slow process, with plenty of
> time for us to hash out what we, as a community, believe are the
> best practices for dealing with violations. 

Good to know! I'm looking forward to see it and participate at
the discussions there.

As a side note, IMHO, this would be a way better handled if you had
added the new CoC document with some top note on it explaining about
that, and saying that the roll-out to the new CoC will happen only
after having such FAQ discussed and merged upstream.

> I think the vast majority of
> the kernel community consists of respectful and well-meaning
> individuals, who will see no negative repercussions personally, from
> the adoption of this CoC.

Yeah, fully agreed. The concept of having a CoC and be respectful is good. 

The only points I'm not happy is that this particular one doesn't seem to fit
to our development model, as it was conceived with Github in mind.

Thanks,
Mauro

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Mel Gorman]

On Thu, Sep 20, 2018 at 08:04:39AM +0100, David Woodhouse wrote:
> On Thu, 2018-09-20 at 09:33 +0300, Jani Nikula wrote:
> > Agreed.
> > 
> > I think there's much more value in adopting a widely used code of
> > conduct than writing your own, or even trying to tweak it. If a project
> > uses the Contributor Covenant, you pretty much know the rules without
> > actually having to read another document and wonder what this all means.
> > In this regard, it's really not unlike the GPL for copyleft licenses;
> > one acronym tells you what you can and can't do.
> > 
> > With that perspective, I think the changes proposed in this thread do
> > more harm than good. If people still insist the text should be improved,
> > I think the proper flow is to file issues or pull requests to
> > Contributor Covenant upstream [1], and later update to a new version of
> > the document.
> 
> I'll note that isn't what Linus did with the GPL.
> 
> But perhaps there's a possible solution: Instead of editing the text of
> the covenant, just preface it with a statement that email addresses
> used on mailing lists are not considered to be private and that it is
> acceptable (and indeed recommended) to credit individuals who have
> contributed to reporting and testing by using their email addresses.

It's not just email addresses We generally require people to use their
real name and not pseudonyms for patches and their Signed-off-by.

-- 
Mel Gorman
SUSE Labs

Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[Leon Romanovsky]

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

On Mon, Sep 24, 2018 at 02:53:11PM +0100, Mel Gorman wrote:
> On Thu, Sep 20, 2018 at 08:04:39AM +0100, David Woodhouse wrote:
> > On Thu, 2018-09-20 at 09:33 +0300, Jani Nikula wrote:
> > > Agreed.
> > >
> > > I think there's much more value in adopting a widely used code of
> > > conduct than writing your own, or even trying to tweak it. If a project
> > > uses the Contributor Covenant, you pretty much know the rules without
> > > actually having to read another document and wonder what this all means.
> > > In this regard, it's really not unlike the GPL for copyleft licenses;
> > > one acronym tells you what you can and can't do.
> > >
> > > With that perspective, I think the changes proposed in this thread do
> > > more harm than good. If people still insist the text should be improved,
> > > I think the proper flow is to file issues or pull requests to
> > > Contributor Covenant upstream [1], and later update to a new version of
> > > the document.
> >
> > I'll note that isn't what Linus did with the GPL.
> >
> > But perhaps there's a possible solution: Instead of editing the text of
> > the covenant, just preface it with a statement that email addresses
> > used on mailing lists are not considered to be private and that it is
> > acceptable (and indeed recommended) to credit individuals who have
> > contributed to reporting and testing by using their email addresses.
>
> It's not just email addresses We generally require people to use their
> real name and not pseudonyms for patches and their Signed-off-by.

From my understanding, it is covered by DCO clause (d).
https://developercertificate.org/
https://wiki.linuxfoundation.org/dco

Thanks

>
> --
> Mel Gorman
> SUSE Labs
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

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