How to contribute

PyTorch is a large project (134K+ commits, 8K+ unique committers in the last 6 months) with a serious review process. This section is the contributor-orientation handbook; the canonical document is CONTRIBUTING.md in the repo root, which is over 60K lines.

Page	What it is
Development workflow	Branch, code, test, PR, merge
Testing	Frameworks, patterns, how to run, mock, and cover
Debugging	Logs, gdb/lldb, common errors, troubleshooting
Patterns and conventions	Coding style, error handling, common idioms
Tooling	spin, lintrunner, CI, codegen

At a glance

1. Read CONTRIBUTING.md once, end to end. You will refer back to it.
2. Pick an issue labelled module: ... and triaged. The "good first issue" label exists; it has a backlog.
3. Build PyTorch from source per Getting started: pip install -e . -v --no-build-isolation.
4. Make your change; run the relevant test subset; run spin lint.
5. Open a PR. Github Actions runs CI across many platforms. The PR template prompts you for the right metadata.
6. A reviewer from CODEOWNERS will be tagged automatically. Iterate.
7. The merge bot lands the change once trunk CI is green.

Conventions in CLAUDE.md / AGENTS.md

The repo's CLAUDE.md and AGENTS.md (which are symlinks to the same file) are the canonical short list of conventions. Highlights:

• Build: pip install -e . -v --no-build-isolation. Don't run cmake or python setup.py install directly.
• Tests: use torch.testing._internal.common_utils.TestCase and run_tests; use assertEqual, @parametrize, and instantiate_device_type_tests.
• Lint: use spin lint and spin fixlint.
• Code style: minimize comments; prefer self-documenting code; clear abstractions; explicit state management; no dynamic setattr/getattr.
• No print debugging. Use torch._logging.trace_structured for production-friendly logs and tlparse to parse them.
• Don't commit unless asked.
• ghstack is the preferred stacked-PR tool inside Meta. External contributors can use the regular GitHub PR flow.

Pull request lifecycle

graph LR
    Fork[Fork + branch] --> Code[Code + test]
    Code --> Lint[spin lint]
    Lint --> PR[Open PR]
    PR --> CI[GHA CI]
    CI --> Review[Code review]
    Review -->|changes| Code
    Review -->|approved| MergeQueue[Merge queue / merge bot]
    MergeQueue --> Trunk[Lands on main]

CI labels (ciflow/inductor, ciflow/trunk, ciflow/binaries, ciflow/rocm-mi300, …) opt PRs into specific test sets. The pytorch-bot automation responds to comments to retrigger jobs and merge.

Module ownership

CODEOWNERS lists owners per directory. Owners are subscribed for notifications and review nudges; they are not strictly required to approve. The relevant modules:

• /torch/autograd/, /tools/autograd/, /torch/csrc/autograd/ → albanD, soulitzer
• /torch/nn/ → albanD, jbschlosser, mikaylagawarecki
• /torch/optim/ → albanD, janeyx99
• /aten/src/ATen/native/quantized/ → jerryzh168 et al.
• /torch/distributed/_composable/fsdp/ → weifengpy
• /torch/onnx/, /test/onnx/ → titaiwangms, xadupre, justinchuby
• /aten/src/ATen/cuda/, /torch/cuda/ → eqy, syed-ahmed, Aidyn-A
• /aten/src/ATen/mps/, /torch/mps/ → malfet
• /aten/src/ATen/native/sparse/ → amjames, pearu, nikitaved

Full list: see Maintainers.

Where to read next

• Development workflow — concrete day-to-day commands.
• Testing — the test idioms.
• Patterns and conventions — style.