[PATCH] add a Code of Conduct document

[PATCH] add a Code of Conduct document

[Jeff King]

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:

  https://www.contributor-covenant.org/version/1/4/code-of-conduct.html

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.

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

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've cc'd git@sfconservancy.org here, because I think it's important for
all of the project committee members to endorse it (and because the
document puts us on the hook for enforcing it!).

 CODE_OF_CONDUCT.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 85 insertions(+)
 create mode 100644 CODE_OF_CONDUCT.md

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
new file mode 100644
index 0000000000..b94f72b0b8
--- /dev/null
+++ b/CODE_OF_CONDUCT.md
@@ -0,0 +1,85 @@
+# Git Code of Conduct
+
+This code of conduct outlines our expectations for participants within
+the Git community, as well as steps for reporting unacceptable behavior.
+We are committed to providing a welcoming and inspiring community for
+all and expect our code of conduct to be honored. Anyone who violates
+this code of conduct may be banned from the community.
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to make participation in our project and
+our community a harassment-free experience for everyone, regardless of age,
+body size, disability, ethnicity, sex characteristics, gender identity and
+expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+  advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies
+when an individual is representing the project or its community in public
+spaces. Examples of representing a project or community include using an
+official project e-mail address, posting via an official social media account,
+or acting as an appointed representative at an online or offline event.
+Representation of a project may be further defined and clarified by project
+maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at git@sfconservancy.org. All
+complaints will be reviewed and investigated and will result in a response
+that is deemed necessary and appropriate to the circumstances. The project
+team is obligated to maintain confidentiality with regard to the reporter of
+an incident. Further details of specific enforcement policies may be posted
+separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq
-- 
2.23.0.763.g3828a6cd7f

Re: [PATCH] add a Code of Conduct document

[SZEDER Gábor]

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

We are decent people, 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.  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.

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

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

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

  https://www.trueos.org/rulesofconduct/

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.


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

Re: [PATCH] add a Code of Conduct document

[Johannes Schindelin]

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

> 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:
>
>   https://www.trueos.org/rulesofconduct/

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

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

Thanks,
Dscho

Re: [PATCH] add a Code of Conduct document

[Jeff King]

On Tue, Sep 24, 2019 at 03:20:42PM +0200, Johannes Schindelin wrote:

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

Thanks for your response, Dscho. I was all set to reply to Gábor, but
you made all my points for me. :)

In particular, I think this paragraph is key. I don't think this CoC is
asking to change anything about how we work or communicate currently. I
view it as writing down the status quo (which is valuable for the
reasons I mentioned in the commit message).

(None of which is to say that people might not have disagreements that
need resolving, or that discussions about communication style aren't
welcome; just that I think the CoC is at a more meta level).

-Peff

Re: [PATCH] add a Code of Conduct document

[Daniel Stenberg]

On Tue, 24 Sep 2019, Johannes Schindelin wrote:

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

As one of the lurking not-really-in-this-project persons around, I just want 
to step out of the shadows for a sec and say:

I think this is totally the right move and I'm a strong +1 on the CoC as 
suggested.

-- 

  / daniel.haxx.se

Re: [PATCH] add a Code of Conduct document

[Phillip Wood]

Hi Gábor

On 24/09/2019 10:01, SZEDER Gábor wrote:
> On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
>> [...]
>>
>> 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, 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.

History suggests that almost all will be decent but there will be one or 
two who aren't and cause trouble.

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

I don't find it insulting, to me it just sets out that the project 
welcomes contributors who behave decently.

> 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.
> Consequently, such CoCs are often found rather discouraging, and
> announcements about their adoption in open-source projects generally
> get negative reaction.
> 
> Less is more.  Much-much more.  A concise CoC that treats its readers
> as responsible, well-behaved human beings is met with much approval.

I was pleasantly surprised at how short the proposed CoC is, I don't 
think it's too long at all. It only takes a couple of minutes to read 
and is quite clear.

Best Wishes

Phillip


> Take, for example, the TrueOS Rules of Conduct, which in just a few
> short sentences covers everything that's worth covering:
> 
>    https://www.trueos.org/rulesofconduct/
> 
> 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.
> 
> 
>> 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.
> 

Re: [PATCH] add a Code of Conduct document

[Derrick Stolee]

On 9/24/2019 2:44 AM, 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.

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.

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

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

> 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

Re: [PATCH] add a Code of Conduct document

[Jeff King]

On Tue, Sep 24, 2019 at 08:13:27AM -0400, Derrick Stolee wrote:

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

Yeah, that was specifically what I was thinking with "maybe this could
go in some other documents". I don't know if anybody is actively working
on a reviewer's guide, though.

-Peff

Re: [PATCH] add a Code of Conduct document

[Phillip Wood]

Hi Peff

On 24/09/2019 07:44, 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

I think these are all good points, it is definitely better to discuss 
this when there isn't a pressing problem to resolve.

> 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
> 
> I also stole a very nice introductory paragraph from the Git for Windows
> version of the file.

Using an existing text makes sense, even more so if it is being 
successfully used by git for windows

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

