[Ksummit-discuss] New CoC and Brendan Eich

[Ksummit-discuss] New CoC and Brendan Eich

[jonsmirl]

I would highly recommend getting the new CoC reviewed and approved by
some of the very smart lawyers that help out the Linux community.  I
would also recommend discussing the Brendan Eich situation at Ksummit.
A situation like this needs to be planned for since an improper
response will make things much worse leading to legal challenges.

Some random articles to refresh everyone's memory...
https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marriage-row.html
https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the-right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
https://www.bbc.com/news/technology-26868536
https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Eich-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.html

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Laurent Pinchart]

Hi Jon,

On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:
> I would highly recommend getting the new CoC reviewed and approved by
> some of the very smart lawyers that help out the Linux community.  I
> would also recommend discussing the Brendan Eich situation at Ksummit.
> A situation like this needs to be planned for since an improper
> response will make things much worse leading to legal challenges.
> 
> Some random articles to refresh everyone's memory...
> https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/
> digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria
> ge-row.html
> https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the-> right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
> https://www.bbc.com/news/technology-26868536
> https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei
> ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h
> tml

We're facing a textbook case that has a probability of generating heated 
discussions no lower than 100%. I remember having a pretty strong opinion on 
the topic when it came under public scrutiny (and while I generally don't mind 
discussing it, I won't disclose that opinion here as that's entirely 
irrelevant). The more interesting part was that waiting for the debate to cool 
down gave me time to think, and realize that what is often perceived as a 
black-and-white situation most often turns out to be more complex than 
initially perceived.

One point that I would like to explore is thus how we can take the time needed 
to solve such matters when the mob is waiting outside of the courtroom with 
tar and feathers. I don't want to discuss here what our response to such a 
case should be, but the process that we should follow to come up with a 
response. It is of paramount importance in my opinion for the body tasked with 
handling those issues to follow a process that ensures it will be able to keep 
a cool head and have enough time available to think the response carefully.

Another point that I believe is important is the issue of representation. The 
code of conduct mentions both "project" and "community". While neither are 
defined, the term project is quite straightforward, but the term community not 
really so. The code of conduct gives a mandate to the TAB to handle 
enforcement in the name of the project (I don't want to focus here on whether 
the TAB is the right instance to handle those issues, this will likely be 
discusses separately and possibly be changed, I will just use TAB here to 
refer to the code of conduct enforcement body for simplicity), and I would 
argue that the mandate extends to representing the community as a whole. When 
the TAB will have to decide on a case that will generate a wide diversity of 
opinions, what kind of process can we put in place to ensure that all 
community members will feel represented (and thus heard) ? To put it 
differently, how can we make sure that the community members who don't fully 
agree with the final decision will agree to disagree and still feel part of 
the community ?

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] New CoC and Brendan Eich

[jonsmirl]

On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Jon,
>
> On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:
> > I would highly recommend getting the new CoC reviewed and approved by
> > some of the very smart lawyers that help out the Linux community.  I
> > would also recommend discussing the Brendan Eich situation at Ksummit.
> > A situation like this needs to be planned for since an improper
> > response will make things much worse leading to legal challenges.
> >
> > Some random articles to refresh everyone's memory...
> > https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/
> > digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria
> > ge-row.html
> > https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the-> right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
> > https://www.bbc.com/news/technology-26868536
> > https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei
> > ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h
> > tml
>
> We're facing a textbook case that has a probability of generating heated
> discussions no lower than 100%. I remember having a pretty strong opinion on
> the topic when it came under public scrutiny (and while I generally don't mind
> discussing it, I won't disclose that opinion here as that's entirely
> irrelevant). The more interesting part was that waiting for the debate to cool
> down gave me time to think, and realize that what is often perceived as a
> black-and-white situation most often turns out to be more complex than
> initially perceived.
>
> One point that I would like to explore is thus how we can take the time needed
> to solve such matters when the mob is waiting outside of the courtroom with
> tar and feathers. I don't want to discuss here what our response to such a
> case should be, but the process that we should follow to come up with a
> response. It is of paramount importance in my opinion for the body tasked with
> handling those issues to follow a process that ensures it will be able to keep
> a cool head and have enough time available to think the response carefully.

What is going to happen when someone gets fired after being accused of
violating the CoC and they lose $20M in options? INAL but it appears
to me that the CoC has created lawsuit exposure for all of the
maintainers. This CoC really needs to be vetted by the kernel legal
team.

>
> Another point that I believe is important is the issue of representation. The
> code of conduct mentions both "project" and "community". While neither are
> defined, the term project is quite straightforward, but the term community not
> really so. The code of conduct gives a mandate to the TAB to handle
> enforcement in the name of the project (I don't want to focus here on whether
> the TAB is the right instance to handle those issues, this will likely be
> discusses separately and possibly be changed, I will just use TAB here to
> refer to the code of conduct enforcement body for simplicity), and I would
> argue that the mandate extends to representing the community as a whole. When
> the TAB will have to decide on a case that will generate a wide diversity of
> opinions, what kind of process can we put in place to ensure that all
> community members will feel represented (and thus heard) ? To put it
> differently, how can we make sure that the community members who don't fully
> agree with the final decision will agree to disagree and still feel part of
> the community ?
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Rodrigo Vivi]

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

On Thu, Oct 4, 2018 at 12:06 PM jonsmirl@gmail.com <jonsmirl@gmail.com>
wrote:

> On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> >
> > Hi Jon,
> >
> > On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:
> > > I would highly recommend getting the new CoC reviewed and approved by
> > > some of the very smart lawyers that help out the Linux community.  I
> > > would also recommend discussing the Brendan Eich situation at Ksummit.
> > > A situation like this needs to be planned for since an improper
> > > response will make things much worse leading to legal challenges.
> > >
> > > Some random articles to refresh everyone's memory...
> > >
> https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/
> > >
> digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria
> > > ge-row.html
> > >
> https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the->
> right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
> > > https://www.bbc.com/news/technology-26868536
> > >
> https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei
> > >
> ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h
> > > tml
> >
> > We're facing a textbook case that has a probability of generating heated
> > discussions no lower than 100%. I remember having a pretty strong
> opinion on
> > the topic when it came under public scrutiny (and while I generally
> don't mind
> > discussing it, I won't disclose that opinion here as that's entirely
> > irrelevant). The more interesting part was that waiting for the debate
> to cool
> > down gave me time to think, and realize that what is often perceived as a
> > black-and-white situation most often turns out to be more complex than
> > initially perceived.
> >
> > One point that I would like to explore is thus how we can take the time
> needed
> > to solve such matters when the mob is waiting outside of the courtroom
> with
> > tar and feathers. I don't want to discuss here what our response to such
> a
> > case should be, but the process that we should follow to come up with a
> > response. It is of paramount importance in my opinion for the body
> tasked with
> > handling those issues to follow a process that ensures it will be able
> to keep
> > a cool head and have enough time available to think the response
> carefully.
>
> What is going to happen when someone gets fired after being accused of
> violating the CoC and they lose $20M in options? INAL but it appears
> to me that the CoC has created lawsuit exposure for all of the
> maintainers. This CoC really needs to be vetted by the kernel legal
> team.
>

you mean If someone gets fired for violating respect to the other human
being in public?!
I'm afraid this already happen around the world. And I never saw anyone
blaming news or social networks for that. The cause of this consequence is
on the speech itself, not on the channels....


>
> >
> > Another point that I believe is important is the issue of
> representation. The
> > code of conduct mentions both "project" and "community". While neither
> are
> > defined, the term project is quite straightforward, but the term
> community not
> > really so. The code of conduct gives a mandate to the TAB to handle
> > enforcement in the name of the project (I don't want to focus here on
> whether
> > the TAB is the right instance to handle those issues, this will likely be
> > discusses separately and possibly be changed, I will just use TAB here to
> > refer to the code of conduct enforcement body for simplicity), and I
> would
> > argue that the mandate extends to representing the community as a whole.
> When
> > the TAB will have to decide on a case that will generate a wide
> diversity of
> > opinions, what kind of process can we put in place to ensure that all
> > community members will feel represented (and thus heard) ? To put it
> > differently, how can we make sure that the community members who don't
> fully
> > agree with the final decision will agree to disagree and still feel part
> of
> > the community ?
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
> >
> >
> >
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>

[-- Attachment #2: Type: text/html, Size: 6215 bytes --]

Re: [Ksummit-discuss] New CoC and Brendan Eich

[jonsmirl]

On Thu, Oct 4, 2018 at 3:21 PM Rodrigo Vivi <rodrigo.vivi@gmail.com> wrote:
>
>
>
> On Thu, Oct 4, 2018 at 12:06 PM jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>>
>> On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>> >
>> > Hi Jon,
>> >
>> > On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:
>> > > I would highly recommend getting the new CoC reviewed and approved by
>> > > some of the very smart lawyers that help out the Linux community.  I
>> > > would also recommend discussing the Brendan Eich situation at Ksummit.
>> > > A situation like this needs to be planned for since an improper
>> > > response will make things much worse leading to legal challenges.
>> > >
>> > > Some random articles to refresh everyone's memory...
>> > > https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/
>> > > digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria
>> > > ge-row.html
>> > > https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the-> right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
>> > > https://www.bbc.com/news/technology-26868536
>> > > https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei
>> > > ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h
>> > > tml
>> >
>> > We're facing a textbook case that has a probability of generating heated
>> > discussions no lower than 100%. I remember having a pretty strong opinion on
>> > the topic when it came under public scrutiny (and while I generally don't mind
>> > discussing it, I won't disclose that opinion here as that's entirely
>> > irrelevant). The more interesting part was that waiting for the debate to cool
>> > down gave me time to think, and realize that what is often perceived as a
>> > black-and-white situation most often turns out to be more complex than
>> > initially perceived.
>> >
>> > One point that I would like to explore is thus how we can take the time needed
>> > to solve such matters when the mob is waiting outside of the courtroom with
>> > tar and feathers. I don't want to discuss here what our response to such a
>> > case should be, but the process that we should follow to come up with a
>> > response. It is of paramount importance in my opinion for the body tasked with
>> > handling those issues to follow a process that ensures it will be able to keep
>> > a cool head and have enough time available to think the response carefully.
>>
>> What is going to happen when someone gets fired after being accused of
>> violating the CoC and they lose $20M in options? INAL but it appears
>> to me that the CoC has created lawsuit exposure for all of the
>> maintainers. This CoC really needs to be vetted by the kernel legal
>> team.
>
>
> you mean If someone gets fired for violating respect to the other human being in public?!
> I'm afraid this already happen around the world. And I never saw anyone blaming news or social networks for that. The cause of this consequence is on the speech itself, not on the channels....

With that much money on the line the person who got fired is likely to
sue the maintainer for their role in the accusation.  Now the
maintainer is stuck with a legal defense burden.

>
>>
>>
>> >
>> > Another point that I believe is important is the issue of representation. The
>> > code of conduct mentions both "project" and "community". While neither are
>> > defined, the term project is quite straightforward, but the term community not
>> > really so. The code of conduct gives a mandate to the TAB to handle
>> > enforcement in the name of the project (I don't want to focus here on whether
>> > the TAB is the right instance to handle those issues, this will likely be
>> > discusses separately and possibly be changed, I will just use TAB here to
>> > refer to the code of conduct enforcement body for simplicity), and I would
>> > argue that the mandate extends to representing the community as a whole. When
>> > the TAB will have to decide on a case that will generate a wide diversity of
>> > opinions, what kind of process can we put in place to ensure that all
>> > community members will feel represented (and thus heard) ? To put it
>> > differently, how can we make sure that the community members who don't fully
>> > agree with the final decision will agree to disagree and still feel part of
>> > the community ?
>> >
>> > --
>> > Regards,
>> >
>> > Laurent Pinchart
>> >
>> >
>> >
>>
>>
>> --
>> Jon Smirl
>> jonsmirl@gmail.com
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Geert Uytterhoeven]

