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.

The scorecard

From GitHub’s community profile for the public repositories. Synced on 3 September 2026, across 26 public repositories.

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

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

The issue template field is unreliable

molo scores 100 with its issue template field empty. Its issue templates are separate files under .github/ISSUE_TEMPLATE/, and that field names a single file, so it comes back blank. The health percentage counts the directory that the field does not report. Read the repository before trusting the field.

When CONTRIBUTING earns its place

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.

The rest of molo’s CONTRIBUTING is the same shape. The commands that get a working copy running, the one command to run before opening a pull request (.venv/bin/python -m 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.

The code of conduct

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. It ships where there is a place for a conversation to happen and a decision to make about it.

A minimal template

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.

What is owed to each repository

Every repository keeps a README, a license and a description. That is already true for all of them, 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.

claude-codex-bridge carries a CONTRIBUTING that its README never links to, so the file is there and nothing points to it.

nerln/molo on GitHubThe CONTRIBUTING, code of conduct, pull request template and issue templates described above. MIT.