I think this is a sensible approach - it needs to be clear that there is 
a mechanism to deal with violations otherwise there's no point to having 
a CoC but we don't want to get bogged down by a whole sequence of what 
if someone does this that or the other.

I think the text below does a good job of setting out expectations 
without being too long

Best Wishes

Phillip

> 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
> 
> 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've cc'd git@sfconservancy.org here, because I think it's important for
> all of the project committee members to endorse it (and because the
> document puts us on the hook for enforcing it!).
> 
>   CODE_OF_CONDUCT.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 85 insertions(+)
>   create mode 100644 CODE_OF_CONDUCT.md
> 
> diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
> new file mode 100644
> index 0000000000..b94f72b0b8
> --- /dev/null
> +++ b/CODE_OF_CONDUCT.md
> @@ -0,0 +1,85 @@
> +# Git Code of Conduct
> +
> +This code of conduct outlines our expectations for participants within
> +the Git community, as well as steps for reporting unacceptable behavior.
> +We are committed to providing a welcoming and inspiring community for
> +all and expect our code of conduct to be honored. Anyone who violates
> +this code of conduct may be banned from the community.
> +
> +## Our Pledge
> +
> +In the interest of fostering an open and welcoming environment, we as
> +contributors and maintainers pledge to make participation in our project and
> +our community a harassment-free experience for everyone, regardless of age,
> +body size, disability, ethnicity, sex characteristics, gender identity and
> +expression, level of experience, education, socio-economic status,
> +nationality, personal appearance, race, religion, or sexual identity and
> +orientation.
> +
> +## Our Standards
> +
> +Examples of behavior that contributes to creating a positive environment
> +include:
> +
> +* Using welcoming and inclusive language
> +* Being respectful of differing viewpoints and experiences
> +* Gracefully accepting constructive criticism
> +* Focusing on what is best for the community
> +* Showing empathy towards other community members
> +
> +Examples of unacceptable behavior by participants include:
> +
> +* The use of sexualized language or imagery and unwelcome sexual attention or
> +  advances
> +* Trolling, insulting/derogatory comments, and personal or political attacks
> +* Public or private harassment
> +* Publishing others' private information, such as a physical or electronic
> +  address, without explicit permission
> +* Other conduct which could reasonably be considered inappropriate in a
> +  professional setting
> +
> +## Our Responsibilities
> +
> +Project maintainers are responsible for clarifying the standards of acceptable
> +behavior and are expected to take appropriate and fair corrective action in
> +response to any instances of unacceptable behavior.
> +
> +Project maintainers have the right and responsibility to remove, edit, or
> +reject comments, commits, code, wiki edits, issues, and other contributions
> +that are not aligned to this Code of Conduct, or to ban temporarily or
> +permanently any contributor for other behaviors that they deem inappropriate,
> +threatening, offensive, or harmful.
> +
> +## Scope
> +
> +This Code of Conduct applies within all project spaces, and it also applies
> +when an individual is representing the project or its community in public
> +spaces. Examples of representing a project or community include using an
> +official project e-mail address, posting via an official social media account,
> +or acting as an appointed representative at an online or offline event.
> +Representation of a project may be further defined and clarified by project
> +maintainers.
> +
> +## Enforcement
> +
> +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> +reported by contacting the project team at git@sfconservancy.org. All
> +complaints will be reviewed and investigated and will result in a response
> +that is deemed necessary and appropriate to the circumstances. The project
> +team is obligated to maintain confidentiality with regard to the reporter of
> +an incident. Further details of specific enforcement policies may be posted
> +separately.
> +
> +Project maintainers who do not follow or enforce the Code of Conduct in good
> +faith may face temporary or permanent repercussions as determined by other
> +members of the project's leadership.
> +
> +## Attribution
> +
> +This Code of Conduct is adapted from the [Contributor Covenant][homepage],
> +version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
> +
> +[homepage]: https://www.contributor-covenant.org
> +
> +For answers to common questions about this code of conduct, see
> +https://www.contributor-covenant.org/faq
> 

Re: [PATCH] add a Code of Conduct document

[Garima Singh]

On 9/24/2019 2:44 AM, Jeff King wrote:
> 
> 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've cc'd git@sfconservancy.org here, because I think it's important for
> all of the project committee members to endorse it (and because the
> document puts us on the hook for enforcing it!).
> 

I think this looks really good. I appreciate how it gets the point across for
people to empower each other and welcome new members without being too wordy.
It gets my wholehearted ACK. Thanks for putting it together. 

Cheers,
Garima G Singh

Re: [PATCH] add a Code of Conduct document

[Deb Nicholson]

Hi all, 
Deb here from Git's fiscal home. Let us know if you need any advice or
help finding a professional consultant to take a look at the Code of
Conduct document for you. I'm also happy to perosanlly take a look at
any draft(s).
Best, 
Deb


On Tue, 2019-09-24 at 12:53 -0400, Garima Singh wrote:
> On 9/24/2019 2:44 AM, Jeff King wrote:
> > 
> > 
> > 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've cc'd git@sfconservancy.org here, because I think it's
> > important for
> > all of the project committee members to endorse it (and because the
> > document puts us on the hook for enforcing it!).
> > 
> I think this looks really good. I appreciate how it gets the point
> across for
> people to empower each other and welcome new members without being
> too wordy.
> It gets my wholehearted ACK. Thanks for putting it together. 
> 
> Cheers,
> Garima G Singh
-- 
Deb Nicholson <deb@sfconservancy.org>
Software Freedom Conservancy