Hi Rodrigo,

On Thu, Oct 4, 2018 at 9:22 PM Rodrigo Vivi <rodrigo.vivi@gmail.com> wrote:
> On Thu, Oct 4, 2018 at 12:06 PM jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>> > On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:
>> > > I would highly recommend getting the new CoC reviewed and approved by
>> > > some of the very smart lawyers that help out the Linux community.  I
>> > > would also recommend discussing the Brendan Eich situation at Ksummit.
>> > > A situation like this needs to be planned for since an improper
>> > > response will make things much worse leading to legal challenges.
>> > >
>> > > Some random articles to refresh everyone's memory...
>> > > https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/
>> > > digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria
>> > > ge-row.html
>> > > https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the-> right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
>> > > https://www.bbc.com/news/technology-26868536
>> > > https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei
>> > > ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h
>> > > tml
>> >
>> > We're facing a textbook case that has a probability of generating heated
>> > discussions no lower than 100%. I remember having a pretty strong opinion on
>> > the topic when it came under public scrutiny (and while I generally don't mind
>> > discussing it, I won't disclose that opinion here as that's entirely
>> > irrelevant). The more interesting part was that waiting for the debate to cool
>> > down gave me time to think, and realize that what is often perceived as a
>> > black-and-white situation most often turns out to be more complex than
>> > initially perceived.
>> >
>> > One point that I would like to explore is thus how we can take the time needed
>> > to solve such matters when the mob is waiting outside of the courtroom with
>> > tar and feathers. I don't want to discuss here what our response to such a
>> > case should be, but the process that we should follow to come up with a
>> > response. It is of paramount importance in my opinion for the body tasked with
>> > handling those issues to follow a process that ensures it will be able to keep
>> > a cool head and have enough time available to think the response carefully.
>>
>> What is going to happen when someone gets fired after being accused of
>> violating the CoC and they lose $20M in options? INAL but it appears
>> to me that the CoC has created lawsuit exposure for all of the
>> maintainers. This CoC really needs to be vetted by the kernel legal
>> team.
>
> you mean If someone gets fired for violating respect to the other human being in public?!

If you formulate it that way, it is an easy answer.
Unfortunately reality won't be that black-and-white.

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] New CoC and Brendan Eich

[Mauro Carvalho Chehab]

Em Thu, 4 Oct 2018 12:21:42 -0700
Rodrigo Vivi <rodrigo.vivi@gmail.com> escreveu:

> On Thu, Oct 4, 2018 at 12:06 PM jonsmirl@gmail.com <jonsmirl@gmail.com>
> wrote:
> 
> > On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:  
> > >
> > > Hi Jon,
> > >
> > > On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:  
> > > > I would highly recommend getting the new CoC reviewed and approved by
> > > > some of the very smart lawyers that help out the Linux community.  I
> > > > would also recommend discussing the Brendan Eich situation at Ksummit.
> > > > A situation like this needs to be planned for since an improper
> > > > response will make things much worse leading to legal challenges.
> > > >
> > > > Some random articles to refresh everyone's memory...
> > > >  
> > https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/  
> > > >  
> > digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria  
> > > > ge-row.html
> > > >  
> > https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the->
> > right-to-fight-gay-rights-but-not-to-be-mozillas-ceo  
> > > > https://www.bbc.com/news/technology-26868536
> > > >  
> > https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei  
> > > >  
> > ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h  
> > > > tml  
> > >
> > > We're facing a textbook case that has a probability of generating heated
> > > discussions no lower than 100%. I remember having a pretty strong  
> > opinion on  
> > > the topic when it came under public scrutiny (and while I generally  
> > don't mind  
> > > discussing it, I won't disclose that opinion here as that's entirely
> > > irrelevant). The more interesting part was that waiting for the debate  
> > to cool  
> > > down gave me time to think, and realize that what is often perceived as a
> > > black-and-white situation most often turns out to be more complex than
> > > initially perceived.
> > >
> > > One point that I would like to explore is thus how we can take the time  
> > needed  
> > > to solve such matters when the mob is waiting outside of the courtroom  
> > with  
> > > tar and feathers. I don't want to discuss here what our response to such  
> > a  
> > > case should be, but the process that we should follow to come up with a
> > > response. It is of paramount importance in my opinion for the body  
> > tasked with  
> > > handling those issues to follow a process that ensures it will be able  
> > to keep  
> > > a cool head and have enough time available to think the response  
> > carefully.
> >
> > What is going to happen when someone gets fired after being accused of
> > violating the CoC and they lose $20M in options? INAL but it appears
> > to me that the CoC has created lawsuit exposure for all of the
> > maintainers. This CoC really needs to be vetted by the kernel legal
> > team.
> >  
> 
> you mean If someone gets fired for violating respect to the other human
> being in public?!
> I'm afraid this already happen around the world. And I never saw anyone
> blaming news or social networks for that. The cause of this consequence is
> on the speech itself, not on the channels....

No, that's not what's written at the letter of the CoC. It is written
there that:

If developer A violates the CoC insulting developer B, the maintainer C is
responsible to take actions against developer B.

If maintainer C doesn't take actions[1], developer B can complain to
TAB against maintainer C (and not against developer A).

In other words, at the light of this CoC, the one that should be held
into account is not the one that lacked respect. It is someone else
that was unable to "educate" developer A.

[1] It should be notice that, even the best good will maintainer
won't be able to enforce the CoC, as several actions are impossible to
handle for an e-mail-based workflow: maintainer B can't edit or 
remove all copies of an email that developer A posted on a public
mailing list and their mirrors. Even his capability of banning developer A
is limited, as he usually doesn't maintain the e-mail server. So, he has
to ask someone else to do that.

Thanks,
Mauro

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Rodrigo Vivi]

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

On Mon, Oct 8, 2018 at 2:35 PM Mauro Carvalho Chehab <
mchehab+samsung@kernel.org> wrote:

> Em Thu, 4 Oct 2018 12:21:42 -0700
> Rodrigo Vivi <rodrigo.vivi@gmail.com> escreveu:
>
> > On Thu, Oct 4, 2018 at 12:06 PM jonsmirl@gmail.com <jonsmirl@gmail.com>
> > wrote:
> >
> > > On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart
> > > <laurent.pinchart@ideasonboard.com> wrote:
> > > >
> > > > Hi Jon,
> > > >
> > > > On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com
> wrote:
> > > > > I would highly recommend getting the new CoC reviewed and approved
> by
> > > > > some of the very smart lawyers that help out the Linux community.
> I
> > > > > would also recommend discussing the Brendan Eich situation at
> Ksummit.
> > > > > A situation like this needs to be planned for since an improper
> > > > > response will make things much worse leading to legal challenges.
> > > > >
> > > > > Some random articles to refresh everyone's memory...
> > > > >
> > >
> https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelecoms/
>
> > > > >
> > >
> digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-gay-marria
>
> > > > > ge-row.html
> > > > >
> > >
> https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-the-
> >
> > > right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
> > > > > https://www.bbc.com/news/technology-26868536
> > > > >
> > >
> https://www.telegraph.co.uk/technology/technology-topics/10745283/Brendan-Ei
>
> > > > >
> > >
> ch-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-our-jobs.h
>
> > > > > tml
> > > >
> > > > We're facing a textbook case that has a probability of generating
> heated
> > > > discussions no lower than 100%. I remember having a pretty strong
> > > opinion on
> > > > the topic when it came under public scrutiny (and while I generally
> > > don't mind
> > > > discussing it, I won't disclose that opinion here as that's entirely
> > > > irrelevant). The more interesting part was that waiting for the
> debate
> > > to cool
> > > > down gave me time to think, and realize that what is often perceived
> as a
> > > > black-and-white situation most often turns out to be more complex
> than
> > > > initially perceived.
> > > >
> > > > One point that I would like to explore is thus how we can take the
> time
> > > needed
> > > > to solve such matters when the mob is waiting outside of the
> courtroom
> > > with
> > > > tar and feathers. I don't want to discuss here what our response to
> such
> > > a
> > > > case should be, but the process that we should follow to come up
> with a
> > > > response. It is of paramount importance in my opinion for the body
> > > tasked with
> > > > handling those issues to follow a process that ensures it will be
> able
> > > to keep
> > > > a cool head and have enough time available to think the response
> > > carefully.
> > >
> > > What is going to happen when someone gets fired after being accused of
> > > violating the CoC and they lose $20M in options? INAL but it appears
> > > to me that the CoC has created lawsuit exposure for all of the
> > > maintainers. This CoC really needs to be vetted by the kernel legal
> > > team.
> > >
> >
> > you mean If someone gets fired for violating respect to the other human
> > being in public?!
> > I'm afraid this already happen around the world. And I never saw anyone
> > blaming news or social networks for that. The cause of this consequence
> is
> > on the speech itself, not on the channels....
>
> No, that's not what's written at the letter of the CoC. It is written
> there that:
>
> If developer A violates the CoC insulting developer B, the maintainer C is
> responsible to take actions against developer B.
>
> If maintainer C doesn't take actions[1], developer B can complain to
> TAB against maintainer C (and not against developer A).
>
> In other words, at the light of this CoC, the one that should be held
> into account is not the one that lacked respect. It is someone else
> that was unable to "educate" developer A.
>
> [1] It should be notice that, even the best good will maintainer
> won't be able to enforce the CoC, as several actions are impossible to
> handle for an e-mail-based workflow: maintainer B can't edit or
> remove all copies of an email that developer A posted on a public
> mailing list and their mirrors. Even his capability of banning developer A
> is limited, as he usually doesn't maintain the e-mail server. So, he has
> to ask someone else to do that.
>

Thanks for explaining like this. Maybe now I understand why some people
are freaking out about it.

But in my simplified example just add the Maintainer as conniving.

So, a company would fire maintainer for being conniving with an harassment
or any other unacceptable behavior, right?!

So, Developer A shouts racists words, maintainer C doesn't C the email.
Developer B complains to the TAB against Developer A and Maintainer C.

Should TAB ban permanently Maintainer C? I think temporarily is an option
really
clear there. But I assume TAB will listen to all sides and see all archive
before
taking any harsh decision like this.

I think the permanent ban would be just on cases when things are repeating
and when maintainer was clearly conniving with the action.

Ok, maybe this COC should be expanding to add TABs recommendation and leave
it
more crispy and clear.

However all I'm currently seeing on the patches that are floating lately
are using little unlikely corner cases to justify to remove critical parts
of the code of conduct such as the highlight that racism is unacceptable.

Thanks,
Rodrigo.


>
> Thanks,
> Mauro
>

[-- Attachment #2: Type: text/html, Size: 8053 bytes --]

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Mauro Carvalho Chehab]

Em Mon, 8 Oct 2018 16:20:05 -0700
Rodrigo Vivi <rodrigo.vivi@gmail.com> escreveu:

