patchadd a Code of Conduct document

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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