ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] New CoC and Brendan Eich
Date: Wed, 10 Oct 2018 10:57:54 -0300	[thread overview]
Message-ID: <20181010105754.0a46e1b3@coco.lan> (raw)
In-Reply-To: <CAMuHMdWBWKtZDpdYn0zaWFnF27pnenu6Ha5wq-40QPWE+D-pFQ@mail.gmail.com>

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

  reply	other threads:[~2018-10-10 13:58 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-04 16:23 jonsmirl
2018-10-04 18:33 ` Laurent Pinchart
2018-10-04 19:05   ` jonsmirl
2018-10-04 19:21     ` Rodrigo Vivi
2018-10-04 19:53       ` jonsmirl
2018-10-05  7:21       ` Geert Uytterhoeven
2018-10-08 21:35       ` Mauro Carvalho Chehab
2018-10-08 23:20         ` Rodrigo Vivi
2018-10-09 10:07           ` Mauro Carvalho Chehab
2018-10-09 15:59             ` Rodrigo Vivi
2018-10-09 16:52             ` Chris Mason
2018-10-09 22:03               ` Dan Williams
2018-10-10  6:47                 ` Geert Uytterhoeven
2018-10-10 13:57                   ` Mauro Carvalho Chehab [this message]
2018-10-10 17:21                     ` Josh Triplett
2018-10-10 18:28                       ` Mauro Carvalho Chehab
2018-10-10 19:56                         ` Josh Triplett
2018-10-10 20:12                           ` Mauro Carvalho Chehab
2018-10-10 20:17                             ` Josh Triplett
2018-10-04 19:34     ` Laurent Pinchart
2018-10-04 20:39   ` Al Viro
2018-10-04 20:56     ` Jonathan Corbet
2018-10-04 21:27       ` Thomas Gleixner
2018-10-04 22:04         ` Jonathan Corbet
2018-10-05 16:03           ` Theodore Y. Ts'o
2018-10-04 22:05         ` Tim.Bird
2018-10-05  6:23           ` Christoph Hellwig
2018-10-05  7:12       ` Geert Uytterhoeven
2018-10-05  7:50         ` Josh Triplett
2018-10-05  9:20           ` Jani Nikula
2018-10-05  9:57             ` Laurent Pinchart
2018-10-05 10:45               ` Joe Perches
2018-10-05 10:55                 ` Laurent Pinchart
2018-10-05 12:59               ` Jani Nikula
2018-10-05 13:09                 ` Laurent Pinchart
2018-10-05 15:17                 ` James Bottomley
2018-10-05 18:28                   ` Josh Triplett
2018-10-05 18:39                     ` James Bottomley
2018-10-04 20:57     ` Josh Triplett
2018-10-05  7:16       ` Geert Uytterhoeven
2018-10-05  7:51         ` Josh Triplett
2018-10-05  8:00           ` Geert Uytterhoeven
2018-10-05  8:44             ` Josh Triplett
2018-10-05 15:26           ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181010105754.0a46e1b3@coco.lan \
    --to=mchehab+samsung@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox