Add a copy of the Contributor Covenant CoC text

[eemeli]

This adds a copy of the text of the Contributor Covenant, version 1.4, to our CODE_OF_CONDUCT.md document. The primary reason for this is to make it clear exactly what text we're using, as the language of the upstream "version 1.4.1" has had a few modifications made to it since its release in April 2017, without an accompanying version number change.

Regarding the text itself, I've taken the contents from the current HEAD commit, and filled in the [INSERT EMAIL ADDRESS] bit in its Enforcement section with "the email addresses listed above in the Reporting and Escalation sections".

I've also added a second github.com link for the translations, as with the recent release of the Contributor Covenant CoC version 2.0 it's likely that the links at https://www.contributor-covenant.org/translations will soon start to get updated to its translations.

Edit: See comment below for refactored contents.

Edit: Never mind the previous edit. See comment below.

[ljharb]

I would prefer linking to the commit sha on github rather than creating a duplicate source of truth. The modifications you link to are largely editorial, and the others are arguably fixing an omission, and all seem like changes we'd accept without controversy - but either way, linking to a sha should achieve the same "pinning" affect without redundancy.

[mhdawson]

I'd lean towards avoiding having a duplicate copy that we need to maintain as well. Let's discuss in the meeting today.

[mcollina]

LGTM

[eemeli]

Refactored based on feedback here & in today's CPC meeting to drop the inlined text, and to add a link using a git sha instead (as suggested by @ljharb). Also fixed the CoC governance doc link to point to its current stage-2 status.

[bnb]

I'd just like to echo my -1 on removing the full text from our source control. There is distinct value in having it directly available as a committed part of the culture our collective organizations, and I'm sad we're shifting that responsibility out to other people.

A few additional points to address the reasons that I've seen for doing so:

• Translations: When this came up in a previous meeting, I created an issue to see if we could get translations embedded in the CoC itself rather than having to go to a website to do so. Coraline asserted she'd add it: Suggested Avenue for Linking Translated Versions EthicalSource/contributor_covenant#725 (comment)
• Org-wide maintenance: GitHub has a feature where if you add a .github repo to your organization, it will apply community health files including CODE_OF_CONDUCT, CONTRIBUTING, SUPPORT, ISSUE_TEMPLATE(S), and PULL_REQUEST_TEMPLATE to all repos. I just did this in my cutenode org, for example. You can see the official blog post discussing this for more details. Additionally, I just added this to my personal org if you want to see an implementation.

Additionally, I'd argue that we're not pointing to a "duplicate copy". We're not creating a copy, we're creating our Code of Conduct. The source is a template meant to be filled out with your specific data – as evidenced by the inclusion of [INSERT CONTACT METHOD] and this quote from the homepage:

We recommend that you add the Markdown or text version of the Contributor Covenant to your source code repository at the root level.

By using the template as a source of truth rather than customizing it as it's intended, we're making our entire process more complex than is ultimately necessary.

For someone who is coming to see our Code of Conduct, they will have to context switch between the linked template and our additional context in the CODE_OF_CONDUCT.md file. This is an unnecessary complication for a utility that should be as straightforward and simple as possible.

Finally, if updating is a concern, simply using the (official) tool that Contributor Covenant provides to automatically generate contributor covenants would be a straightforward and officially supported solution. Here's the command(s) we'd need to use:

# using npx
npx covgen report@lists.openjsf.org

# OR if you want to install locally
npm i -g covgen
covgen report@lists.openjsf.org

# OR if you want to use yarn
yarn add global covgen
covgen report@lists.openjsf.org

[bnb]

I would also like to assert that instead of trying to hack our way around using the Contributor Covenant at scale, we instead try to contribute changes back to ensure that others get the utility we're trying to achieve and improve the Code of Conduct for everyone ❤️

[mhdawson]

I would also like to assert that instead of trying to hack our way around using the Contributor Covenant at scale, we instead try to contribute changes back to ensure that others get the utility we're trying to achieve and improve the Code of Conduct for everyone heart

+1

I wonder if one option is asking for a version of the Contributor Covenant that makes using it as a link more friendly. This only makes sense if we value not having to update/copy versus maintaining a copy and having to update it everywhere. I can see a few options to discuss/explore:

1. Having every project have their own copy, maximum work to keep updated but no external dependency.
2. Having a copy in the CPC repo, projects link to that, reduced work to keep updated, also lessens dependency on an external link.
3. Use link everywhere including CPC repo. Minor reduction in work over 2) and full dependency on external link.

Any other we might/should consider/discuss?

[bnb]

I'd like to continue to assert that I'm a -1 on linking. I see little value with increased cost in terms of community.

I'm additionally unconvinced of a maintenance burden, as this could be automated by simply building a GitHub Action that automatically submits a PR every time there's a new version published. I would be willing to do this work if folks were open to the possibility of adopting it.

[knolleary]

As a project maintainer, I would prefer to have a copy of the coc text in our repo to reaffirm our commitment to it. I think it is a healthy chore to have to maintain it as it ensures project maintainers are aware of changes. If we just pointed a link to an openjs repo that could change what it pointed to, there would be nothing at the project level to highlight the fact a change had happened.

[ljharb]

By pointing to a SHA instead of a branch, a change won't happen without explicit action, which then can be reviewed - it need not be inline for that.

[mhdawson]

The main drawback I see of a copy is the maintenance so if maintainers don't see that as a problem and want a copy then.... Would be great if maintainers, CPC reps of additional projects would chime ion on that front.

[mhdawson]

I'll note that the issue raised related to translations is potentially being addressed by the baseline text including links to the translations. @bnb can you paste the link to the discussion you are having in the Contributor Covenant repo on that topic?

[bnb]

@mhdawson it's linked in my comment above (#413 (comment)), but here it is again: EthicalSource/contributor_covenant#725 (comment)

[eemeli]

Apologies for the messiness, but based on discussions at the collab summit, I've re-rebased this to include the CoC text inline in our repository. I'm also re-requesting reviews from everyone who's approved some version of this.

The point of view that I believe we need to keep in mind here is that of a person who is looking to report an incident, or otherwise needs to consult the CoC. We should make their lives as easy as possible, and provide a minimal number of places to look at and hoops to jump through. Yes, this will require us to apply updates when the upstream changes, but having an explicit track of changes is also a benefit.

[ljharb]

I object to that approach; I don't think an extra click for the bulk of the text is a problem.

We should of course have reporting instructions as inline as possible, but that's not part of the CoC text.

[joesepi]

The Contributor's Covenant requests that you inline the text. https://www.contributor-covenant.org

I think we should move forward with the text inline and we can further evaluate if we see fit in a CoC working group of sorts -- which I think was something we wanted to do based on Collab Summit discussions.

[MylesBorins]

LGTM

[mhdawson]

My main concern in avoiding a copy was extra work and keeping things consistent. Given that people don't seem concerned about extra work and have strong feelings that it should be inline I'm +1 for that as well.

I think we can address any consistency extra work issues through some tooling if they do end up being an issue.

[mhdawson]

LGTM

[joesepi]

As per my comment above: LGTM

[kborchers]

LGTM

[mhdawson]

Discussion today in the CPC meeting clarified that @ljharb prefers a different approach but will not block it going forward. Agreed we should land and any further discussion and be in the planned CoC working sessions.