Re: [PATCH] add a Code of Conduct document

[Denton Liu]

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:
> 
>   https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
> 
> 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.
> 
> 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
> 
> 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've cc'd git@sfconservancy.org here, because I think it's important for
> all of the project committee members to endorse it (and because the
> document puts us on the hook for enforcing it!).

I tried looking it up but I couldn't find who the project committee
members are. Is this list published anywhere? More on that later...

> 
>  CODE_OF_CONDUCT.md | 85 ++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 85 insertions(+)
>  create mode 100644 CODE_OF_CONDUCT.md
> 
> diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
> new file mode 100644
> index 0000000000..b94f72b0b8
> --- /dev/null
> +++ b/CODE_OF_CONDUCT.md
> @@ -0,0 +1,85 @@
> +# Git Code of Conduct
> +
> +This code of conduct outlines our expectations for participants within
> +the Git community, as well as steps for reporting unacceptable behavior.
> +We are committed to providing a welcoming and inspiring community for
> +all and expect our code of conduct to be honored. Anyone who violates
> +this code of conduct may be banned from the community.
> +
> +## Our Pledge
> +
> +In the interest of fostering an open and welcoming environment, we as
> +contributors and maintainers pledge to make participation in our project and
> +our community a harassment-free experience for everyone, regardless of age,
> +body size, disability, ethnicity, sex characteristics, gender identity and
> +expression, level of experience, education, socio-economic status,
> +nationality, personal appearance, race, religion, or sexual identity and
> +orientation.
> +
> +## Our Standards
> +
> +Examples of behavior that contributes to creating a positive environment
> +include:
> +
> +* Using welcoming and inclusive language
> +* Being respectful of differing viewpoints and experiences
> +* Gracefully accepting constructive criticism
> +* Focusing on what is best for the community
> +* Showing empathy towards other community members
> +
> +Examples of unacceptable behavior by participants include:
> +
> +* The use of sexualized language or imagery and unwelcome sexual attention or
> +  advances
> +* Trolling, insulting/derogatory comments, and personal or political attacks
> +* Public or private harassment
> +* Publishing others' private information, such as a physical or electronic
> +  address, without explicit permission

Since this is a mailing list-based project, we should explicitly state
that email addresses and names don't count as private information since
it's vital for discourse.

On that note, I like the idea of having a CoC-interpretations document,
much like the one in the Linux kernel[1]. In my opinion, having one
would remove a lot of the vagueness (such as the emails issue) in the
CoC and close us off from people loophole lawyering over the language
used.

> +* Other conduct which could reasonably be considered inappropriate in a
> +  professional setting
> +
> +## Our Responsibilities
> +
> +Project maintainers are responsible for clarifying the standards of acceptable
> +behavior and are expected to take appropriate and fair corrective action in
> +response to any instances of unacceptable behavior.
> +
> +Project maintainers have the right and responsibility to remove, edit, or
> +reject comments, commits, code, wiki edits, issues, and other contributions

Since we use patches here, we should probably explicitly state that too.

> +that are not aligned to this Code of Conduct, or to ban temporarily or
> +permanently any contributor for other behaviors that they deem inappropriate,
> +threatening, offensive, or harmful.
> +
> +## Scope
> +
> +This Code of Conduct applies within all project spaces, and it also applies
> +when an individual is representing the project or its community in public
> +spaces. Examples of representing a project or community include using an
> +official project e-mail address, posting via an official social media account,
> +or acting as an appointed representative at an online or offline event.
> +Representation of a project may be further defined and clarified by project
> +maintainers.
> +
> +## Enforcement
> +
> +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> +reported by contacting the project team at git@sfconservancy.org. All
> +complaints will be reviewed and investigated and will result in a response
> +that is deemed necessary and appropriate to the circumstances. The project
> +team is obligated to maintain confidentiality with regard to the reporter of
> +an incident. Further details of specific enforcement policies may be posted
> +separately.

I feel uncomfortable with this being left so wide open. First of all, I
know that the power *probably* won't be abused but I don't think
probably is good enough.

As I said above, I couldn't find a public list of the people who were on
the project committee. Perhaps that's because my Googling skills are bad
but I feel uncomfortable knowing that *anyone* will be given judge, jury
and executioner power, let alone people whom I don't know anything
about.

I'm okay with leaving it open for now but I think I would be a lot more
comfortable if we had the interpretations document to close up the
vagueness later.

Thanks for starting the discussion,

Denton

[1]: https://github.com/torvalds/linux/blob/master/Documentation/process/code-of-conduct-interpretation.rst

> +
> +Project maintainers who do not follow or enforce the Code of Conduct in good
> +faith may face temporary or permanent repercussions as determined by other
> +members of the project's leadership.
> +
> +## Attribution
> +
> +This Code of Conduct is adapted from the [Contributor Covenant][homepage],
> +version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
> +
> +[homepage]: https://www.contributor-covenant.org
> +
> +For answers to common questions about this code of conduct, see
> +https://www.contributor-covenant.org/faq
> -- 
> 2.23.0.763.g3828a6cd7f
> 