> > > > What is going to happen when someone gets fired after being accused of
> > > > violating the CoC and they lose $20M in options? INAL but it appears
> > > > to me that the CoC has created lawsuit exposure for all of the
> > > > maintainers. This CoC really needs to be vetted by the kernel legal
> > > > team.
> > > >  
> > >
> > > you mean If someone gets fired for violating respect to the other human
> > > being in public?!
> > > I'm afraid this already happen around the world. And I never saw anyone
> > > blaming news or social networks for that. The cause of this consequence  
> > is  
> > > on the speech itself, not on the channels....  
> >
> > No, that's not what's written at the letter of the CoC. It is written
> > there that:
> >
> > If developer A violates the CoC insulting developer B, the maintainer C is
> > responsible to take actions against developer B.
> >
> > If maintainer C doesn't take actions[1], developer B can complain to
> > TAB against maintainer C (and not against developer A).
> >
> > In other words, at the light of this CoC, the one that should be held
> > into account is not the one that lacked respect. It is someone else
> > that was unable to "educate" developer A.
> >
> > [1] It should be notice that, even the best good will maintainer
> > won't be able to enforce the CoC, as several actions are impossible to
> > handle for an e-mail-based workflow: maintainer B can't edit or
> > remove all copies of an email that developer A posted on a public
> > mailing list and their mirrors. Even his capability of banning developer A
> > is limited, as he usually doesn't maintain the e-mail server. So, he has
> > to ask someone else to do that.
> >  
> 
> Thanks for explaining like this. Maybe now I understand why some people
> are freaking out about it.
> 
> But in my simplified example just add the Maintainer as conniving.

That is just plain wrong. You can blame the Internet infrastructure
for not allowing removing or editing the text of a previously sent
e-mail. Another e-mail technology, developed back at the eighties
would have allowed such changes (X.400).

In any case, the maintainer can't really take any action about that.
What it is sent, can't be edited anymore. Also, usually, if one
tries to reply to a troll who posts insults, all you get is more
insults. There are plenty of examples like that at public mailing lists.

> So, a company would fire maintainer for being conniving with an harassment
> or any other unacceptable behavior, right?!
> 
> So, Developer A shouts racists words, maintainer C doesn't C the email.
> Developer B complains to the TAB against Developer A and Maintainer C.

No. If you read the CoC carefully, you'll see that it doesn't
have anything saying that TAB would be taking any action against
Developer A. The only person that this CoC who would be punished,
on this CoC's "enforcement" section is the maintainer.

-

See, this CoC was conceived with Github in mind. There, both the
author of a comment/issue/PR/... and the maintainers of a project have
full rights to edit or remove any post.

Also, there is a company behind Github that needs a way to protect
themselves from being sued if someone post harassment messages there
(because this is illegal on several places).

On a Github like service, the hole of the people who will prevent illegal
posts are the ones that own or co-maintain projects. If they're not
willing to do it, then Github can impose bans.

In other words, if someone comes after Github due to an harassment
post, they have legal ways to impose penalties to the ones that
aren't enforcing their policies. The same applies to a project
owner that gave commit grants to other developers: they can also
ban them if, for example, a PR with some harassment text on
it gets merged.

-

The way it is, the way it is currently written, I can't see how this
particular CoC would work for e-mails, as technically, there's no way
for anyone to remove a post that was already sent. It won't work either
for Bugzilla or Trac, as there nobody can edit or remove any entry
(not even the author). People can only add new comments.

I'd say that, even wiki pages (using Mediawiki, for example)
won't fully complain. There, people can be banned and contents
can be edited, but if one looks at the page history, the old
content can still be seen.

In other words, if we use this particular CoC, we need to either
to fix it or to change our workflow to only use Github (or a similar
implementation with the same concepts in mind) and don't use
anymore e-mails, bugzilla, mediawiki, ...

Thanks,
Mauro

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Rodrigo Vivi]

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

On Tue, Oct 9, 2018 at 3:07 AM Mauro Carvalho Chehab <
mchehab+samsung@kernel.org> wrote:

> Em Mon, 8 Oct 2018 16:20:05 -0700
> Rodrigo Vivi <rodrigo.vivi@gmail.com> escreveu:
>
> > > > > What is going to happen when someone gets fired after being
> accused of
> > > > > violating the CoC and they lose $20M in options? INAL but it
> appears
> > > > > to me that the CoC has created lawsuit exposure for all of the
> > > > > maintainers. This CoC really needs to be vetted by the kernel legal
> > > > > team.
> > > > >
> > > >
> > > > you mean If someone gets fired for violating respect to the other
> human
> > > > being in public?!
> > > > I'm afraid this already happen around the world. And I never saw
> anyone
> > > > blaming news or social networks for that. The cause of this
> consequence
> > > is
> > > > on the speech itself, not on the channels....
> > >
> > > No, that's not what's written at the letter of the CoC. It is written
> > > there that:
> > >
> > > If developer A violates the CoC insulting developer B, the maintainer
> C is
> > > responsible to take actions against developer B.
> > >
> > > If maintainer C doesn't take actions[1], developer B can complain to
> > > TAB against maintainer C (and not against developer A).
> > >
> > > In other words, at the light of this CoC, the one that should be held
> > > into account is not the one that lacked respect. It is someone else
> > > that was unable to "educate" developer A.
> > >
> > > [1] It should be notice that, even the best good will maintainer
> > > won't be able to enforce the CoC, as several actions are impossible to
> > > handle for an e-mail-based workflow: maintainer B can't edit or
> > > remove all copies of an email that developer A posted on a public
> > > mailing list and their mirrors. Even his capability of banning
> developer A
> > > is limited, as he usually doesn't maintain the e-mail server. So, he
> has
> > > to ask someone else to do that.
> > >
> >
> > Thanks for explaining like this. Maybe now I understand why some people
> > are freaking out about it.
> >
> > But in my simplified example just add the Maintainer as conniving.
>
> That is just plain wrong. You can blame the Internet infrastructure
> for not allowing removing or editing the text of a previously sent
> e-mail. Another e-mail technology, developed back at the eighties
> would have allowed such changes (X.400).
>
> In any case, the maintainer can't really take any action about that.
> What it is sent, can't be edited anymore. Also, usually, if one
> tries to reply to a troll who posts insults, all you get is more
> insults. There are plenty of examples like that at public mailing lists.
>

So let's rewrite in a way that is "edit or reject if possible" or whenever
possible
or something like that. Because if we can edit but don't take any action we
are
being conniving.


>
> > So, a company would fire maintainer for being conniving with an
> harassment
> > or any other unacceptable behavior, right?!
> >
> > So, Developer A shouts racists words, maintainer C doesn't C the email.
> > Developer B complains to the TAB against Developer A and Maintainer C.
>
> No. If you read the CoC carefully, you'll see that it doesn't
> have anything saying that TAB would be taking any action against
> Developer A. The only person that this CoC who would be punished,
> on this CoC's "enforcement" section is the maintainer.
>

And what I'm suggesting is to do additions to make it more clear about
the procedures and recommendations.
Instead of remove critical parts.


>
> -
>
> See, this CoC was conceived with Github in mind. There, both the
> author of a comment/issue/PR/... and the maintainers of a project have
> full rights to edit or remove any post.
>

So let's fix this by making clear that we need to edit whenever possible...


>
> Also, there is a company behind Github that needs a way to protect
> themselves from being sued if someone post harassment messages there
> (because this is illegal on several places).
>

Another reason to move faster to Gitlab?



>
> On a Github like service, the hole of the people who will prevent illegal
> posts are the ones that own or co-maintain projects. If they're not
> willing to do it, then Github can impose bans.
>
> In other words, if someone comes after Github due to an harassment
> post, they have legal ways to impose penalties to the ones that
> aren't enforcing their policies. The same applies to a project
> owner that gave commit grants to other developers: they can also
> ban them if, for example, a PR with some harassment text on
> it gets merged.


> -
>
> The way it is, the way it is currently written, I can't see how this
> particular CoC would work for e-mails, as technically, there's no way
> for anyone to remove a post that was already sent. It won't work either
> for Bugzilla or Trac, as there nobody can edit or remove any entry
> (not even the author). People can only add new comments.
>
> I'd say that, even wiki pages (using Mediawiki, for example)
> won't fully complain. There, people can be banned and contents
> can be edited, but if one looks at the page history, the old
> content can still be seen.
>
> In other words, if we use this particular CoC, we need to either
> to fix it or to change our workflow to only use Github (or a similar
> implementation with the same concepts in mind) and don't use
> anymore e-mails, bugzilla, mediawiki, ...
>
> Thanks,
> Mauro
>

[-- Attachment #2: Type: text/html, Size: 7322 bytes --]

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Chris Mason]

On 9 Oct 2018, at 6:07, Mauro Carvalho Chehab wrote:

>> So, a company would fire maintainer for being conniving with an 
>> harassment
>> or any other unacceptable behavior, right?!
>>
>> So, Developer A shouts racists words, maintainer C doesn't C the 
>> email.
>> Developer B complains to the TAB against Developer A and Maintainer 
>> C.
>
> No. If you read the CoC carefully, you'll see that it doesn't
> have anything saying that TAB would be taking any action against
> Developer A. The only person that this CoC who would be punished,
> on this CoC's "enforcement" section is the maintainer.

The code of conduct asks maintainers to be involved in maintaining 
culture as well as code.  It does mention repercussions for maintainers, 
but it's important to apply some common sense here.  If you enable 
people to send in terrible code, someone is going to talk to you about 
your poor decisions.  If you're enabling people to violate the code of 
conduct, it's a good idea to sit down and talk about ways to improve the 
level of discourse in your subsystem.

The repercussions are most likely going to be working on methods to try 
and make things better.  Then if they don't work...trying again.

-chris

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Dan Williams]

On Tue, Oct 9, 2018 at 9:53 AM Chris Mason <clm@fb.com> wrote:
>
> On 9 Oct 2018, at 6:07, Mauro Carvalho Chehab wrote:
>
> >> So, a company would fire maintainer for being conniving with an
> >> harassment
> >> or any other unacceptable behavior, right?!
> >>
> >> So, Developer A shouts racists words, maintainer C doesn't C the
> >> email.
> >> Developer B complains to the TAB against Developer A and Maintainer
> >> C.
> >
> > No. If you read the CoC carefully, you'll see that it doesn't
> > have anything saying that TAB would be taking any action against
> > Developer A. The only person that this CoC who would be punished,
> > on this CoC's "enforcement" section is the maintainer.
>
> The code of conduct asks maintainers to be involved in maintaining
> culture as well as code.  It does mention repercussions for maintainers,
> but it's important to apply some common sense here.  If you enable
> people to send in terrible code, someone is going to talk to you about
> your poor decisions.  If you're enabling people to violate the code of
> conduct, it's a good idea to sit down and talk about ways to improve the
> level of discourse in your subsystem.

I'd also add, it's clear that these situations can be messy and a
maintainer may not feel equipped, or have the emotional resources to
engage at all times. So I think reasonable way for a maintainer to
engage is to simply ask for help. At a minimum we need trusted people
in the community that are willing to be available to help out
contributors and fellow maintainers alike, and the TAB is tasked with
being available to help. That was the situation with the previous
code, this one is more explicit, but the intent is the same to have a
concerted effort and an escalation path to help keep development
discourse productive.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Geert Uytterhoeven]

On Wed, Oct 10, 2018 at 12:03 AM Dan Williams <dan.j.williams@intel.com> wrote:
> On Tue, Oct 9, 2018 at 9:53 AM Chris Mason <clm@fb.com> wrote:
> > On 9 Oct 2018, at 6:07, Mauro Carvalho Chehab wrote:
> > >> So, a company would fire maintainer for being conniving with an
> > >> harassment
> > >> or any other unacceptable behavior, right?!
> > >>
> > >> So, Developer A shouts racists words, maintainer C doesn't C the
> > >> email.
> > >> Developer B complains to the TAB against Developer A and Maintainer
> > >> C.
> > >
> > > No. If you read the CoC carefully, you'll see that it doesn't
> > > have anything saying that TAB would be taking any action against
> > > Developer A. The only person that this CoC who would be punished,
> > > on this CoC's "enforcement" section is the maintainer.

