How to contribute

CPython is one of the older open-source projects still in active development, and the contribution flow has been refined for that reality: many maintainers, slow merges, mandatory tests, and an exhaustive expert index. This section is the in-tree complement to the official Developer's Guide — it focuses on what is true in this checkout (build commands, generators, the test harness) rather than on process.

Where to start

You want to	Read
Build, run tests, install	Getting started
Submit a PR end-to-end	Development workflow
Run, write, and shape the test suite	Testing
Reproduce a crash or wrong-result bug	Debugging
Understand the recurring idioms in the codebase	Patterns and conventions
Use the build system, regenerate generated files	Tooling

The PR loop in one paragraph

Open an issue (or pick one), branch from main, make the change, add or update a Misc/NEWS.d/next/... blurb, run make test for the affected modules, push, open a PR, and wait. CI runs the test suite on Linux, macOS, Windows, WASI, and an instrumented PGO build, plus a JIT-enabled run, plus a free-threaded run. CI failures block merges. Reviewers come from the CODEOWNERS file and the experts index; a "core developer" approval lands the change.

Definition of "done"

A change is ready to merge when:

1. Tests added or updated (rare exceptions: doc-only PRs, no-op refactors).
2. News blurb added under Misc/NEWS.d/next/ for any user-visible change.
3. make patchcheck is clean (Tools/patchcheck/). This runs whitespace/EOL checks, regen-status checks, and reminds you about news entries.
4. make regen-all has been run if you touched a generator input (Grammar/python.gram, Python/bytecodes.c, Parser/Python.asdl, Argument Clinic blocks, …).
5. CI is green on every required check.
6. One or two core devs have signed off (the bot adds reviewers from CODEOWNERS automatically).

The most common pitfalls

• Forgetting make regen-all. If you change Python/bytecodes.c you must commit the regenerated Python/generated_cases.c.h, Python/executor_cases.c.h, Python/optimizer_cases.c.h, and the Include/internal/pycore_* metadata headers. The CI lint job catches this, but it costs a round trip.
• Skipping the news entry. make patchcheck reminds you. Without it the release manager has to scrape the diff to write release notes.
• C ↔ Python parity. Many stdlib modules ship a C implementation in Modules/_*module.c and a pure-Python fallback in Lib/*.py (e.g. _pyio.py, _pydatetime.py). Behavioural changes need to be made in both unless there is a very specific reason not to.
• The reference-counting trap. Every C function that returns a new PyObject* increases its refcount; you must Py_DECREF (or Py_XDECREF for nullable values) when done, including on every error path. See Patterns and conventions.

Process pointers (out-of-tree)

• Developer's Guide — the canonical process doc.
• Experts Index — who to ping for which subsystem (mirrors .github/CODEOWNERS).
• PEPs — language-level proposals; large feature work always starts here.
• discuss.python.org — design discussion.