Contribute to TensorPlay

Start with a reproducible problem, then keep each change clear, tested, and open to discussion.

Ship your first change

01

Fork & clone

Fork the repo, then clone your fork locally.

git clone https://github.com/<you>/TensorPlay.git
cd TensorPlay

02
Branch
One topic per branch keeps review fast.
```
git checkout -b feat/my-change
```
03
Install & build
PEP 517 build via scikit-build-core; MAX_JOBS caps parallelism.
```
pip install -e .
```
04
Test
pytest must pass; flaky tests get the kind/flaky label, not silent reruns.
```
pytest test/
```

01

Conventional Commits

Enforced by tools/commit_schema.py on both the commit-msg hook and PR titles. The PR title becomes the squash-commit subject.

type(scope): subject — subject ≤ 100 chars, no trailing period
feat/fix require a scope; scopes map 1:1 to release-notes labels
Breaking change: append ! and a BREAKING CHANGE: footer

Conventional Commits spec

02

Scopes

Pick the scope that matches where the change lands; the labeler routes release notes from it.

frontend — Python API, Tensor, bindings
autograd — TPX engine, forward-mode AD
compiler — tensorplay.compile, Stax, Triton
kernels — p10 core, CPU kernels
cuda — runtime, streams, graphs, allocator
build / docs — packaging, CI, documentation

03

Code style

Typed Python formatted with black; C++ follows the Google style via clang-format.

Python: PEP 8 + type hints + black
C++: Google C++ Style Guide + clang-format
pre-commit: pip install pre-commit && pre-commit install --hook-type pre-commit --hook-type commit-msg

04

Triage & labels

New issues and PRs start as needs-triage and land on the project board. Milestones bucket work per release.

kind/flaky — intermittent test or build failures
breaking change — must appear in release notes
regression / performance / platform: linux|macos|windows

Entry points

CONTRIBUTING.mdThe full guide in the repo Good first issuesStart here for a first PR DiscussionsDesign questions & proposals feedback@tensorplay.cnPrivate & maintainer-facing