Indeed.

The only repercussion for violators (not considering existing legal
frameworks) is being banned, and/or their work being rejected, but not by
the TAB.

The CoC says it is the _maintainer_'s responsibility to take action
w.r.t. the violator, by (translated to Linux kernel development and
maintenance tasks):
  1) Replying to email clarifying the standards of acceptable behavior,
  2) Removing or editing the comment and/or contribution,
  3) Editing the patch description and/or patch body,
  4) Rejecting the patch,
  5) Banning the contributor from the mailing list,

2) cannot be done on public mailing lists,
5) also needs external help from the mailing list administrator, so it is not
    under direct control of the maintainer.

So "Maintainers have the right and responsibility [...]" needs to be updated
to match the above.

> > The code of conduct asks maintainers to be involved in maintaining
> > culture as well as code.  It does mention repercussions for maintainers,
> > but it's important to apply some common sense here.  If you enable
> > people to send in terrible code, someone is going to talk to you about
> > your poor decisions.  If you're enabling people to violate the code of
> > conduct, it's a good idea to sit down and talk about ways to improve the
> > level of discourse in your subsystem.
>
> I'd also add, it's clear that these situations can be messy and a
> maintainer may not feel equipped, or have the emotional resources to
> engage at all times. So I think reasonable way for a maintainer to
> engage is to simply ask for help. At a minimum we need trusted people
> in the community that are willing to be available to help out
> contributors and fellow maintainers alike, and the TAB is tasked with
> being available to help. That was the situation with the previous
> code, this one is more explicit, but the intent is the same to have a
> concerted effort and an escalation path to help keep development
> discourse productive.

Indeed, so for 1), assistance can be provided by other members of the community.

-Maintainers are responsible for clarifying the standards of acceptable behavior
-and are expected to take appropriate and fair corrective action in response to
+All project members are encouraged to clarify the standards of
acceptable behavior
+and take appropriate and fair corrective action in response to
 any instances of unacceptable behavior.

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] New CoC and Brendan Eich

[Mauro Carvalho Chehab]

Em Wed, 10 Oct 2018 08:47:26 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:

> On Wed, Oct 10, 2018 at 12:03 AM Dan Williams <dan.j.williams@intel.com> wrote:
> > On Tue, Oct 9, 2018 at 9:53 AM Chris Mason <clm@fb.com> wrote:  
> > > On 9 Oct 2018, at 6:07, Mauro Carvalho Chehab wrote:  
> > > >> So, a company would fire maintainer for being conniving with an
> > > >> harassment
> > > >> or any other unacceptable behavior, right?!
> > > >>
> > > >> So, Developer A shouts racists words, maintainer C doesn't C the
> > > >> email.
> > > >> Developer B complains to the TAB against Developer A and Maintainer
> > > >> C.  
> > > >
> > > > No. If you read the CoC carefully, you'll see that it doesn't
> > > > have anything saying that TAB would be taking any action against
> > > > Developer A. The only person that this CoC who would be punished,
> > > > on this CoC's "enforcement" section is the maintainer.  
> 
> Indeed.
> 
> The only repercussion for violators (not considering existing legal
> frameworks) is being banned, and/or their work being rejected, but not by
> the TAB.
> 
> The CoC says it is the _maintainer_'s responsibility to take action
> w.r.t. the violator, by (translated to Linux kernel development and
> maintenance tasks):
>   1) Replying to email clarifying the standards of acceptable behavior,

On a side node, right now Brazil is voting for president. I'm part of a
Whatsapp group with about 100 members, of people that know each other,
with a CoC that explicitly forbids political posts. Every time
someone post any such message, someone replies with the CoC (usually,
not a group admin).

Does it work? No. Just yesterday, someone posted a message saying
something like:

  "Please, let's stop posting anything about politics, but most of you
   seem to be in favor of candidate A. He is not good because ..."

In short, this post caused hundreds of other posts, dozens of
CoC posts and two members left te group.

While it could be worth trying such replies, I'm afraid that
this could end by producing the opposite effect of causing or
inflaming an already existing flame war.

>   2) Removing or editing the comment and/or contribution,
>   3) Editing the patch description and/or patch body,
>   4) Rejecting the patch,

Reject a technically good patch due to that seems a poor choice.
Better to do (3) instead.

>   5) Banning the contributor from the mailing list,
> 
> 2) cannot be done on public mailing lists,
> 5) also needs external help from the mailing list administrator, so it is not
>     under direct control of the maintainer.

IMO, the possible actions against CoC violators are:

1) Any community member can reply clarifying the CoC.
2) The maintainer may edit patches that would contain CoC violations.
3) Any community member may suggest ML admins to ban the offender, if
   the behavior doesn't change.

Btw, in this case, the "community member" is anyone subscribed to the
ML. It doesn't even need to be a developer.

With regards to (2), I have to add that idiomatic expression violations
are really hard to be detected by non-native English speakers.

Recently, I wanted to post about exchanging gpg keys on an event
we'll have. As this is something that I don't commonly organize, I browsed
the Internet to check the proper term (it is "key chain party" or
"key signing party"). On my google search, I omitted one of the words on 
that phase, and discovered an idiomatic expression that could be argued
as a CoC violation.

> So "Maintainers have the right and responsibility [...]" needs to be updated
> to match the above.
> 
> > > The code of conduct asks maintainers to be involved in maintaining
> > > culture as well as code.  It does mention repercussions for maintainers,
> > > but it's important to apply some common sense here.  If you enable
> > > people to send in terrible code, someone is going to talk to you about
> > > your poor decisions.  If you're enabling people to violate the code of
> > > conduct, it's a good idea to sit down and talk about ways to improve the
> > > level of discourse in your subsystem.  
> >
> > I'd also add, it's clear that these situations can be messy and a
> > maintainer may not feel equipped, or have the emotional resources to
> > engage at all times. So I think reasonable way for a maintainer to
> > engage is to simply ask for help. At a minimum we need trusted people
> > in the community that are willing to be available to help out
> > contributors and fellow maintainers alike, and the TAB is tasked with
> > being available to help. That was the situation with the previous
> > code, this one is more explicit, but the intent is the same to have a
> > concerted effort and an escalation path to help keep development
> > discourse productive.  
> 
> Indeed, so for 1), assistance can be provided by other members of the community.
> 
> -Maintainers are responsible for clarifying the standards of acceptable behavior
> -and are expected to take appropriate and fair corrective action in response to
> +All project members are encouraged to clarify the standards of
> acceptable behavior
> +and take appropriate and fair corrective action in response to
>  any instances of unacceptable behavior.

That makes a lot more sense to me.

Thanks,
Mauro

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Josh Triplett]

On Wed, Oct 10, 2018 at 10:57:54AM -0300, Mauro Carvalho Chehab wrote:
> With regards to (2), I have to add that idiomatic expression violations
> are really hard to be detected by non-native English speakers.
> 
> Recently, I wanted to post about exchanging gpg keys on an event
> we'll have. As this is something that I don't commonly organize, I browsed
> the Internet to check the proper term (it is "key chain party" or
> "key signing party"). On my google search, I omitted one of the words on 
> that phase, and discovered an idiomatic expression that could be argued
> as a CoC violation.

Unintentionally using a phrase like that seems easy enough to handle
with a reply (on-list or off, as appropriate) saying "You might wish to
rephrase that as 'key signing party' or similar, because the phrase you
used is also an idiom with risque connotations."

To contrast that with the kind of *intentional* issue that would prompt
a less forgiving response (especially if repeated), consider if someone
submitted a script to manage such parties, named it "key-party", and
filled it with other related innuendo, to the point that there's no
doubt they were doing so intentionally. Sounds ridiculous, and yet there
are plenty of examples of that and worse in FOSS history.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Mauro Carvalho Chehab]

Em Wed, 10 Oct 2018 10:21:11 -0700
Josh Triplett <josh@joshtriplett.org> escreveu:

> On Wed, Oct 10, 2018 at 10:57:54AM -0300, Mauro Carvalho Chehab wrote:
> > With regards to (2), I have to add that idiomatic expression violations
> > are really hard to be detected by non-native English speakers.
> > 
> > Recently, I wanted to post about exchanging gpg keys on an event
> > we'll have. As this is something that I don't commonly organize, I browsed
> > the Internet to check the proper term (it is "key chain party" or
> > "key signing party"). On my google search, I omitted one of the words on 
> > that phase, and discovered an idiomatic expression that could be argued
> > as a CoC violation.  
> 
> Unintentionally using a phrase like that seems easy enough to handle
> with a reply (on-list or off, as appropriate) saying "You might wish to
> rephrase that as 'key signing party' or similar, because the phrase you
> used is also an idiom with risque connotations."
> 
> To contrast that with the kind of *intentional* issue that would prompt
> a less forgiving response (especially if repeated), consider if someone
> submitted a script to manage such parties, named it "key-party", and
> filled it with other related innuendo, to the point that there's no
> doubt they were doing so intentionally. Sounds ridiculous, and yet there
> are plenty of examples of that and worse in FOSS history.

Yes, I know that an unintentional mention would have a completely
different treatment. 

The point is that, as a maintainer, if one would write a patch with such
expression - or whatever other idiomatic sentence that would have a "hidden"
meaning inside it for non native speakers - I would probably end by applying
it without I even realize about the issue.

Thanks,
Mauro

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Josh Triplett]

On Wed, Oct 10, 2018 at 03:28:11PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Oct 2018 10:21:11 -0700
> Josh Triplett <josh@joshtriplett.org> escreveu:
> 
> > On Wed, Oct 10, 2018 at 10:57:54AM -0300, Mauro Carvalho Chehab wrote:
> > > With regards to (2), I have to add that idiomatic expression violations
> > > are really hard to be detected by non-native English speakers.
> > > 
> > > Recently, I wanted to post about exchanging gpg keys on an event
> > > we'll have. As this is something that I don't commonly organize, I browsed
> > > the Internet to check the proper term (it is "key chain party" or
> > > "key signing party"). On my google search, I omitted one of the words on 
> > > that phase, and discovered an idiomatic expression that could be argued
> > > as a CoC violation.  
> > 
> > Unintentionally using a phrase like that seems easy enough to handle
> > with a reply (on-list or off, as appropriate) saying "You might wish to
> > rephrase that as 'key signing party' or similar, because the phrase you
> > used is also an idiom with risque connotations."
> > 
> > To contrast that with the kind of *intentional* issue that would prompt
> > a less forgiving response (especially if repeated), consider if someone
> > submitted a script to manage such parties, named it "key-party", and
> > filled it with other related innuendo, to the point that there's no
> > doubt they were doing so intentionally. Sounds ridiculous, and yet there
> > are plenty of examples of that and worse in FOSS history.
> 
> Yes, I know that an unintentional mention would have a completely
> different treatment. 
> 
> The point is that, as a maintainer, if one would write a patch with such
> expression - or whatever other idiomatic sentence that would have a "hidden"
> meaning inside it for non native speakers - I would probably end by applying
> it without I even realize about the issue.

And the same notion of intent applies there, too. Mistakes happen, and
when they really are mistakes, that's not a critical issue. I'd assume
you'd also quickly apply a patch someone sent you to fix it. (By
contrast with someone who, for instance, might go off on a rant if asked
to do so.)

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Mauro Carvalho Chehab]

Em Wed, 10 Oct 2018 12:56:34 -0700
Josh Triplett <josh@joshtriplett.org> escreveu:

