From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A5EFEA84 for ; Tue, 9 Oct 2018 15:59:52 +0000 (UTC) Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8E8E77C for ; Tue, 9 Oct 2018 15:59:51 +0000 (UTC) Received: by mail-wm1-f41.google.com with SMTP id 206-v6so2424964wmb.5 for ; Tue, 09 Oct 2018 08:59:51 -0700 (PDT) MIME-Version: 1.0 References: <6108593.JtmfA2IdsK@avalon> <20181008183423.4bdcaeea@coco.lan> <20181009070736.42b8fea5@coco.lan> In-Reply-To: <20181009070736.42b8fea5@coco.lan> From: Rodrigo Vivi Date: Tue, 9 Oct 2018 08:59:32 -0700 Message-ID: To: Mauro Carvalho Chehab Content-Type: multipart/alternative; boundary="000000000000dd42d30577cdd35d" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] New CoC and Brendan Eich List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000000000000dd42d30577cdd35d Content-Type: text/plain; charset="UTF-8" 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 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 > --000000000000dd42d30577cdd35d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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 b= eing accused of
> > > > violating the CoC and they lose $20M in options? INAL b= ut 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.
> > > >=C2=A0
> > >
> > > 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 n= ever saw anyone
> > > blaming news or social networks for that. The cause of this = consequence=C2=A0
> > is=C2=A0
> > > on the speech itself, not on the channels....=C2=A0
> >
> > No, that's not what's written at the letter of the CoC. I= t is written
> > there that:
> >
> > If developer A violates the CoC insulting developer B, the mainta= iner C is
> > responsible to take actions against developer B.
> >
> > If maintainer C doesn't take actions[1], developer B can comp= lain 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 el= se
> > that was unable to "educate" developer A.
> >
> > [1] It should be notice that, even the best good will maintainer<= br> > > won't be able to enforce the CoC, as several actions are impo= ssible 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 de= veloper A
> > is limited, as he usually doesn't maintain the e-mail server.= So, he has
> > to ask someone else to do that.
> >=C2=A0
>
> Thanks for explaining like this. Maybe now I understand why some peopl= e
> 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 &qu= ot;edit or reject if possible" or whenever possible
or somet= hing like that. Because if we can edit but don't take any action we are=
being conniving.
=C2=A0

> So, a company would fire maintainer for being conniving with an harass= ment
> or any other unacceptable behavior, right?!
>
> So, Developer A shouts racists words, maintainer C doesn't C the e= mail.
> 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 addition= s to make it more clear about
the procedures and recommendations.=
Instead of remove critical parts.
=C2=A0

-

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 possib= le...
=C2=A0

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?

=C2=A0

-

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