Levels

level sets how much a public repo commits to. Each level adds requirements to the one below it:

• minimal: a public repo with few users. Locked and updated dependencies, hardened workflows, the Scorecard workflow and SECURITY.md.
• standard, the default: every minimal and standard requirement that applies to the repo. The render adds the test policy and coding standards to .github/CONTRIBUTING.md, a ## Usage section to a new render's README, .github/first-release.md with the OpenSSF badge step (OpenSSF badge), and cold-install.yml.
• community: a repo that wants outside contributors. The render adds GOVERNANCE.md, docs/roadmap.md, docs/assurance-case.md and docs/decisions/, and the dco workflow, which every public repo gets, checks every pull request, maintainers' included.

A private repo, or a public one without a license, is not on the ladder: copier skips the question.

To move a project to another level, run copier update --data level=community. An update of a project made before 0.15.0 starts from its old openssf_badge answer: none becomes minimal, passing becomes standard and silver becomes community.

Requirements

A requirement applies to every repo, or only to repos with one of its traits. The template derives the traits from your answers:

The requirements live in levels.toml, and just levels-doc writes the table below from it. A repo meets a level when it meets every requirement that applies to it at that level and below. "Counts from" is the date a requirement starts to count: before then, a tool that reads levels.toml may list it without counting it, which gives repos time to catch up. The file's version is the newest template release, so a repo can say which version of the ladder it meets.

The table says what a repo must have to meet a level, not only what the render adds. Every level also gets the files the template always renders, such as .github/CONTRIBUTING.md, the issue forms and the citation files. The render supplies configuration and checks for the automated requirements. Finish setup, commit the lockfiles and configure repository settings before checking compliance. The review ones need you, and docs-site needs docs_site in extras once its trigger holds.

Levels version 0.15.0:

Checking a repo

just check-level <path> checks a checkout against levels.toml and prints JSON. It reads the level and traits from the repo's .copier-answers.yml. For a repo without one, pass --level standard and a --trait for each trait. From another folder, run uv run <this repo>/scripts/check_level.py <path>. It reads files only: it makes no network calls and runs no tools.

Each requirement gets one status:

• met: the evidence names the files that meet it.
• missing: the evidence says what is missing.
• not_applicable: the requirement is above the repo's level, is for traits the repo lacks, or its condition does not hold, such as lockfile in a repo with no pyproject.toml or package.json.
• unchecked: a person has to judge it (verify = "review"), or the facts are not in the files: the live site's headers, sp-repo-review's results, whether a linked issue is open, release signatures.

{
  "schema_version": 1,
  "repo": "tide-tables",
  "level": "standard",
  "traits": ["numerics"],
  "levels_version": "0.15.0",
  "checked_at": "2027-03-01T09:30:00Z",
  "requirements": [
    {"id": "lockfile", "area": "supply-chain", "level": "minimal", "since": "2026-11-11", "status": "met", "evidence": "uv.lock"}
  ]
}

scripts/check_level.schema.json is the schema. A new field does not change schema_version; a breaking change does. The script exits 0 when it prints a report, whatever the report finds, 2 on a bad flag and 3 when it cannot read the repo or levels.toml.

OpenSSF Best Practices badge

The level prepares a public, licensed repo for a level of the OpenSSF Best Practices badge: standard for passing, community for silver, and minimal for neither.

Levels lists what each level adds. For the badge, the ## Usage section of README.md links the releases and the package registry, with a TODO for what the software does and how to use it. The dco-signoff commit-msg hook (git commit -s) comes with every public render.

The template supplies the files and settings for the passing criteria. Registration still needs evidence from the project and its maintainer. sourceledger, generated from v0.13.0, earned the passing badge on 10 November 2026. Its assessment records the criterion answers, evidence links and maintainer attestations that the render cannot supply; the badge was then added to its README. A fresh render still needs its own assessment.

Before you register

1. Push the repository to GitHub and run just repo-settings. It protects main against direct pushes and deletion, and turns on secret scanning with push protection, private vulnerability reporting and CodeQL default setup.
2. Replace the TODO in the README's ## Usage section. Say what the software does and the problem it solves, then show its basic use.
3. Write doc comments for the public API. They are its reference documentation. In Python, ruff's D rules ask for them.
4. Turn on two-factor authentication for your GitHub account. For a repository in an organization, also require it under the organization's Settings > Authentication security.
5. Make a release with just release X.Y.Z. Its notes are the CHANGELOG section for that version.

Register

1. Open https://www.bestpractices.dev/en/projects/new and log in with GitHub.
2. Under "Select a GitHub repository", pick the repository. Both URL fields take https://github.com/OWNER/REPO, unless the project has a home page of its own.
3. Under "Badge series", pick "metal" for passing and silver, or "baseline" for OSPS Baseline level 1. Then select "Submit Project".
4. Answer the criteria. bestpractices.dev fills in some from the repository. Give the file as the URL where a criterion asks for one.

The render cannot answer these for you:

• know_secure_design and know_common_errors: a primary developer knows secure design and the common kinds of vulnerability for this kind of software.
• maintained, report_responses and enhancement_responses: you reply to issues. .github/CONTRIBUTING.md promises a reply within about two weeks.
• vulnerability_report_response: you reply to a vulnerability report within 14 days, as .github/SECURITY.md promises.
• tests_are_added, warnings_fixed, static_analysis_fixed, vulnerabilities_fixed_60_days and dynamic_analysis_fixed: the project's history shows it.
• dynamic_analysis (suggested): property in extras adds property tests.

Add the badge to README.md once bestpractices.dev awards it.

OSPS Baseline level 1

Where a public render meets each level 1 control of OSPS Baseline v2026.08.28 (level 1 is the same set of controls as in v2026.02.19):

Scientific Python repo-review

A project with the python stack runs sp-repo-review as a git hook. It checks pyproject.toml, the pytest settings, the hooks and the workflows against the Scientific Python development guide, and fails on any check the project has not chosen to skip.

The checks the template skips on purpose are under [tool.repo-review.ignore] in pyproject.toml, each with its reason: just instead of nox, ruff and ty as local hooks, no reStructuredText, no pre-commit.ci. To skip another, add its code and a reason there. Run it on its own with prek run sp-repo-review --all-files.