> On Wed, Oct 10, 2018 at 03:28:11PM -0300, Mauro Carvalho Chehab wrote:
> > Em Wed, 10 Oct 2018 10:21:11 -0700
> > Josh Triplett <josh@joshtriplett.org> escreveu:
> > 
> > > On Wed, Oct 10, 2018 at 10:57:54AM -0300, Mauro Carvalho Chehab wrote:
> > > > With regards to (2), I have to add that idiomatic expression violations
> > > > are really hard to be detected by non-native English speakers.
> > > > 
> > > > Recently, I wanted to post about exchanging gpg keys on an event
> > > > we'll have. As this is something that I don't commonly organize, I browsed
> > > > the Internet to check the proper term (it is "key chain party" or
> > > > "key signing party"). On my google search, I omitted one of the words on 
> > > > that phase, and discovered an idiomatic expression that could be argued
> > > > as a CoC violation.  
> > > 
> > > Unintentionally using a phrase like that seems easy enough to handle
> > > with a reply (on-list or off, as appropriate) saying "You might wish to
> > > rephrase that as 'key signing party' or similar, because the phrase you
> > > used is also an idiom with risque connotations."
> > > 
> > > To contrast that with the kind of *intentional* issue that would prompt
> > > a less forgiving response (especially if repeated), consider if someone
> > > submitted a script to manage such parties, named it "key-party", and
> > > filled it with other related innuendo, to the point that there's no
> > > doubt they were doing so intentionally. Sounds ridiculous, and yet there
> > > are plenty of examples of that and worse in FOSS history.
> > 
> > Yes, I know that an unintentional mention would have a completely
> > different treatment. 
> > 
> > The point is that, as a maintainer, if one would write a patch with such
> > expression - or whatever other idiomatic sentence that would have a "hidden"
> > meaning inside it for non native speakers - I would probably end by applying
> > it without I even realize about the issue.
> 
> And the same notion of intent applies there, too. Mistakes happen, and
> when they really are mistakes, that's not a critical issue. I'd assume
> you'd also quickly apply a patch someone sent you to fix it. (By
> contrast with someone who, for instance, might go off on a rant if asked
> to do so.)

Surely, but, except if I receive such fix soon enough, I probably won't
be rebasing the tree (as rebasing a master tree usually causes damage
to a lot of people).

So, the bad wording will stay forever at the git history - and will
probably be backported to -stable too (if stable people won't notice).

Thanks,
Mauro

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Josh Triplett]

On Wed, Oct 10, 2018 at 05:12:27PM -0300, Mauro Carvalho Chehab wrote:
> Em Wed, 10 Oct 2018 12:56:34 -0700
> Josh Triplett <josh@joshtriplett.org> escreveu:
> 
> > On Wed, Oct 10, 2018 at 03:28:11PM -0300, Mauro Carvalho Chehab wrote:
> > > Em Wed, 10 Oct 2018 10:21:11 -0700
> > > Josh Triplett <josh@joshtriplett.org> escreveu:
> > > 
> > > > On Wed, Oct 10, 2018 at 10:57:54AM -0300, Mauro Carvalho Chehab wrote:
> > > > > With regards to (2), I have to add that idiomatic expression violations
> > > > > are really hard to be detected by non-native English speakers.
> > > > > 
> > > > > Recently, I wanted to post about exchanging gpg keys on an event
> > > > > we'll have. As this is something that I don't commonly organize, I browsed
> > > > > the Internet to check the proper term (it is "key chain party" or
> > > > > "key signing party"). On my google search, I omitted one of the words on 
> > > > > that phase, and discovered an idiomatic expression that could be argued
> > > > > as a CoC violation.  
> > > > 
> > > > Unintentionally using a phrase like that seems easy enough to handle
> > > > with a reply (on-list or off, as appropriate) saying "You might wish to
> > > > rephrase that as 'key signing party' or similar, because the phrase you
> > > > used is also an idiom with risque connotations."
> > > > 
> > > > To contrast that with the kind of *intentional* issue that would prompt
> > > > a less forgiving response (especially if repeated), consider if someone
> > > > submitted a script to manage such parties, named it "key-party", and
> > > > filled it with other related innuendo, to the point that there's no
> > > > doubt they were doing so intentionally. Sounds ridiculous, and yet there
> > > > are plenty of examples of that and worse in FOSS history.
> > > 
> > > Yes, I know that an unintentional mention would have a completely
> > > different treatment. 
> > > 
> > > The point is that, as a maintainer, if one would write a patch with such
> > > expression - or whatever other idiomatic sentence that would have a "hidden"
> > > meaning inside it for non native speakers - I would probably end by applying
> > > it without I even realize about the issue.
> > 
> > And the same notion of intent applies there, too. Mistakes happen, and
> > when they really are mistakes, that's not a critical issue. I'd assume
> > you'd also quickly apply a patch someone sent you to fix it. (By
> > contrast with someone who, for instance, might go off on a rant if asked
> > to do so.)
> 
> Surely, but, except if I receive such fix soon enough, I probably won't
> be rebasing the tree (as rebasing a master tree usually causes damage
> to a lot of people).
> 
> So, the bad wording will stay forever at the git history - and will
> probably be backported to -stable too (if stable people won't notice).

It happens. It's not the end of the world. I wouldn't expect to see a
git tree people work from rebased to remove something as minor as that,
even if it *hadn't* been propagated yet.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Laurent Pinchart]

Hi Jon,

On Thursday, 4 October 2018 22:05:53 EEST jonsmirl@gmail.com wrote:
> On Thu, Oct 4, 2018 at 2:32 PM Laurent Pinchart wrote:
> > On Thursday, 4 October 2018 19:23:33 EEST jonsmirl@gmail.com wrote:
> >> I would highly recommend getting the new CoC reviewed and approved by
> >> some of the very smart lawyers that help out the Linux community.  I
> >> would also recommend discussing the Brendan Eich situation at Ksummit.
> >> A situation like this needs to be planned for since an improper
> >> response will make things much worse leading to legal challenges.
> >> 
> >> Some random articles to refresh everyone's memory...
> >> https://www.telegraph.co.uk/finance/newsbysector/mediatechnologyandtelec
> >> oms/digital-media/10743456/Mozilla-chief-Brendan-Eich-steps-down-over-
> >> gay-marriage-row.html
> >> https://www.theguardian.com/commentisfree/2014/apr/07/brendan-eich-has-t
> >> he-right-to-fight-gay-rights-but-not-to-be-mozillas-ceo
> >> https://www.bbc.com/news/technology-26868536
> >> https://www.telegraph.co.uk/technology/technology-topics/10745283/Brenda
> >> n-Eich-is-a-homophobe-Im-a-lesbian-and-neither-of-us-deserves-to-lose-
> >> our-jobs.h tml
> > 
> > We're facing a textbook case that has a probability of generating heated
> > discussions no lower than 100%. I remember having a pretty strong opinion
> > on the topic when it came under public scrutiny (and while I generally
> > don't mind discussing it, I won't disclose that opinion here as that's
> > entirely irrelevant). The more interesting part was that waiting for the
> > debate to cool down gave me time to think, and realize that what is often
> > perceived as a black-and-white situation most often turns out to be more
> > complex than initially perceived.
> > 
> > One point that I would like to explore is thus how we can take the time
> > needed to solve such matters when the mob is waiting outside of the
> > courtroom with tar and feathers. I don't want to discuss here what our
> > response to such a case should be, but the process that we should follow
> > to come up with a response. It is of paramount importance in my opinion
> > for the body tasked with handling those issues to follow a process that
> > ensures it will be able to keep a cool head and have enough time
> > available to think the response carefully.
> 
> What is going to happen when someone gets fired after being accused of
> violating the CoC and they lose $20M in options? INAL but it appears
> to me that the CoC has created lawsuit exposure for all of the
> maintainers. This CoC really needs to be vetted by the kernel legal
> team.

You're not the only one raising concerns in this area. I believe it would make 
sense for the Linux Foundation, in their position of a legal body closely 
related to the community, or for the TAB as a deputy of the Linux Foundation, 
to consult the community at large and get legal advice. Even if the usual 
advice is for individual having legal concerns to consult their own lawyer, I 
don't think this could scale in this case. We need a forum where our questions 
and concerns can be expressed and gathered, and someone to fund legal counsel.

I do have personal opinions on this topics, and as I'm not a lawyer, I'll 
refrain from commenting on it further in this mail thread.

The community aspects of code of conduct enforcement that I raised in my 
previous e-mail still interest me, and those I would like to keep discussing.

> > Another point that I believe is important is the issue of representation.
> > The code of conduct mentions both "project" and "community". While
> > neither are defined, the term project is quite straightforward, but the
> > term community not really so. The code of conduct gives a mandate to the
> > TAB to handle enforcement in the name of the project (I don't want to
> > focus here on whether the TAB is the right instance to handle those
> > issues, this will likely be discusses separately and possibly be changed,
> > I will just use TAB here to refer to the code of conduct enforcement body
> > for simplicity), and I would argue that the mandate extends to
> > representing the community as a whole. When the TAB will have to decide
> > on a case that will generate a wide diversity of opinions, what kind of
> > process can we put in place to ensure that all community members will
> > feel represented (and thus heard) ? To put it differently, how can we
> > make sure that the community members who don't fully agree with the final
> > decision will agree to disagree and still feel part of the community ?

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Al Viro]

On Thu, Oct 04, 2018 at 09:33:15PM +0300, Laurent Pinchart wrote:

> Another point that I believe is important is the issue of representation. The 
> code of conduct mentions both "project" and "community". While neither are 
> defined, the term project is quite straightforward, but the term community not 
> really so. The code of conduct gives a mandate to the TAB to handle 
> enforcement in the name of the project (I don't want to focus here on whether 
> the TAB is the right instance to handle those issues, this will likely be 
> discusses separately and possibly be changed, I will just use TAB here to 
> refer to the code of conduct enforcement body for simplicity), and I would 
> argue that the mandate extends to representing the community as a whole. When 
> the TAB will have to decide on a case that will generate a wide diversity of 
> opinions, what kind of process can we put in place to ensure that all 
> community members will feel represented (and thus heard) ? To put it 
> differently, how can we make sure that the community members who don't fully 
> agree with the final decision will agree to disagree and still feel part of 
> the community ?

Community, shmonunity...  Here's a scenario:

	* contributor Alice gets banned from contributing, for whatever reason
	* Alice finds a roothole and posts a technically valid fix
	* maintainer Bob sees the posting, verifies that the bug is real, that
the fix is correct and that the source of that patch is banned.

What should Bob do?  Discuss.  And piss on Mozilla, Eich, options, etc. - they
are irrelevant.  The above isn't, and it's going to happen sooner or later if
the bans are not going to stay pure theory.

Note that "commit the fix without mentioning Alice" isn't a viable option.  And
"design a different fix and commit that without mentioning Alice" isn't any
better, especially if the same thing keeps repeating.  And "send Alice to Place
de la Revolution to make sure that this stops" is not an option either - TAB
isn't CSP and the guillotine got retired, anyway.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Jonathan Corbet]

On Thu, 4 Oct 2018 21:39:57 +0100
Al Viro <viro@ZenIV.linux.org.uk> wrote:

> 	* contributor Alice gets banned from contributing, for whatever reason
> 	* Alice finds a roothole and posts a technically valid fix
> 	* maintainer Bob sees the posting, verifies that the bug is real, that
> the fix is correct and that the source of that patch is banned.