Re: [PATCH] add a Code of Conduct document

[Pratyush Yadav]

On 24/09/19 10:12AM, Denton Liu wrote:
> On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
> > +## Enforcement
> > +
> > +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> > +reported by contacting the project team at git@sfconservancy.org. All
> > +complaints will be reviewed and investigated and will result in a response
> > +that is deemed necessary and appropriate to the circumstances. The project
> > +team is obligated to maintain confidentiality with regard to the reporter of
> > +an incident. Further details of specific enforcement policies may be posted
> > +separately.
> 
> I feel uncomfortable with this being left so wide open. First of all, I
> know that the power *probably* won't be abused but I don't think
> probably is good enough.
> 
> As I said above, I couldn't find a public list of the people who were on
> the project committee. Perhaps that's because my Googling skills are bad
> but I feel uncomfortable knowing that *anyone* will be given judge, jury
> and executioner power, let alone people whom I don't know anything
> about.
 
I agree with this. I would certainly like to know who the people who 
will judge these cases are.

I want to add another question: what will the judgement process be like? 
Will it be an open discussion on this list, or will it be decided behind 
closed doors by the committee, and we just get to hear the results?

While there might be no plans regarding this as of now, I'd _really_ 
like an open discussion regarding these issues that arise in the future, 
rather than it being decided behind closed doors with us regular old
contributors getting no say in it. A closed discussion would be much 
more prone to power abuse, if any.

> I'm okay with leaving it open for now but I think I would be a lot more
> comfortable if we had the interpretations document to close up the
> vagueness later.

-- 
Regards,
Pratyush Yadav

Re: [PATCH] add a Code of Conduct document

[Doug Maxey]

On 9/24/19 3:05 PM, Pratyush Yadav wrote:
> On 24/09/19 10:12AM, Denton Liu wrote:
>> On Tue, Sep 24, 2019 at 02:44:54AM -0400, Jeff King wrote:
>>> +## Enforcement
>>> +
>>> +Instances of abusive, harassing, or otherwise unacceptable behavior may be
>>> +reported by contacting the project team at git@sfconservancy.org. All
>>> +complaints will be reviewed and investigated and will result in a response
>>> +that is deemed necessary and appropriate to the circumstances. The project
>>> +team is obligated to maintain confidentiality with regard to the reporter of
>>> +an incident. Further details of specific enforcement policies may be posted
>>> +separately.
>> I feel uncomfortable with this being left so wide open. First of all, I
>> know that the power *probably* won't be abused but I don't think
>> probably is good enough.


I can put it more succinctly:

Has anyone ever heard the pebble dropped in this well hit bottom?


>>
>> As I said above, I couldn't find a public list of the people who were on
>> the project committee. Perhaps that's because my Googling skills are bad
>> but I feel uncomfortable knowing that *anyone* will be given judge, jury
>> and executioner power, let alone people whom I don't know anything
>> about.
>   
> I agree with this. I would certainly like to know who the people who
> will judge these cases are.
>
> I want to add another question: what will the judgement process be like?
> Will it be an open discussion on this list, or will it be decided behind
> closed doors by the committee, and we just get to hear the results?
>
> While there might be no plans regarding this as of now, I'd _really_
> like an open discussion regarding these issues that arise in the future,
> rather than it being decided behind closed doors with us regular old
> contributors getting no say in it. A closed discussion would be much
> more prone to power abuse, if any.
>
>> I'm okay with leaving it open for now but I think I would be a lot more
>> comfortable if we had the interpretations document to close up the
>> vagueness later.

Re: [PATCH] add a Code of Conduct document

[Jeff King]

On Wed, Sep 25, 2019 at 01:35:33AM +0530, Pratyush Yadav wrote:

> > As I said above, I couldn't find a public list of the people who were on
> > the project committee. Perhaps that's because my Googling skills are bad
> > but I feel uncomfortable knowing that *anyone* will be given judge, jury
> > and executioner power, let alone people whom I don't know anything
> > about.
>  
> I agree with this. I would certainly like to know who the people who 
> will judge these cases are.

See my other reply to Denton for details here.

> I want to add another question: what will the judgement process be like? 
> Will it be an open discussion on this list, or will it be decided behind 
> closed doors by the committee, and we just get to hear the results?

I think we'll have to approach this on a case by case basis to some
degree. If people are having conflict on the mailing list, I'd like to
see it resolved there, too. If somebody is sexually assaulted at the Git
Contributor Summit, that probably needs to be handled with more
discretion.

Keep in mind that a lot of this isn't changing the status quo. When we
had a problem on the mailing list in the past, it was discussed on the
list _and_ in private. And ultimately decisions came down to the
maintainer: am I going to start ignoring this person's patches, or will
I continue to encourage them to interact with the project even though
they're causing problems.

So I think a lot of this is really just writing down the current
practice.

