contributor_covenant: the document projects copy, and the builder being written to replace it

The default branch is not the document most projects use

This is the first thing to sort out, because the repository presents two different things. The README on the default branch opens with the words Contributor Covenant 3 and immediately describes itself as the working repository for a new Contributor Covenant builder. That is a web application under construction, not the covenant text.

Meanwhile the published releases are versions of the document: 2.1, 2.0 and 1.4. Version 2.1 was published on 2021-08-04 and its release note is a single sentence about the preamble. Version 2.0 came on 2020-06-25 with an empty body, and 1.4 on 2016-01-30, also empty.

So if you arrive looking for a code of conduct template, the newest thing you can actually adopt is 2.1, and it is five years old as a release. If you arrive curious about how the project intends to deliver the next version, the README checklist is the document to read. Both are in the same repository on the same branch, which is a genuine source of confusion rather than a subtlety.

The homepage is contributor-covenant.org, and the repository topics list codeofconduct, diversity, inclusivity and translations, which tells you the translations effort has been a substantial part of the project's life.

What version 2.1 actually changed, in one sentence

The release note for 2.1 says it adds caste and color to the preamble. That is the whole change, and it is worth understanding what it signals.

The preamble is the Our Pledge section, the part of the document a contributor reads first and the part that has to survive being quoted out of context. Adding two categories to it is not a cosmetic edit. It means the pledge language acknowledges forms of discrimination that a Western-default list had left implicit, and it happens in the sentence most likely to be quoted on a project website, a conference page or a hiring post.

That single-sentence release history is also a useful corrective to the assumption that a governance document needs long change logs. A code of conduct that only changes when its language is deliberately revised is arguably better behaved than one that accumulates clarifications nobody reads.

What you do not get from the release notes is any guidance on enforcement, which is the part that actually determines whether a code of conduct helps. For that, the repository has a separate `CODE_OF_CONDUCT.md`, and the covenant document itself has an enforcement section with an enforcement contact, which is the field every adopting project must fill in.

The third version is a configurable document generator, not a single file

The builder concept is laid out as a requirements checklist on the README, and the most interesting item is the idea of modules.

The stated concept is that there will be different modules for different use cases, with an event and an open source community named as the examples, and different chunks of text per context. The module list splits into common elements and modular sections. Common: the preamble, and the rest of the document. Modular: Standards, Enforcement, and Enforcement Guidelines.

That split is the design decision with consequences. A single static file forces every project to carry text irrelevant to it, such as event-specific standards in a permanent community code of conduct. Modular composition lets the enforcement section differ, and the README notes that Enforcement takes form input from the user, so the generated document is personalised at generation time rather than at adoption time.

The other checklist items are less abstract. There is a requirement to start from scratch using prior art from an HL3 builder, a requirement to keep JavaScript minimal for accessibility reasons and maintenance, a wireframe that exists as an issue, and a requirement that a mailer form use the adopting project's URL to update the adopters list. The last item means the tool is meant to maintain the registry of which projects have adopted the covenant, which is the mechanism that makes a network of adopters visible.

Building the site locally takes Hugo and one command

The development instructions are short and depend on one prerequisite. Hugo has to be installed first, using whatever package manager you already have. On Debian and Ubuntu:

apt-get install hugo

On Arch Linux:

pacman -S hugo

On macOS with Homebrew:

brew install hugo

Then, from the repository root:

hugo server -D

The `-D` flag builds drafts, which is necessary here because the builder's wireframe and the version 3 content are both still in progress. Without it you get a site with the sections that are finished and nothing else, which is a confusing first experience on a repository whose visible work is unfinished.

The repository layout is a standard Hugo site: `hugo.toml` for configuration, `content/` for Markdown, `layouts/` for templates, `data/` for structured content, `assets/` and `static/` for assets, plus a `changelog` directory. There is a `.netlify.toml`, which indicates the site deploys through Netlify rather than through GitHub Pages.

Accessibility rules written as contribution requirements

The Code Style section is short and unusually specific for a governance project, and it is the part of the README with the most engineering content.

The general rules are to use spaces for indentation and to order properties alphabetically. Then there are three language-specific groups.

For HTML: include an `alt` attribute for all images and a `title` attribute for all links. For CSS: prefer classes over IDs unless something is absolutely unique, one selector per line, use `rem` over `em` or `px`, capitalize hexadecimal, and maintain contrast to WCAG AA on normal text and WCAG AAA on large text. For Markdown: do not use fancy quotes and dashes, since the Markdown processor handles that.

That last rule deserves a note. It is an explicit instruction to let the renderer produce typographic punctuation, which is the opposite of what many text guides tell you to do when they ask for straight quotes in source. It also explains why this article has no curly punctuation conventions to argue about.

The contrast rule is the substantive one, and pairing AA for normal text with AAA for large text is stricter than the AA baseline most sites target. Combined with the requirement to keep JavaScript minimal, these rules are accessibility requirements expressed as a contribution gate, which is a mechanism that actually holds. A policy document asking for accessibility changes nothing; a pull request that fails review for a contrast ratio does.

Governance files, licensing, and what a project actually needs

Beyond the README, the repository carries `GOVERNANCE.md`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and `LICENSE.md`. A project whose subject is community process maintaining its own governance documentation is not surprising, but the presence of all four in one repository is a reasonable model for what a code of conduct repository should look like.

The licence field on the repository is not declared. That is a real consideration for anyone who wants to modify the covenant text itself. Copyright law's default means you can read and quote it, including quoting it in your own project, but the permission to adapt and redistribute a modified version is not granted by the absence of a licence. Copying the text verbatim into your repository is what almost everyone does and is clearly fine. Forking it into your own variant is a different question, and `LICENSE.md` is the file to read before you answer it.

The practical list for an adopting project is short. Copy version 2.1's text into a `CODE_OF_CONDUCT.md` at the root of your repository, replace the enforcement contact placeholder with someone who will actually answer, and confirm that the address in the document is monitored. The translation effort that the repository's topics advertise matters more than it first appears, because a code of conduct written only in the language of the project leads means the people most likely to need it are the least able to use it.

Editorial conclusion

For most projects the practical question is settled: adopt Contributor Covenant 2.1, published on 2021-08-04, copy it into your own repository, and point your enforcement contact at a human being. That release is the newest published version even though the repository's default branch is working on a third version, which means if you were expecting a 3.0 to copy today, there is nothing to copy. The interesting engineering is in that unreleased work: a Hugo site with modular document sections, an enforcement form that captures the adopting project, and accessibility rules written into the contribution guide as contrast targets rather than aspirations. If you want to influence it, the README points at a wireframe issue and an open source contribution is the obvious route. The last push was on 2026-05-20 and the project is hosted at contributor-covenant.org.

Frequently asked questions

Official sources

1. EthicalSource/contributor_covenant on GitHub
2. Issues
3. Project website
4. README
5. Releases