So, while remedies under the CoC are yet to be determined in any sort of
detail, I don't believe I have heard anybody talk about banning the
acceptance of patches from anybody.  Speaking only for myself, I have a
hard time seeing that happening in the absence of other sorts of concerns
(the event where a would-be contributor started sending under a sock
puppet name because nobody would consider his work anymore comes to mind).

What *is* common under CoCs in various projects is banning from specific
fora, such as this mailing list.  But that is a different thing and
doesn't bring about the scenario described above.

jon

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Thomas Gleixner]

On Thu, 4 Oct 2018, Jonathan Corbet wrote:
> On Thu, 4 Oct 2018 21:39:57 +0100
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
> 
> > 	* contributor Alice gets banned from contributing, for whatever reason
> > 	* Alice finds a roothole and posts a technically valid fix
> > 	* maintainer Bob sees the posting, verifies that the bug is real, that
> > the fix is correct and that the source of that patch is banned.
> 
> So, while remedies under the CoC are yet to be determined in any sort of
> detail, I don't believe I have heard anybody talk about banning the
> acceptance of patches from anybody.  Speaking only for myself, I have a
> hard time seeing that happening in the absence of other sorts of concerns
> (the event where a would-be contributor started sending under a sock
> puppet name because nobody would consider his work anymore comes to mind).
> 
> What *is* common under CoCs in various projects is banning from specific
> fora, such as this mailing list.  But that is a different thing and
> doesn't bring about the scenario described above.

It does. Alice is banned from the mailing list, but still posts the
roothole fix to LKML and Cc's the maintainer according to the rules. LKML
drops the post, but the maintainer still gets it. Now what is he supposed
to do? Ignore it, because he forgot to add Alice to his /dev/null filter?

Thanks,

	tglx

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Jonathan Corbet]

On Thu, 4 Oct 2018 23:27:33 +0200 (CEST)
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, 4 Oct 2018, Jonathan Corbet wrote:
> > On Thu, 4 Oct 2018 21:39:57 +0100
> > Al Viro <viro@ZenIV.linux.org.uk> wrote:
> >   
> > > 	* contributor Alice gets banned from contributing, for whatever reason
> > > 	* Alice finds a roothole and posts a technically valid fix
> > > 	* maintainer Bob sees the posting, verifies that the bug is real, that
> > > the fix is correct and that the source of that patch is banned.  
> > 
> > So, while remedies under the CoC are yet to be determined in any sort of
> > detail, I don't believe I have heard anybody talk about banning the
> > acceptance of patches from anybody.  Speaking only for myself, I have a
> > hard time seeing that happening in the absence of other sorts of concerns
> > (the event where a would-be contributor started sending under a sock
> > puppet name because nobody would consider his work anymore comes to mind).
> > 
> > What *is* common under CoCs in various projects is banning from specific
> > fora, such as this mailing list.  But that is a different thing and
> > doesn't bring about the scenario described above.  
> 
> It does. Alice is banned from the mailing list, but still posts the
> roothole fix to LKML and Cc's the maintainer according to the rules. LKML
> drops the post, but the maintainer still gets it. Now what is he supposed
> to do? Ignore it, because he forgot to add Alice to his /dev/null filter?

Again, I don't think anybody is envisioning telling maintainers that they
cannot accept patches from a given individual over conduct issues, and
I've certainly heard no talk of trying to mandate email filters.  I don't
understand who you think might be telling the maintainer not to apply such
a patch..?

One fairly common approach to conduct problems is to have the person
involved work through somebody who is willing to deal with them for a
while.  This sounds kind of like that sort of scenario.

The community needs to figure out how it wants to handle the disciplinary
side of things should we ever have a case where trying to talk to the
person involved isn't enough.  I suppose that *could* involve a blanket
refusal to accept that person's patches under any circumstances, but I
don't think I've ever seen that in the past except in cases where there
were issues with the patches themselves.  I would be surprised to see that
change.

In any case, this scenario is one thing to keep in mind as we work all
this out.

jon

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Theodore Y. Ts'o]

On Thu, Oct 04, 2018 at 04:04:14PM -0600, Jonathan Corbet wrote:
> Again, I don't think anybody is envisioning telling maintainers that they
> cannot accept patches from a given individual over conduct issues, and
> I've certainly heard no talk of trying to mandate email filters.  I don't
> understand who you think might be telling the maintainer not to apply such
> a patch..?
> 
> One fairly common approach to conduct problems is to have the person
> involved work through somebody who is willing to deal with them for a
> while.  This sounds kind of like that sort of scenario.
> 
> The community needs to figure out how it wants to handle the disciplinary
> side of things should we ever have a case where trying to talk to the
> person involved isn't enough.  I suppose that *could* involve a blanket
> refusal to accept that person's patches under any circumstances, but I
> don't think I've ever seen that in the past except in cases where there
> were issues with the patches themselves.  I would be surprised to see that
> change.

It might be helpful to consider that cutting off a contributor has
happened already, when the netfilter core team, as maintainers,
collectively made a decision to not accept any patches from a
copyright troll.  Neither Linus, nor the TAB, nor the LF were involved
in that decision.  That maintainer team decided to do that on their
own.  The sky didn't fall down.  No one sued the netfilter core team
for millions and millions of dollars.  In fact, it seems to me that
the community as a whole breathed a sign of relief, and we all moved
on.

I don't know what the netfilter core team would decide to do if the
copyright troll submitted a security patch.  It wouldn't be up to me,
but if they asked them for my advice, I'd tell them they received a
bug report, and they should fix it.  In this particular case, I'd
advise them to find a different way to fix the bug, and rewrite it in
a clean room fashion, because, you know --- copyright troll --- but I
don't think it's worth it to figure out how to handle every single
eventuality ahead of time.

Like most personnel matters, it's going to be very case specific, but
it should be noted that the decision to cut off contributions from the
copyright troll happened after much provocation.  It was *not*
something that was done casually, and I'm sure there was a lot careful
thought, and probably emtional anguish, involved.

People seem to be assuming that this kind of very extreme decision
happen casually and easily, but it's happened only *once* in over a
quarter century of Linux kernel development.  And it only got done
after **substantial** damage had already been inflicted, and it was
the only way to protect the community.

	  	    	   	       	      - Ted

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Tim.Bird]

> -----Original Message-----
> From: Thomas Gleixner
> On Thu, 4 Oct 2018, Jonathan Corbet wrote:
> > On Thu, 4 Oct 2018 21:39:57 +0100
> > Al Viro <viro@ZenIV.linux.org.uk> wrote:
> >
> > > 	* contributor Alice gets banned from contributing, for whatever
> reason
> > > 	* Alice finds a roothole and posts a technically valid fix
> > > 	* maintainer Bob sees the posting, verifies that the bug is real, that
> > > the fix is correct and that the source of that patch is banned.
> >
> > So, while remedies under the CoC are yet to be determined in any sort of
> > detail, I don't believe I have heard anybody talk about banning the
> > acceptance of patches from anybody.  Speaking only for myself, I have a
> > hard time seeing that happening in the absence of other sorts of concerns
> > (the event where a would-be contributor started sending under a sock
> > puppet name because nobody would consider his work anymore comes to
> mind).
> >
> > What *is* common under CoCs in various projects is banning from specific
> > fora, such as this mailing list.  But that is a different thing and
> > doesn't bring about the scenario described above.
> 
> It does. Alice is banned from the mailing list, but still posts the
> roothole fix to LKML and Cc's the maintainer according to the rules. LKML
> drops the post, but the maintainer still gets it. Now what is he supposed
> to do? Ignore it, because he forgot to add Alice to his /dev/null filter?

In general I don't think it's very productive to debate hypothetical
situations.  This one seems to me to be a low-probability event.
However, it seems like the Maintainer can do whatever they want, and
the CoC will have improved the situation.  If the submission is laden
with curse-words and abuse, then LKML and the wider community
has been spared from the negative communication, and the Maintainer
can clean up any language in the commit message or the code that they
want.  Maintainers do this kind of thing all the time.

If the Maintainer themselves find the communication so abusive
that they don't want to consider the code, they can tell Alice to
redo the patch, or in the extreme case add her to the /dev/null filter.

When the patch hits upstream, no one should care who it came from.
The CoC is not about creating a witch hunt against individuals, or about
ignoring valid code.  It is about improving behavior during the contribution 
process.
 -- Tim

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Christoph Hellwig]

On Thu, Oct 04, 2018 at 10:05:39PM +0000, Tim.Bird@sony.com wrote:
> In general I don't think it's very productive to debate hypothetical
> situations.

Given certain very smart but abusive persons in the security community
it is everything but hypothetical.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Geert Uytterhoeven]

On Thu, Oct 4, 2018 at 10:56 PM Jonathan Corbet <corbet@lwn.net> wrote:
> On Thu, 4 Oct 2018 21:39:57 +0100
> Al Viro <viro@ZenIV.linux.org.uk> wrote:
> >       * contributor Alice gets banned from contributing, for whatever reason
> >       * Alice finds a roothole and posts a technically valid fix
> >       * maintainer Bob sees the posting, verifies that the bug is real, that
> > the fix is correct and that the source of that patch is banned.
>
> So, while remedies under the CoC are yet to be determined in any sort of
> detail, I don't believe I have heard anybody talk about banning the
> acceptance of patches from anybody.  Speaking only for myself, I have a
> hard time seeing that happening in the absence of other sorts of concerns

"Maintainers have the right and responsibility [...] to ban temporarily or
 permanently any contributor".

> (the event where a would-be contributor started sending under a sock
> puppet name because nobody would consider his work anymore comes to mind).

That has indeed already happened.

> What *is* common under CoCs in various projects is banning from specific
> fora, such as this mailing list.  But that is a different thing and
> doesn't bring about the scenario described above.

"Maintainers have the right and responsibility to remove [...] commits".
Enjoy the append-only nature of non-rebasing git ;-)

BTW, should we start sending out patches to remedy parts in the CoC that
are not appropriate/suited/wanted for the Linux kernel project?
So far I have seen many suggestions to improve it, but no formal patches
for Documentation/process/code-of-conduct.rst.
I'm afraid it is already causing a chilling effect...

Or is that to be done after a group discussion in e.g. Edinburgh?
Which may bring us _after_ the release of v4.19...

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] New CoC and Brendan Eich

[Josh Triplett]

On Fri, Oct 05, 2018 at 09:12:40AM +0200, Geert Uytterhoeven wrote:
> BTW, should we start sending out patches to remedy parts in the CoC that
> are not appropriate/suited/wanted for the Linux kernel project?
> So far I have seen many suggestions to improve it, but no formal patches
> for Documentation/process/code-of-conduct.rst.
> I'm afraid it is already causing a chilling effect...

There have also been very few patches to the top-level COPYING, modulo
some recent SPDX-inspired reordering. The right place for patches is
upstream; the right place for clarifications on application would be in
a separate Documentation/process/code-of-conduct-process.rst or similar.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Jani Nikula]

On Fri, 05 Oct 2018, Josh Triplett <josh@joshtriplett.org> wrote:
> On Fri, Oct 05, 2018 at 09:12:40AM +0200, Geert Uytterhoeven wrote:
>> BTW, should we start sending out patches to remedy parts in the CoC that
>> are not appropriate/suited/wanted for the Linux kernel project?
>> So far I have seen many suggestions to improve it, but no formal patches
>> for Documentation/process/code-of-conduct.rst.
>> I'm afraid it is already causing a chilling effect...
>
> There have also been very few patches to the top-level COPYING, modulo
> some recent SPDX-inspired reordering. The right place for patches is
> upstream; the right place for clarifications on application would be in
> a separate Documentation/process/code-of-conduct-process.rst or similar.

