How to contribute

This wiki section captures what a new contributor needs in order to land code in this repo. The canonical document is CONTRIBUTING.md at the repo root — read that first, then come back here for the practical bits.

Pickup

• Issues live in https://github.com/tensorflow/tensorflow/issues (see ISSUES.md at the root for the policy on filing).
• General questions go to TensorFlow Forum (discuss.tensorflow.org) or Stack Overflow with the tensorflow tag.
• Security issues are reported privately per SECURITY.md.

The comp: label on issues maps to subsystems and is the easiest way to find issues you might be qualified to fix:

• comp:core → tensorflow/core/
• comp:keras → tensorflow/python/keras/
• comp:lite → tensorflow/lite/
• comp:xla → tensorflow/compiler/
• comp:apis → tensorflow/python/ mostly

Pull request lifecycle

The lifecycle described in CONTRIBUTING.md has six stages, in order:

1. You open the PR on GitHub.
2. A maintainer triages it and adds size / component / status labels. The CLA must be signed (see below).
3. A reviewer (someone familiar with the area) reviews, and may request changes.
4. Once approved, a kokoro:force-run label kicks off Google's internal CI.
5. The change is mirrored into Google's internal monorepo via Copybara and re-run against internal tests.
6. After internal tests pass, the change is merged in both places. Your PR shows up on master here, possibly with a slightly modified commit message and A. Unique TensorFlower as the author.

Practical implications:

• The squash-merge is done by the bot, not by humans pressing the merge button. Do not be surprised if your name disappears from the commit summary on master; you remain the author in the commit body and on GitHub.
• Internal CI failures can block a PR even when the GitHub CI is green. The maintainer typically pings you to fix.
• Cherry-picks for patch releases (e.g. into r2.21) are done by maintainers; tag your PR with the version if it's a security fix.

CLA

The TensorFlow project requires a signed Contributor License Agreement. You sign it once per email (individual) or per company (corporate). Without the CLA the cla check on the PR will fail and reviewers won't merge.

Definition of done for a PR

For a typical code PR (paraphrasing the checklist in CONTRIBUTING.md):

• You have read CONTRIBUTING.md.
• You have signed the CLA.
• The change is small and focused (no unrelated reformatting).
• You have unit tests, both passing and exercising the new behaviour.
• You have followed the project's coding style (see patterns-and-conventions).
• All affected lint and presubmit checks pass.
• The PR description explains why, and links to the relevant issue.

Sub-pages

• development-workflow — branching, Copybara, internal/external CI, cherry-picks.
• testing — Bazel test, Python and C++ test patterns, GPU tests.
• debugging — tf.debugging, sanitizers, common failure modes.
• patterns-and-conventions — naming, error handling, coding style links.
• tooling — Bazel, code generators, doc generation, ./configure.