> While there might be no plans regarding this as of now, I'd _really_ 
> like an open discussion regarding these issues that arise in the future, 
> rather than it being decided behind closed doors with us regular old
> contributors getting no say in it. A closed discussion would be much 
> more prone to power abuse, if any.

Yes, I don't like the idea of creating a pseudo-judicial system that has
none of the normal guarantees of rights (like say, facing your accuser
and seeing their evidence). At the same time, I don't want to re-create
a court system (badly). Especially given that most of our enforcement is
pretty "soft" in the first place; i.e., the most we can probably do is
stop interacting with a person, and maybe ask vger admins to block them
from using the list.

-Peff

Re: [PATCH] add a Code of Conduct document

[Jeff King]

On Tue, Sep 24, 2019 at 10:12:14AM -0700, Denton Liu wrote:

> > I've cc'd git@sfconservancy.org here, because I think it's important for
> > all of the project committee members to endorse it (and because the
> > document puts us on the hook for enforcing it!).
> 
> I tried looking it up but I couldn't find who the project committee
> members are. Is this list published anywhere? More on that later...

See:

  https://public-inbox.org/git/20180925215112.GA29627@sigill.intra.peff.net/

The current committee is:

  Junio C Hamano <gitster@pobox.com>
  Jeff King <peff@peff.net>
  Christian Couder <christian.couder@gmail.com>
  Ævar Arnfjörð Bjarmason <avarab@gmail.com>

There's a link there that goes into more detail on how the selection
process works.

> > +* Publishing others' private information, such as a physical or electronic
> > +  address, without explicit permission
> 
> Since this is a mailing list-based project, we should explicitly state
> that email addresses and names don't count as private information since
> it's vital for discourse.

I'd argue that participating in the mailing list means you've given
permission for your address to be public. Ditto including it in a git
commit that gets pushed.

> On that note, I like the idea of having a CoC-interpretations document,
> much like the one in the Linux kernel[1]. In my opinion, having one
> would remove a lot of the vagueness (such as the emails issue) in the
> CoC and close us off from people loophole lawyering over the language
> used.

Yeah, I like the kernel one, as well. I'd rather have an interpretation
document than try to hack up the CoC. It's nice to be able to say "we
use Contributor Covenent 1.4" and have that be a standard across
projects.

> > +Project maintainers have the right and responsibility to remove, edit, or
> > +reject comments, commits, code, wiki edits, issues, and other contributions
> 
> Since we use patches here, we should probably explicitly state that too.

I'd just call that "commits", but I think "other contributions" is a
fine catch-all. Again, I don't mind a clarification document but I'd
prefer not to hack up this CoC for little things like this.

> > +Instances of abusive, harassing, or otherwise unacceptable behavior may be
> > +reported by contacting the project team at git@sfconservancy.org. All
> > +complaints will be reviewed and investigated and will result in a response
> > +that is deemed necessary and appropriate to the circumstances. The project
> > +team is obligated to maintain confidentiality with regard to the reporter of
> > +an incident. Further details of specific enforcement policies may be posted
> > +separately.
> 
> I feel uncomfortable with this being left so wide open. First of all, I
> know that the power *probably* won't be abused but I don't think
> probably is good enough.
> 
> As I said above, I couldn't find a public list of the people who were on
> the project committee. Perhaps that's because my Googling skills are bad
> but I feel uncomfortable knowing that *anyone* will be given judge, jury
> and executioner power, let alone people whom I don't know anything
> about.
> 
> I'm okay with leaving it open for now but I think I would be a lot more
> comfortable if we had the interpretations document to close up the
> vagueness later.

