Skip to content

Contributing and conduct

Both files answer a question the source code cannot: what will get a patch rejected, and what happens if a conversation goes badly. The rule applied here is narrow. A CONTRIBUTING file ships when a patch can fail for a reason the reader had no way to guess. A CODE_OF_CONDUCT ships when there is somewhere for a conversation to happen and a decision to make about it.

From GitHub’s community profile for the eleven public repositories, synced 2026-08-04.

File Repositories that have it
README 11 of 11
License 11 of 11
Description 11 of 11
CONTRIBUTING.md 2 of 11: molo, claude-codex-bridge
CODE_OF_CONDUCT.md 1 of 11: molo
Pull request template 1 of 11: molo
Issue template 0 of 11, as reported

The health percentages follow from that row of the table: molo 100, claude-codex-bridge 71, and the other nine at 42.

molo is a local queue for yt-dlp, and it has a limit no contributor would infer from the code: no circumvention code, no CDM modules, no keys, no decryption routines, and no documentation that presents getting past a paywall as a use case. A test enforces it, so a patch that crosses the line fails CI rather than reaching an inbox. Writing that down saves someone a weekend, which is the whole justification for the file.

The rest of molo’s CONTRIBUTING is the same shape. The three commands that get a working copy running, the one command to run before opening a pull request (pytest tests -q), and one instruction about the policy tests: if you find yourself editing them to make a change pass, stop and open an issue, because either the test is wrong or the change is.

Across all eleven repositories there are zero forks and one open issue. A CONTRIBUTING file on a repository nobody has patched documents a process that has never run. It is worth writing anyway when it records a real constraint, and worth skipping when it would only restate git clone.

A code of conduct is a commitment about how the maintainer behaves when a thread gets tense. molo’s fits on one screen and says plainly what gets someone removed. A three thousand word document copied from a template, on a repository with one open issue, is the ceremony version of the same promise.

Four sections cover a single-maintainer project. This is molo’s file with the project-specific parts replaced.

# Contributing
Pull requests are welcome. So are bug reports that say what you expected
and what happened instead.
## The one hard limit
The rule a patch can break without knowing it exists. If a test enforces
it, name the test. If nothing enforces it, say that too.
## Getting set up
git clone <url> && cd <repo>
python3 -m venv .venv && .venv/bin/pip install -e ".[dev]"
## Before opening a pull request
.venv/bin/python -m pytest tests -q
Which tests are load bearing, and what to do when one of them blocks your
change: open an issue instead of editing the test.
## Reporting a bug
Platform, whether the install came from a release or from source, and the
versions of the dependencies that usually turn out to be the cause.

If a project has no hard limit and no test suite, the first and third sections collapse into a sentence in the README and the file is not needed yet.

Every repository keeps a README, a license and a description. That is already true for all eleven, and it is the part checked on every sync.

A repository gets a CONTRIBUTING the first time a patch could fail for a reason that is not already in the README, and that file names the command that runs the checks. Nine of these repositories have not reached that point.

One gap belongs on this page because the page is meant to list them: claude-codex-bridge carries a CONTRIBUTING that its README never links to, so the file is there and nobody arrives at it.