| 1 | # Contributing to Siti AI |
| 2 | |
| 3 | Thanks for your interest — Siti is both a shipping product and the reference app |
| 4 | for the [Onde](https://ondeinference.com) inference engine, so clean, readable |
| 5 | contributions genuinely help other developers. |
| 6 | |
| 7 | ## Ground rules |
| 8 | |
| 9 | - Be kind and constructive. This project follows a [Code of Conduct](CODE_OF_CONDUCT.md). |
| 10 | - For security issues, **do not open a public issue** — follow [SECURITY.md](SECURITY.md). |
| 11 | - Discuss non-trivial changes in an issue before opening a large PR. |
| 12 | |
| 13 | ## Contributor License Agreement (CLA) |
| 14 | |
| 15 | Before we can merge your first contribution, you'll need to sign our |
| 16 | [Contributor License Agreement](CLA.md). It's lightweight and only needs to be |
| 17 | done once. When you open a pull request, the CLA bot will comment with a link if |
| 18 | a signature is needed. |
| 19 | |
| 20 | Why a CLA: Siti's code is Apache-2.0, but the project sits alongside a |
| 21 | commercially licensed SDK. The CLA lets Splitfire AB keep both open-source and |
| 22 | commercial licensing options open while guaranteeing your contribution stays |
| 23 | available under the open license. |
| 24 | |
| 25 | ## Development setup |
| 26 | |
| 27 | **Prerequisites:** [Rust](https://rustup.rs) (stable), [pnpm](https://pnpm.io), |
| 28 | and the [Tauri prerequisites](https://tauri.app/start/prerequisites/) (Xcode on |
| 29 | macOS). |
| 30 | |
| 31 | ```bash |
| 32 | pnpm install |
| 33 | make dev # start the Tauri dev server (or: pnpm tauri dev) |
| 34 | ``` |
| 35 | |
| 36 | The Onde engine is pulled from crates.io — you do **not** need a separate SDK |
| 37 | checkout. To hack on Siti and Onde together, uncomment the `[patch.crates-io]` |
| 38 | block in `src-tauri/Cargo.toml` and point it at your local `onde` checkout. |
| 39 | |
| 40 | ## Before you open a PR |
| 41 | |
| 42 | ```bash |
| 43 | make fmt # cargo fmt |
| 44 | make lint # clippy + tsc — must pass with no warnings |
| 45 | make build # must compile |
| 46 | ``` |
| 47 | |
| 48 | - Keep changes focused; one logical change per PR. |
| 49 | - Match the surrounding style. The codebase is deliberately well-commented where |
| 50 | the "why" is non-obvious — keep that up. |
| 51 | - Update docs when you change behavior. |
| 52 | - New Rust code should be `clippy`-clean; new UI code should typecheck. |
| 53 | |
| 54 | ## Commit messages |
| 55 | |
| 56 | Write clear, imperative commit messages ("Add model download retry", not |
| 57 | "added stuff"). Reference issues where relevant (`Fixes #123`). |
| 58 | |
| 59 | ## Pull requests |
| 60 | |
| 61 | - Fill out the PR template. |
| 62 | - Ensure CI is green. |
| 63 | - A maintainer will review; expect a round or two of feedback. We care about the |
| 64 | details because this codebase is meant to be read. |
| 65 | |
| 66 | ## Reporting bugs & requesting features |
| 67 | |
| 68 | Use the issue templates. Good bug reports include your platform/version, steps to |
| 69 | reproduce, and what you expected vs. what happened. |
| 70 | |
| 71 | ## License of contributions |
| 72 | |
| 73 | By contributing, you agree that your contributions are licensed under |
| 74 | [Apache-2.0](LICENSE) and covered by the terms of the [CLA](CLA.md). |