Agreed, as noted before.

Also, given the way the new CoC was introduced, I think the discussion
on modifying code-of-conduct.rst locally is mostly futile until we hear
some direction straight from the horse's mouth. However, nothing
prevents anyone from proposing improvements directly to Contributor
Covenant upstream.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Laurent Pinchart]

Hi Jani,

On Friday, 5 October 2018 12:20:49 EEST Jani Nikula wrote:
> On Fri, 05 Oct 2018, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Fri, Oct 05, 2018 at 09:12:40AM +0200, Geert Uytterhoeven wrote:
> >> BTW, should we start sending out patches to remedy parts in the CoC that
> >> are not appropriate/suited/wanted for the Linux kernel project?
> >> So far I have seen many suggestions to improve it, but no formal patches
> >> for Documentation/process/code-of-conduct.rst.
> >> I'm afraid it is already causing a chilling effect...
> > 
> > There have also been very few patches to the top-level COPYING, modulo
> > some recent SPDX-inspired reordering. The right place for patches is
> > upstream; the right place for clarifications on application would be in
> > a separate Documentation/process/code-of-conduct-process.rst or similar.
> 
> Agreed, as noted before.

I'm afraid I disagree in this particular instance. We first need to evaluate 
a) whether we have picked the right upstream, and b) whether the upstream we 
base our code of conduct on has the same goals as yours. There are valid 
reasons for software to fork, I don't see why there could be valid reasons for 
codes of conduct to fork.

Note that I'm not advocating forking or not forking, I'm saying that the 
discussion shouldn't be avoided. Several concerns have been raised that the 
wording of the code of conduct, not its essence, doesn't apply very well to 
the community due to technical differences in the management of the project, 
these need to be addressed. Other concerns have been raised that touch to the 
essence of the code of conduct, and I believe these need to be discussed. Only 
when the necessary discussions will have taken place, and a decision on how to 
address the concerns taken, should we then decide whether to fork or 
contribute upstream.

> Also, given the way the new CoC was introduced, I think the discussion
> on modifying code-of-conduct.rst locally is mostly futile until we hear
> some direction straight from the horse's mouth.

I agree that we are lacking an official story. However, I share concerns about 
how the new code of conduct has been imposed (by who ?) without consulting the 
community, and I think we need a better process to decide *together* what we 
want to do *together*. In that regard discussing how we want to address 
community management in general is a public issue that needs to be discussed 
among us. I still believe that democracy is better than dictatorship, 
including when it comes to deciding codes of conduct.

> However, nothing prevents anyone from proposing improvements directly to
> Contributor Covenant upstream.

Again I believe this should be discussed inside our community first, and then 
possibly proposed upstream when we reach an agreement on what we want to do. 
Otherwise you'll have completely random, often half-though, proposals 
submitted upstream and nothing will happen. Let's not use this as an argument 
to muzzle all voices from our community members.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Joe Perches]

On Fri, 2018-10-05 at 12:57 +0300, Laurent Pinchart wrote:
> Only 
> when the necessary discussions will have taken place, and a decision on how to 
> address the concerns taken, should we then decide whether to fork or 
> contribute upstream.

It's not necessarily am either/or, nor is it
up to this downstream to decide for upstream.

Upstream may or may not want to change to what
this community decides is best for itself.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Laurent Pinchart]

Hi Joe,

On Friday, 5 October 2018 13:45:01 EEST Joe Perches wrote:
> On Fri, 2018-10-05 at 12:57 +0300, Laurent Pinchart wrote:
> > Only when the necessary discussions will have taken place, and a decision
> > on how to address the concerns taken, should we then decide whether to
> > fork or contribute upstream.
> 
> It's not necessarily am either/or, nor is it
> up to this downstream to decide for upstream.
> 
> Upstream may or may not want to change to what
> this community decides is best for itself.

We agree on this, I should have been more precised and said that we could then 
device to submit proposals upstream if we deem them to be applicable, but 
there's certainly no guarantee that upstream would accept them.

I also want to note that, while I believe our community should decide what is 
best for itself, there have been lots of work done on codes of conducts in the 
past, and it would seem equally erroneous to me to ignore that and think we 
can do better by ourselves with very little experience in the area. Discussing 
proposed changes with upstream has the potential to bring interesting 
feedback, even if upstream isn't interested in accepting the change proposals.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Jani Nikula]

On Fri, 05 Oct 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> There are valid reasons for software to fork, I don't see why there
> could be valid reasons for codes of conduct to fork.

Perhaps you're missing a "not" in there?

Some of the valid reasons to *not* fork codes of conduct are similar to
why you shouldn't roll your own licenses. First, people don't want to
keep reading and interpreting different texts for different projects,
wondering what this means for them. Just read the familiar label and you
know what's in the box. Second, as a community you can share the
experiences and best practices with other projects using the same text.

I'm not saying we should stick to Contributor Covenant at all cost, I'm
saying pick a suitable tried and tested code of conduct, and stick with
it.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Laurent Pinchart]

Hi Jani,

On Friday, 5 October 2018 15:59:23 EEST Jani Nikula wrote:
> On Fri, 05 Oct 2018, Laurent Pinchart wrote:
> > There are valid reasons for software to fork, I don't see why there
> > could be valid reasons for codes of conduct to fork.
> 
> Perhaps you're missing a "not" in there?

Yes, sorry, proof-reading your own e-mails work equally as well as reviewing 
your own patches :-)

> Some of the valid reasons to *not* fork codes of conduct are similar to
> why you shouldn't roll your own licenses. First, people don't want to
> keep reading and interpreting different texts for different projects,
> wondering what this means for them. Just read the familiar label and you
> know what's in the box. Second, as a community you can share the
> experiences and best practices with other projects using the same text.

No disagreement there, but that's not limited to codes of conduct or licenses. 
Forking generates pain in general, but sometimes still makes sense when 
carefully done.

> I'm not saying we should stick to Contributor Covenant at all cost, I'm
> saying pick a suitable tried and tested code of conduct, and stick with
> it.

That would have my preference as well, provided such a code of conduct exists 
(and we would add a FAQ to clarify grey areas regardless of which standard 
code of conduct we would select).

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] New CoC and Brendan Eich

[James Bottomley]

On Fri, 2018-10-05 at 15:59 +0300, Jani Nikula wrote:
> On Fri, 05 Oct 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.
> com> wrote:
> > There are valid reasons for software to fork, I don't see why there
> > could be valid reasons for codes of conduct to fork.
> 
> Perhaps you're missing a "not" in there?
> 
> Some of the valid reasons to *not* fork codes of conduct are similar
> to why you shouldn't roll your own licenses. First, people don't want
> to keep reading and interpreting different texts for different
> projects, wondering what this means for them. Just read the familiar
> label and you know what's in the box. Second, as a community you can
> share the experiences and best practices with other projects using
> the same text.
> 
> I'm not saying we should stick to Contributor Covenant at all cost,
> I'm saying pick a suitable tried and tested code of conduct, and
> stick with it.

As I said on another thread: Zephyr jut adopted the contributor
covenant but stripped all the enforcement clauses:

https://github.com/zephyrproject-rtos/zephyr/pull/10356

So I think we could modify it to suit our own community as well.

I don't think when it comes to CoCs one size fits all so I can see us
making local patches that aren't upstream because upstream seems to be
concentrating more on the github than mailing list communities.

James

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Josh Triplett]

On Fri, Oct 05, 2018 at 08:17:14AM -0700, James Bottomley wrote:
> On Fri, 2018-10-05 at 15:59 +0300, Jani Nikula wrote:
> > On Fri, 05 Oct 2018, Laurent Pinchart <laurent.pinchart@ideasonboard.
> > com> wrote:
> > > There are valid reasons for software to fork, I don't see why there
> > > could be valid reasons for codes of conduct to fork.
> > 
> > Perhaps you're missing a "not" in there?
> > 
> > Some of the valid reasons to *not* fork codes of conduct are similar
> > to why you shouldn't roll your own licenses. First, people don't want
> > to keep reading and interpreting different texts for different
> > projects, wondering what this means for them. Just read the familiar
> > label and you know what's in the box. Second, as a community you can
> > share the experiences and best practices with other projects using
> > the same text.
> > 
> > I'm not saying we should stick to Contributor Covenant at all cost,
> > I'm saying pick a suitable tried and tested code of conduct, and
> > stick with it.
> 
> As I said on another thread: Zephyr jut adopted the contributor
> covenant but stripped all the enforcement clauses:
> 
> https://github.com/zephyrproject-rtos/zephyr/pull/10356

No, they didn't. Someone proposed it, it has not been merged.

> I don't think when it comes to CoCs one size fits all so I can see us
> making local patches that aren't upstream because upstream seems to be
> concentrating more on the github than mailing list communities.

I strongly suspect that upstream would welcome patches that clarify how
it applies to mailing-list-based communities.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[James Bottomley]

On Fri, 2018-10-05 at 11:28 -0700, Josh Triplett wrote:
> On Fri, Oct 05, 2018 at 08:17:14AM -0700, James Bottomley wrote:
> > On Fri, 2018-10-05 at 15:59 +0300, Jani Nikula wrote:
> > > On Fri, 05 Oct 2018, Laurent Pinchart
> > > <laurent.pinchart@ideasonboard.com> wrote:
> > > > There are valid reasons for software to fork, I don't see why
> > > > there could be valid reasons for codes of conduct to fork.
> > > 
> > > Perhaps you're missing a "not" in there?
> > > 
> > > Some of the valid reasons to *not* fork codes of conduct are
> > > similar to why you shouldn't roll your own licenses. First,
> > > people don't want to keep reading and interpreting different
> > > texts for different projects, wondering what this means for them.
> > > Just read the familiar label and you know what's in the box.
> > > Second, as a community you can share the experiences and best
> > > practices with other projects using the same text.
> > > 
> > > I'm not saying we should stick to Contributor Covenant at all
> > > cost, I'm saying pick a suitable tried and tested code of
> > > conduct, and stick with it.
> > 
> > As I said on another thread: Zephyr jut adopted the contributor
> > covenant but stripped all the enforcement clauses:
> > 
> > https://github.com/zephyrproject-rtos/zephyr/pull/10356
> 
> No, they didn't. Someone proposed it, it has not been merged.

"someone" who happens to be the Zephyr community manager, yes.

> > I don't think when it comes to CoCs one size fits all so I can see
> > us making local patches that aren't upstream because upstream seems
> > to be concentrating more on the github than mailing list
> > communities.
> 
> I strongly suspect that upstream would welcome patches that clarify
> how it applies to mailing-list-based communities.

So that would argue the way to proceed is to make it work for us first
and then see if upstream wants it.

James

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Josh Triplett]

On Thu, Oct 04, 2018 at 09:39:57PM +0100, Al Viro wrote:
> On Thu, Oct 04, 2018 at 09:33:15PM +0300, Laurent Pinchart wrote:
> 	* contributor Alice gets banned from contributing, for whatever reason
> 	* Alice finds a roothole and posts a technically valid fix
> 	* maintainer Bob sees the posting, verifies that the bug is real, that
> the fix is correct and that the source of that patch is banned.
> 
> What should Bob do?  Discuss.

