list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: Johannes Schindelin <>
To: "SZEDER Gábor" <>
Cc: Jeff King <>,,,
	Derrick Stolee <>,
	Emily Shaffer <>,
	Jonathan Nieder <>,
	Junio C Hamano <>,
Subject: Re: [PATCH] add a Code of Conduct document
Date: Tue, 24 Sep 2019 15:20:42 +0200 (CEST)
Message-ID: <> (raw)
In-Reply-To: <>

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

Hi Gábor,

On Tue, 24 Sep 2019, SZEDER Gábor wrote:

> On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> > We've never had a formally written Code of Conduct document. Though it
> > has been discussed off and on over the years, for the most part the
> > behavior on the mailing list has been good enough that nobody felt the
> > need to push one forward.
> >
> > However, even if there aren't specific problems now, it's a good idea to
> > have a document:
> >
> >   - it puts everybody on the same page with respect to expectations.
> >     This might avoid poor behavior, but also makes it easier to handle
> >     it if it does happen.
> >
> >   - it publicly advertises that good conduct is important to us and will
> >     be enforced, which may make some people more comfortable with
> >     joining our community
> >
> >   - it may be a good time to cement our expectations when things are
> >     quiet, since it gives everybody some distance rather than focusing
> >     on a current contentious issue
> >
> > This patch adapts the Contributor Covenant Code of Conduct. As opposed
> > to writing our own from scratch, this uses common and well-accepted
> > language, and strikes a good balance between illustrating expectations
> > and avoiding a laundry list of behaviors. It's also the same document
> > used by the Git for Windows project.
> >
> > The text is taken mostly verbatim from:
> >
> >
> >
> > I also stole a very nice introductory paragraph from the Git for Windows
> > version of the file.
> >
> > There are a few subtle points, though:
> >
> >   - the document refers to "the project maintainers". For the code, we
> >     generally only consider there to be one maintainer: Junio C Hamano.
> >     But for dealing with community issues, it makes sense to involve
> >     more people to spread the responsibility. I've listed the project
> >     committee address of as the contact point.
> >
> >   - the document mentions banning from the community, both in the intro
> >     paragraph and in "Our Responsibilities". The exact mechanism here is
> >     left vague. I can imagine it might start with social enforcement
> >     (not accepting patches, ignoring emails) and could escalate to
> >     technical measures if necessary (asking vger admins to block an
> >     address). It probably make sense _not_ to get too specific at this
> >     point, and deal with specifics as they come up.
> >
> > Signed-off-by: Jeff King <>
> > ---
> > Obviously related to the discussion in:
> >
> >
> >
> > After some poking around at various CoC options, this one seemed like
> > the best fit to me. But I'm open to suggestions or more discussion. It
> > seems to me that the important piece is having _some_ CoC, and picking
> > something standard-ish seems a safe bet.
> We are decent people,

Okay, you are _asking_ for a devil's advocate, like, _really asking_ for
it, and I will bite.

You don't know that we are decent people. I don't know whether you are a
decent person, neither do you know whether I am a decent person.

To make things worse: your concept of "decent" might be very different
from mine. In fact, I am almost certain that they are different, _and_
Git is an international project that attracts different people that have
yet different notions of what constitutes "decent".

Concrete example: a former mentee of mine, from a different cultural
background than mine, found it indecent to voice disagreement with me,
on the sole ground that I was their mentor. Let that sink in for a
while. In the Git project, we _expect_ contributors to disagree with
reviews that miss a point, to make a counterargument. That act alone
would have been considered "indecent" by at least one contributor.

And to make things _even_ worse: even a decent person has bad days, and
bad days make for poor decisions, including how to treat fellow human
beings. Having a "banister" (as the CoC would provide) is pretty helpful
on those days.

> and know how to behave properly and treat each other with respect.  It
> is my fundamental assumption that all future contributors are decent
> and respectful human beings as well.

Judging from certain examples in the past, I expect that Git will see
the occasional future contributor where having a CoC comes in real

> A CoC like this, which is "explicit about the behavior we want to
> model" (quoting the original discussion starter) inherently insinuates
> that we aren't decent, and can't behave without being told how to do
> so.  Frankly, I find this borderline insulting to me, to my parents,
> to all fellow contributors, and to future contributors as well.

By that token, you should find any law offensive that forbids you from
stealing. Because you, and your family, are not thieves.

Does that sound reasonable? I would contest that.

Just because you abide by a code of conduct does not mean that you are
prone to violate it. In fact, I would expect that those who are the
least prone to violate it are the ones who would be least opposed to
one: what would they have to fear from it?

> There are locations, nationalities and cultures, where the avarage
> wide-spread CoCs, like Contributor Covenant and its derivatives, are
> perceived as (paraphrasing) too "American", politically overcorrect,
> corporate BS, etc., which are forced upon open-source projects.

