|
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). |