In general the project committee tries to involve the larger community
on the list where possible. So I think if there were, say, a discussion
about list behavior, I'd expect it to happen on the list. But I think we
do need a semi-private reporting mechanism:

  - some issues may involve details that the reporter wishes to keep
    public (e.g,. a harasser follows somebody to a non-mailing-list
    venue like Twitter, but the harassed person doesn't want to publicly
    announce their Twitter handle; you can imagine even more extreme
    cases of details somebody doesn't want to make public).

  - people may want to report problems pseudo-anonymously because they
    fear retaliation. I think this gets into a grey area of facing your
    accuser, but it seems like there needs to be a private mechanism to
    at least make initial contact (e.g., not to deliver one-sided
    evidence, but to draw the committee's attention to a particular
    already-public thread).

-Peff

Re: [PATCH] add a Code of Conduct document

[Emily Shaffer]

> > I've cc'd git@sfconservancy.org here, because I think it's important for
> > all of the project committee members to endorse it (and because the
> > document puts us on the hook for enforcing it!).
>
> I tried looking it up but I couldn't find who the project committee
> members are. Is this list published anywhere? More on that later...

To be honest, I'm a little worried about it too. What if I have a
problem with someone on the project committee? What if I have a
problem with someone I don't know is on the project committee?

I helped my other FOSS project to adopt a Code of Conduct earlier in
the year (https://github.com/openbmc/docs/blob/master/code-of-conduct.md)
and we got around this by asking for volunteers from the technical
steering committee to agree to have their contact info listed on the
escalation path; at the end of the escalation path we also listed
someone external to the project (which we were able to do because we
had been adopted by the Linux Foundation, and they have someone for
that).

A possible con of being on this escalation path is having your name
and contact info outed to trolls as a supporter of something
controversial like a code of conduct. However, I'd argue that the
growing list of ACKs on this thread expose us in a similar way. On the
other side, the benefit of having a transparent escalation path like
this is that you can bypass a problematic individual who may be in a
position of power. It also provides an opportunity for increased
discretion in delicate situations like the example Peff gave
downthread.

[snip...]

While I'd feel more comfortable with a "menu" of folks I could
escalate a concern to in private, I otherwise like this document and
agree with sentiment elsewhere in the list that it will not change the
way the project behaves now - only write down the current state. ACK
from me.

[PATCH] CODE_OF_CONDUCT: mention individual project-leader emails

[Jeff King]

On Tue, Sep 24, 2019 at 04:52:56PM -0700, Emily Shaffer wrote:

> > > I've cc'd git@sfconservancy.org here, because I think it's important for
> > > all of the project committee members to endorse it (and because the
> > > document puts us on the hook for enforcing it!).
> >
> > I tried looking it up but I couldn't find who the project committee
> > members are. Is this list published anywhere? More on that later...
> 
> To be honest, I'm a little worried about it too. What if I have a
> problem with someone on the project committee? What if I have a
> problem with someone I don't know is on the project committee?

I think those are very good points. See the patch below.

> I helped my other FOSS project to adopt a Code of Conduct earlier in
> the year (https://github.com/openbmc/docs/blob/master/code-of-conduct.md)
> and we got around this by asking for volunteers from the technical
> steering committee to agree to have their contact info listed on the
> escalation path; at the end of the escalation path we also listed
> someone external to the project (which we were able to do because we
> had been adopted by the Linux Foundation, and they have someone for
> that).

Yeah, I think this is sort of the same thing except that I
pre-volunteered the whole project committee. ;)

We could have a separate list of contacts for the code of conduct, but
it seems simplest to just use the existing group that we already have,
unless there's a compelling reason not to.

> A possible con of being on this escalation path is having your name
> and contact info outed to trolls as a supporter of something
> controversial like a code of conduct. However, I'd argue that the
> growing list of ACKs on this thread expose us in a similar way. On the
> other side, the benefit of having a transparent escalation path like
> this is that you can bypass a problematic individual who may be in a
> position of power. It also provides an opportunity for increased
> discretion in delicate situations like the example Peff gave
> downthread.

Yep, agreed with all of this.

So here's a patch that I think improves the situation.

-- >8 --
Subject: [PATCH] CODE_OF_CONDUCT: mention individual project-leader emails

It's possible that somebody on the project committee is the subject of a
complaint. In that case, it may be useful to be able to contact the
other members individually, so let's make it clear that's an option.

This also serves to enumerate the set of people on the committee. That
lets you easily _know_ if you're in the situation mentioned above. And
it's just convenient to list who's involved in the process, since the
project committee list is not anywhere else in the repository.

Signed-off-by: Jeff King <peff@peff.net>
---
 CODE_OF_CONDUCT.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index b94f72b0b8..fc4645d5c0 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -74,6 +74,14 @@ Project maintainers who do not follow or enforce the Code of Conduct in good
 faith may face temporary or permanent repercussions as determined by other
 members of the project's leadership.
 
+The project leadership team can be contacted by email as a whole at
+git@sfconservancy.org, or individually:
+
+  - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
+  - Christian Couder <christian.couder@gmail.com>
+  - Jeff King <peff@peff.net>
+  - Junio C Hamano <gitster@pobox.com>
+
 ## Attribution
 
 This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-- 
2.23.0.765.g1fc3e247e7

Re: [PATCH] CODE_OF_CONDUCT: mention individual project-leader emails

[Derrick Stolee]

On 9/26/2019 3:20 AM, Jeff King wrote:
> On Tue, Sep 24, 2019 at 04:52:56PM -0700, Emily Shaffer wrote:
> 
>>>> I've cc'd git@sfconservancy.org here, because I think it's important for
>>>> all of the project committee members to endorse it (and because the
>>>> document puts us on the hook for enforcing it!).
>>>
>>> I tried looking it up but I couldn't find who the project committee
>>> members are. Is this list published anywhere? More on that later...
>>
>> To be honest, I'm a little worried about it too. What if I have a
>> problem with someone on the project committee? What if I have a
>> problem with someone I don't know is on the project committee?
> 
> I think those are very good points. See the patch below.
> 
>> I helped my other FOSS project to adopt a Code of Conduct earlier in
>> the year (https://github.com/openbmc/docs/blob/master/code-of-conduct.md)
>> and we got around this by asking for volunteers from the technical
>> steering committee to agree to have their contact info listed on the
>> escalation path; at the end of the escalation path we also listed
>> someone external to the project (which we were able to do because we
>> had been adopted by the Linux Foundation, and they have someone for
>> that).
> 
> Yeah, I think this is sort of the same thing except that I
> pre-volunteered the whole project committee. ;)
> 
> We could have a separate list of contacts for the code of conduct, but
> it seems simplest to just use the existing group that we already have,
> unless there's a compelling reason not to.
> 
>> A possible con of being on this escalation path is having your name
>> and contact info outed to trolls as a supporter of something
>> controversial like a code of conduct. However, I'd argue that the
>> growing list of ACKs on this thread expose us in a similar way. On the
>> other side, the benefit of having a transparent escalation path like
>> this is that you can bypass a problematic individual who may be in a
>> position of power. It also provides an opportunity for increased
>> discretion in delicate situations like the example Peff gave
>> downthread.
> 
> Yep, agreed with all of this.
> 
> So here's a patch that I think improves the situation.
> 
> -- >8 --
> Subject: [PATCH] CODE_OF_CONDUCT: mention individual project-leader emails
> 
> It's possible that somebody on the project committee is the subject of a
> complaint. In that case, it may be useful to be able to contact the
> other members individually, so let's make it clear that's an option.
> 
> This also serves to enumerate the set of people on the committee. That
> lets you easily _know_ if you're in the situation mentioned above. And
> it's just convenient to list who's involved in the process, since the
> project committee list is not anywhere else in the repository.

I think this handles the conflict of interest issues. This is likely
never to be needed, but helpful to have.

Thanks,
-Stolee

> 
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  CODE_OF_CONDUCT.md | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
> index b94f72b0b8..fc4645d5c0 100644
> --- a/CODE_OF_CONDUCT.md
> +++ b/CODE_OF_CONDUCT.md
> @@ -74,6 +74,14 @@ Project maintainers who do not follow or enforce the Code of Conduct in good
>  faith may face temporary or permanent repercussions as determined by other
>  members of the project's leadership.
>  
> +The project leadership team can be contacted by email as a whole at
> +git@sfconservancy.org, or individually:
> +
> +  - Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> +  - Christian Couder <christian.couder@gmail.com>
> +  - Jeff King <peff@peff.net>
> +  - Junio C Hamano <gitster@pobox.com>
> +
>  ## Attribution
>  
>  This Code of Conduct is adapted from the [Contributor Covenant][homepage],
> 

Re: [PATCH] CODE_OF_CONDUCT: mention individual project-leader emails

[Emily Shaffer]

On Thu, Sep 26, 2019 at 03:20:46AM -0400, Jeff King wrote:
> So here's a patch that I think improves the situation.

Looks great to me and addresses my only concern with the original patch.
Hearty ACK.

 - Emily

Re: [PATCH] CODE_OF_CONDUCT: mention individual project-leader emails

[CB Bailey]

On 26/09/2019 08:20, Jeff King wrote:
> On Tue, Sep 24, 2019 at 04:52:56PM -0700, Emily Shaffer wrote:
>> I helped my other FOSS project to adopt a Code of Conduct earlier in
>> the year (https://github.com/openbmc/docs/blob/master/code-of-conduct.md)
>> and we got around this by asking for volunteers from the technical
>> steering committee to agree to have their contact info listed on the
>> escalation path; at the end of the escalation path we also listed
>> someone external to the project (which we were able to do because we
>> had been adopted by the Linux Foundation, and they have someone for
>> that).
> 
> Yeah, I think this is sort of the same thing except that I
> pre-volunteered the whole project committee. ;)
> 
> We could have a separate list of contacts for the code of conduct, but
> it seems simplest to just use the existing group that we already have,
> unless there's a compelling reason not to.

I, too, wondered if it might be more appropriate to have the list of
names and email addresses separated from the repository and just linked
from the CoC. Perhaps someone would need to expunge themselves from the
list permanently, or perhaps we'd want to protect against a hypothetical
person in a position of control changing the list to their trusted
cronies. I cannot think of a realistic scenario or practical setup which
would actually guarantee any such benefits and this solution is simple
and practical.

Overall for this proposed CoC patch: ACK

CB

Re: [PATCH] add a Code of Conduct document

[Jonathan Tan]

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

Thanks for starting this. I think Peff has stated better what I would have
said, so to this patch:

Acked-by: Jonathan Tan <jonathantanmy@google.com>

Re: [PATCH] add a Code of Conduct document

[Thomas Gummerer]

On 09/24, 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:
> 
>   https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
> 
> 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.
> 
> Signed-off-by: Jeff King <peff@peff.net>

I don't have much to add to this, the commit message spells out all
the reasons why we should have this nicely and I wholeheartedly agree
with introducing it, and choosing the Contributor Covenant as our
template.  So I'm adding my ACK to the others that have been coming in
already.  Thanks for submitting this!

Re: [PATCH] add a Code of Conduct document

[René Scharfe]

Am 24.09.19 um 08:44 schrieb Jeff King:> +Examples of unacceptable behavior by participants include:> +> +* The use of sexualized language or imagery and unwelcome sexual attention or> +  advances
Sure.

> +* Trolling, insulting/derogatory comments, and personal or political attacks

Hmm.  Trolling can be helpful, if done right.  I consider this to be a
good example: https://git-man-page-generator.lokaltog.net/.  Wrote some
texts that look like that..

I don't mind insults.  Perhaps that's a cultural thing.  I don't
necessarily need them, though.

"Personal and political attacks" sound really scary and don't seem to
match trolling and insulting in severity.  Perhaps I don't understand
the intended meaning.  In any case, I also wouldn't want anyone to be
beaten up or swatted, get a lower social credit score or be forced out
of public office over participation in our project.

> +* Public or private harassment

Right.

> +* Publishing others' private information, such as a physical or electronic
> +  address, without explicit permission

Good.

> +* Other conduct which could reasonably be considered inappropriate in a
> +  professional setting

This is very vague.  It could match eating at your desk, tipping, not
tipping, not wearing a tie, or talking back to a senior developer.

René

Re: [PATCH] add a Code of Conduct document

[Jeff King]

On Tue, Sep 24, 2019 at 10:14:55PM +0200, René Scharfe wrote:

> > +* Trolling, insulting/derogatory comments, and personal or political attacks
> 
> Hmm.  Trolling can be helpful, if done right.  I consider this to be a
> good example: https://git-man-page-generator.lokaltog.net/.  Wrote some
> texts that look like that..

I suppose one man's joke is another man's troll. Is the manpage
generator too mean? I don't think so (I think it's quite funny). I guess
somebody could. But at some point all of these terms are open to
interpretation, and we're going to have to rely on discussion and
precedent.

I don't think step 1 would ever be "report the manpage generator to the
committee, and get it banned!". For one thing, we have no control over
their domain, and it really exists outside of our development community.
So at most we say "yeah, we don't like that; please don't". But more
importantly, I think step 1 is somebody saying "hey, this kind of seems
in poor taste", and then we all have a discussion about it.

> "Personal and political attacks" sound really scary and don't seem to
> match trolling and insulting in severity.  Perhaps I don't understand
> the intended meaning.  In any case, I also wouldn't want anyone to be
> beaten up or swatted, get a lower social credit score or be forced out
> of public office over participation in our project.

I take political attacks to be things like "Everyone from Country X is a
moron", or "People who support political party X are jerks". You might
even have a legitimate complaint about somebody's politics, but if
they're not bringing their politics into the project, it seems wrong to
attack them over it.

I do think there's some grey area there, though, because there _is_ some
intersection of politics (e.g., a discussion about licensing could
easily get into discussion of laws and IP). But if people are talking
constructively about it, and not attacks like "the party you support has
a dumb interpretation of the GPL", that seems fine to me.

Again, I really think the point here is not to enumerate all
possibilities. It's to set some general expectations, and to make it
clear that we value the idea of having a genial atmosphere for
communication that we have a document and a reporting mechanism.

> > +* Other conduct which could reasonably be considered inappropriate in a
> > +  professional setting
> 
> This is very vague.  It could match eating at your desk, tipping, not
> tipping, not wearing a tie, or talking back to a senior developer.

Here I'd go back to "discussion and precedent" from above. Community
norms are a moving target to some degree. Wearing a tie was
unprofessional at one point, and now that is very much not the case, at
least in the programming profession. I think we have to stay somewhat
vague and rely on the social interactions of the community to resolve
things (and again, this is more or less what the status quo is; the
document is mostly a commitment from project leadership to take
seriously discussion and complains about behavior within the project).

-Peff

Re: [PATCH] add a Code of Conduct document

[Johannes Schindelin]

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

Hi,

On Tue, 24 Sep 2019, Jeff King wrote:

> On Tue, Sep 24, 2019 at 10:14:55PM +0200, René Scharfe wrote:
>
> > > +* Trolling, insulting/derogatory comments, and personal or
> > > political attacks
> >
> > Hmm.  Trolling can be helpful, if done right.  I consider this to be
> > a good example: https://git-man-page-generator.lokaltog.net/.  Wrote
> > some texts that look like that..
>
> I suppose one man's joke is another man's troll. [...]

And we could now try to dive into that rabbit hole and discuss every
detail about it, but...

> [...]
>
> Again, I really think the point here is not to enumerate all
> possibilities. It's to set some general expectations, and to make it
> clear that we value the idea of having a genial atmosphere for
> communication that we have a document and a reporting mechanism.

This is a very important point. No CoC can be complete, ever, just like
Git will probably never be complete.

The proposed solution is to give power to a committee of trusted members
of the Git developer community. The key word here is _trust_. I don't
think there can be any doubt that Junio, Peff, Christian and Ævar have
earned the trust of the Git developer community.

For those two reasons, I am totally fine with leaving mostly
hypothetical scenarios a little vague. Because I trust that committee.

Ciao,
Dscho

Re: [PATCH] add a Code of Conduct document

[brian m. carlson]

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

On 2019-09-24 at 06:44:54, 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

I wholeheartedly agree with this assessment.

> 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've already mentioned that I think this is a good idea, and I
appreciate your thorough rationale in the commit message.

Acked-by: brian m. carlson <sandals@crustytoothpaste.net>
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]

Re: [PATCH] add a Code of Conduct document

[Elijah Newren]

On Wed, Sep 25, 2019 at 5:42 PM Jeff King <peff@peff.net> 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:
>
>   https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
>
> 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.
>
> 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
>
> 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.

Acked-by: Elijah Newren <newren@gmail.com>

(including the small update you sent elsewhere to individually list
the members of project leader team.)