This knife cuts both ways, of course. I cannot count how many times I
heard unflattering things about e.g. a former Hungarian colleague of
mine who voiced opinions that were, at times, quite offensive to the
rest of the staff, and it was often excused as "East European".

In a multi-cultural team, respect often comes in the form of learning
about one another's cultural background, and compromising, sometimes
unexpectedly so.

A CoC can very easily create clarity in such circumstances. By stating
explicitly the standards to which we promise to hold ourselves, as well
as others. And it can even help those who think of themselves as decent
to improve on that front.

Example: in Git for Windows, we adopted a variant of the Contributors'
Covenant a couple of years ago. From my side, it was specifically
intended not only to create a safe space for underrepresented groups, it
was also intended to give a promise to contributors that I will hold
myself to that standard, too. Guess what: several times I failed. I am
human. I was called out for it, rightfully so, and it helped me improve
the way I communicate. (I still have a ways to go, of course.)

I still stand by my statement from above: nobody has anything to fear
from a CoC, except those who are prone or even intent on violating it.
In which case I am very much in favor of a CoC, and very, very much not
against it.

> Consequently, such CoCs are often found rather discouraging, and
> announcements about their adoption in open-source projects generally
> get negative reaction.

That does not match my experience. In Git for Windows' case, I can
recall only one minor negative reaction (private, if I remember
correctly), and in that case, I have to admit that I feel my statement
from above very much validated: that person did not seem to _want_ to
abide by the common decency called for by the CoC.

> Less is more.  Much-much more.  A concise CoC that treats its readers
> as responsible, well-behaved human beings is met with much approval.

But do those readers approve of the same thing? Like, do they really
have the same understanding of that concise CoC? I have experienced
_way_ too diverging interpretations of short texts like the one you
linked below to believe _that_.

> Take, for example, the TrueOS Rules of Conduct, which in just a few
> short sentences covers everything that's worth covering:

This is what I understand from reading this very terse statement: "We do
not want to be criticized for the way we talk, no matter how offended
people might get, and here is an email address that might, or might not,
be monitored, where you can complain, if you must. Good luck to you."

> If diversity and inclusion of other cultures is indeed a priority,
> then we should carefully consider that some potential contributors
> will rather choose not to contribute because of a CoC like this.

Let me be blunt for a minute. The proposed CoC would not change anything
for any contributor I consider decent. Not one thing. There would not be
any need to change any behavior, no need to complain, they could just
read the CoC and say: "Yep, that's right, that's exactly how I want to
behave, and that's how I want the others in this project to behave. Back
to this bug I wanted to debug/this feature I wanted to implement..."

> > If people are on board with this direction, it might be fun to pick
> > up a bunch of "Acked-by" trailers from people in the community who
> > agree with it. It might give it more weight if many members have
> > publicly endorsed it.
> Because of the above I'm leaning towards NACK.

It makes me sad to hear that, in particular because I give this patch a
big ACK.

To understand better why you are so negative about it:

- would you feel that you have to do anything differently from before?

- do you think that the CoC does not describe your values that you have

- could you propose a better alternative to the CoC, which -- by Junio's
  own words -- would have helped tremendously in the past, would have
  made it easier for Junio and some others to deal with at least one
  very real, and very damaging problem?


  reply	other threads:[~2019-09-24 13:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24  6:44 Jeff King
2019-09-24  9:01 ` SZEDER Gábor
2019-09-24 13:20   ` Johannes Schindelin [this message]
2019-09-24 15:50     ` Jeff King
2019-09-25  6:39     ` Daniel Stenberg
2019-09-24 14:40   ` Phillip Wood
2019-09-24 12:13 ` Derrick Stolee
2019-09-24 15:51   ` Jeff King
2019-09-24 14:13 ` Phillip Wood
2019-09-24 16:53 ` Garima Singh
2019-09-24 16:56   ` Deb Nicholson
2019-09-24 17:12 ` Denton Liu
2019-09-24 20:05   ` Pratyush Yadav
2019-09-24 20:10     ` Doug Maxey
2019-09-24 20:52     ` Jeff King
2019-09-24 20:46   ` Jeff King
2019-09-24 23:52   ` Emily Shaffer
2019-09-26  7:20     ` [PATCH] CODE_OF_CONDUCT: mention individual project-leader emails Jeff King
2019-09-26 12:16       ` Derrick Stolee
2019-09-26 21:37       ` Emily Shaffer
2019-09-27 18:58       ` CB Bailey
2019-09-24 17:23 ` [PATCH] add a Code of Conduct document Jonathan Tan
2019-09-24 17:40 ` Thomas Gummerer
2019-09-24 20:14 ` René Scharfe
2019-09-24 21:09   ` Jeff King
2019-09-25 12:34     ` Johannes Schindelin
2019-09-24 23:37 ` brian m. carlson
2019-09-26 17:42 ` Elijah Newren

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone