Re: [PATCH] add a Code of Conduct document

From: Derrick Stolee <stolee@gmail.com>
Date: Sep 24, 2019, 12:13 UTC
Message-ID: <6a9fb4c2-6c80-4475-03d3-89bdba73095b@gmail.com>
In-Reply-To: <20190924064454.GA30419@sigill.intra.peff.net>

On 9/24/2019 2:44 AM, Jeff King wrote:

Show 11 quoted lines

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

This point is very important. We have a long document about how to style our code, and it's very easy to point to it when someone uses code style that doesn't fit. "We don't do that here" can apply to behavior as well.

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

And on the other side: the covenant you use includes positive examples.

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

Let's adopt a CoC before we need it.

Show 9 quoted lines

> 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:
> 
>   https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

This is wise. Adopting an existing document is better than rolling our own.

Show 18 quoted lines

> 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 git@sfconservancy.org 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.

It makes sense to leave these vague. If we are too specific, then those
rules can be used against us by a bad actor.

Show 14 quoted lines

> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Obviously related to the discussion in:
> 
>   https://public-inbox.org/git/71fba9e7-6314-6ef9-9959-6ae06843d17a@gmail.com/
> 
> 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.
> 
> I did find this nice set of guidelines in an old discussion:
> 
>   https://github.com/mhagger/git/commit/c6e6196be8fab3d48b12c4e42eceae6937538dee

While this document has good information, most of it would be better suited for a "Reviewing Code" guide. The CoC is more general, as it applies to behavior on-list AND off-list.

Show 11 quoted lines

> I think it's missing some things that are "standard" in more modern CoCs
> (in particular, there's not much discussion of enforcement or
> responsibilities, and I think those are important for the "making people
> comfortable" goal). But maybe there are bits we'd like to pick out for
> other documents; not so much "_what_ we expect" as "here are some tips
> on _how_".
> 
> 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.

I fully endorse this patch! Thanks!

-Stolee