(Presumably they "post" that to some place that isn't part of the Linux
kernel community, such as a security research group. Also, let's leave
aside that the above scenario would come after some non-trivial
likely-private discussion with them, in which they refused to meet the
standards expected of the kernel community; standing reminder that bans
aren't typically step 1 of a process.)

What do you do when a patch is posted that fixes a real bug but doesn't
meet patch requirements in other ways? I've seen developers fix up such
patches themselves, with varying degrees of effort required; I've also
seen developers reject such patches with a request to fix, and other
people coming along to clean up the same fix. See also grsecurity
patches.

What do you do if some random downstream kernel branch (e.g. a distro or
vendor kernel) has a useful patch, and you don't expect the person who
wrote it to contribute it upstream, but it still has a signoff and
you're willing to do the work yourself?

In general: verify that the patch works, still has the right license,
has a signoff, etc. (If someone is being particularly vindictive and
putting irrelevant things in commit messages, etc, then those can easily
be removed; OTOH, if someone has a patch and doesn't provide a signoff,
that'd be an orthogonal problem that isn't specific to this situation,
as you couldn't assume you could incorporate the patch.) Then apply the
patch as a fix, and include it in their next pull request upstream.

Roughly speaking, I'd treat that situation the same as "what if someone
has a patch that's otherwise entirely correct, and a now non-functional
email address that bounces, with no way to reach them", and proceed
accordingly.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Geert Uytterhoeven]

On Thu, Oct 4, 2018 at 10:58 PM Josh Triplett <josh@joshtriplett.org> wrote:
> On Thu, Oct 04, 2018 at 09:39:57PM +0100, Al Viro wrote:
> > On Thu, Oct 04, 2018 at 09:33:15PM +0300, Laurent Pinchart wrote:
> >       * contributor Alice gets banned from contributing, for whatever reason
> >       * Alice finds a roothole and posts a technically valid fix
> >       * maintainer Bob sees the posting, verifies that the bug is real, that
> > the fix is correct and that the source of that patch is banned.
> >
> > What should Bob do?  Discuss.
>
> (Presumably they "post" that to some place that isn't part of the Linux
> kernel community, such as a security research group. Also, let's leave
> aside that the above scenario would come after some non-trivial
> likely-private discussion with them, in which they refused to meet the
> standards expected of the kernel community; standing reminder that bans
> aren't typically step 1 of a process.)
>
> What do you do when a patch is posted that fixes a real bug but doesn't
> meet patch requirements in other ways? I've seen developers fix up such
> patches themselves, with varying degrees of effort required; I've also
> seen developers reject such patches with a request to fix, and other
> people coming along to clean up the same fix. See also grsecurity
> patches.
>
> What do you do if some random downstream kernel branch (e.g. a distro or
> vendor kernel) has a useful patch, and you don't expect the person who
> wrote it to contribute it upstream, but it still has a signoff and
> you're willing to do the work yourself?
>
> In general: verify that the patch works, still has the right license,
> has a signoff, etc. (If someone is being particularly vindictive and
> putting irrelevant things in commit messages, etc, then those can easily
> be removed; OTOH, if someone has a patch and doesn't provide a signoff,
> that'd be an orthogonal problem that isn't specific to this situation,
> as you couldn't assume you could incorporate the patch.) Then apply the
> patch as a fix, and include it in their next pull request upstream.
>
> Roughly speaking, I'd treat that situation the same as "what if someone
> has a patch that's otherwise entirely correct, and a now non-functional
> email address that bounces, with no way to reach them", and proceed
> accordingly.

It's not exactly the same: for the non-functional email address, you can
still fix the issue yourself with a "Reported-by" line, without violating the
rule about publishing addresses, as the address is no longer valid.

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] New CoC and Brendan Eich

[Josh Triplett]

On Fri, Oct 05, 2018 at 09:16:06AM +0200, Geert Uytterhoeven wrote:
> On Thu, Oct 4, 2018 at 10:58 PM Josh Triplett <josh@joshtriplett.org> wrote:
> > On Thu, Oct 04, 2018 at 09:39:57PM +0100, Al Viro wrote:
> > > On Thu, Oct 04, 2018 at 09:33:15PM +0300, Laurent Pinchart wrote:
> > >       * contributor Alice gets banned from contributing, for whatever reason
> > >       * Alice finds a roothole and posts a technically valid fix
> > >       * maintainer Bob sees the posting, verifies that the bug is real, that
> > > the fix is correct and that the source of that patch is banned.
> > >
> > > What should Bob do?  Discuss.
> >
> > (Presumably they "post" that to some place that isn't part of the Linux
> > kernel community, such as a security research group. Also, let's leave
> > aside that the above scenario would come after some non-trivial
> > likely-private discussion with them, in which they refused to meet the
> > standards expected of the kernel community; standing reminder that bans
> > aren't typically step 1 of a process.)
> >
> > What do you do when a patch is posted that fixes a real bug but doesn't
> > meet patch requirements in other ways? I've seen developers fix up such
> > patches themselves, with varying degrees of effort required; I've also
> > seen developers reject such patches with a request to fix, and other
> > people coming along to clean up the same fix. See also grsecurity
> > patches.
> >
> > What do you do if some random downstream kernel branch (e.g. a distro or
> > vendor kernel) has a useful patch, and you don't expect the person who
> > wrote it to contribute it upstream, but it still has a signoff and
> > you're willing to do the work yourself?
> >
> > In general: verify that the patch works, still has the right license,
> > has a signoff, etc. (If someone is being particularly vindictive and
> > putting irrelevant things in commit messages, etc, then those can easily
> > be removed; OTOH, if someone has a patch and doesn't provide a signoff,
> > that'd be an orthogonal problem that isn't specific to this situation,
> > as you couldn't assume you could incorporate the patch.) Then apply the
> > patch as a fix, and include it in their next pull request upstream.
> >
> > Roughly speaking, I'd treat that situation the same as "what if someone
> > has a patch that's otherwise entirely correct, and a now non-functional
> > email address that bounces, with no way to reach them", and proceed
> > accordingly.
> 
> It's not exactly the same: for the non-functional email address, you can
> still fix the issue yourself with a "Reported-by" line, without violating the
> rule about publishing addresses, as the address is no longer valid.

That wasn't the situation as proposed; the situation as proposed
involved a patch already written. (And the email address issue was
already discussed; an email address attached to a publically posted
patch is hardly private information.)

Re: [Ksummit-discuss] New CoC and Brendan Eich

[Geert Uytterhoeven]

Hi Josh,

On Fri, Oct 5, 2018 at 9:52 AM Josh Triplett <josh@joshtriplett.org> wrote:
> On Fri, Oct 05, 2018 at 09:16:06AM +0200, Geert Uytterhoeven wrote:
> > On Thu, Oct 4, 2018 at 10:58 PM Josh Triplett <josh@joshtriplett.org> wrote:
> > > On Thu, Oct 04, 2018 at 09:39:57PM +0100, Al Viro wrote:
> > > > On Thu, Oct 04, 2018 at 09:33:15PM +0300, Laurent Pinchart wrote:
> > > >       * contributor Alice gets banned from contributing, for whatever reason
> > > >       * Alice finds a roothole and posts a technically valid fix
> > > >       * maintainer Bob sees the posting, verifies that the bug is real, that
> > > > the fix is correct and that the source of that patch is banned.
> > > >
> > > > What should Bob do?  Discuss.
> > >
> > > (Presumably they "post" that to some place that isn't part of the Linux
> > > kernel community, such as a security research group. Also, let's leave
> > > aside that the above scenario would come after some non-trivial
> > > likely-private discussion with them, in which they refused to meet the
> > > standards expected of the kernel community; standing reminder that bans
> > > aren't typically step 1 of a process.)
> > >
> > > What do you do when a patch is posted that fixes a real bug but doesn't
> > > meet patch requirements in other ways? I've seen developers fix up such
> > > patches themselves, with varying degrees of effort required; I've also
> > > seen developers reject such patches with a request to fix, and other
> > > people coming along to clean up the same fix. See also grsecurity
> > > patches.
> > >
> > > What do you do if some random downstream kernel branch (e.g. a distro or
> > > vendor kernel) has a useful patch, and you don't expect the person who
> > > wrote it to contribute it upstream, but it still has a signoff and
> > > you're willing to do the work yourself?
> > >
> > > In general: verify that the patch works, still has the right license,
> > > has a signoff, etc. (If someone is being particularly vindictive and
> > > putting irrelevant things in commit messages, etc, then those can easily
> > > be removed; OTOH, if someone has a patch and doesn't provide a signoff,
> > > that'd be an orthogonal problem that isn't specific to this situation,
> > > as you couldn't assume you could incorporate the patch.) Then apply the
> > > patch as a fix, and include it in their next pull request upstream.
> > >
> > > Roughly speaking, I'd treat that situation the same as "what if someone
> > > has a patch that's otherwise entirely correct, and a now non-functional
> > > email address that bounces, with no way to reach them", and proceed
> > > accordingly.
> >
> > It's not exactly the same: for the non-functional email address, you can
> > still fix the issue yourself with a "Reported-by" line, without violating the
> > rule about publishing addresses, as the address is no longer valid.
>
> That wasn't the situation as proposed; the situation as proposed
> involved a patch already written. (And the email address issue was

I agree it's not 100% the same.
What do you do now, if someone sends a patch fixing a critical issue,
but the patch is not up to your standards as a maintainer, and the
submitter runs away, and never follows up?

> already discussed; an email address attached to a publically posted
> patch is hardly private information.)

Which you cannot publish as the person was banned?
Just stripping the banned person's name is also not a solution, as that would
be willful copyright violation.

Summary: banning persons from contributing opens a new can of worms.

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] New CoC and Brendan Eich

[Josh Triplett]

On Fri, Oct 05, 2018 at 10:00:11AM +0200, Geert Uytterhoeven wrote:
> On Fri, Oct 5, 2018 at 9:52 AM Josh Triplett <josh@joshtriplett.org> wrote:
> > That wasn't the situation as proposed; the situation as proposed
> > involved a patch already written. (And the email address issue was
> 
> I agree it's not 100% the same.
> What do you do now, if someone sends a patch fixing a critical issue,
> but the patch is not up to your standards as a maintainer, and the
> submitter runs away, and never follows up?

Depends on if you care to do the work fixing up the patch yourself.
If you do, you can always rework it, and include a "based on a patch
from" note or similar in the commit message.

> > already discussed; an email address attached to a publically posted
> > patch is hardly private information.)
> 
> Which you cannot publish as the person was banned?
> Just stripping the banned person's name is also not a solution, as that would
> be willful copyright violation.

I don't see a reason why it would be necessary to strip someone's name
just because they're no longer welcome in discussions. Just don't CC
them.

Re: [Ksummit-discuss] New CoC and Brendan Eich

[James Bottomley]

On Fri, 2018-10-05 at 00:51 -0700, Josh Triplett wrote:
> On Fri, Oct 05, 2018 at 09:16:06AM +0200, Geert Uytterhoeven wrote:
[...]
> > It's not exactly the same: for the non-functional email address,
> > you can still fix the issue yourself with a "Reported-by" line,
> > without violating the rule about publishing addresses, as the
> > address is no longer valid.
> 
> That wasn't the situation as proposed; the situation as proposed
> involved a patch already written. (And the email address issue was
> already discussed; an email address attached to a publically posted
> patch is hardly private information.)

It's been discussed but I don't think there's been agreement about the
potential problems.  The problematic piece is specific mention of email
address as private information.

To give a more cogent example: it also mentions physical address. 
However, for anyone who owns their own house physical address is also a
matter of public record; to find it all I have to do is search the
county property records which means I can get it as long as I roughly
know where you live.  I think posting someone's actual address would be
a CoC violation because it's irrelevant to any patch process I can
think of and yet for most people it would still be "public
information".  The intent around that particular clause of the CoC
seems to be to give enhanced privacy to something that may or may not
be in the public domain, but it's badly worded to cover stuff that we
use as part of our everyday process.

James