Skip to content

Commit 3bda091

Browse files
authored
docs: add contributing guide (abetlen#2229)
1 parent 52fe54b commit 3bda091

3 files changed

Lines changed: 79 additions & 0 deletions

File tree

CHANGELOG.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8,6 +8,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
88
## [Unreleased]
99

1010
- feat: Update llama.cpp to ggml-org/llama.cpp@c0c7e147e
11+
- docs: add contributing guide by @abetlen in #2229
1112
- chore: Migrate llama.cpp submodule URL to ggml-org/llama.cpp by @shalinib-ibm in #2034
1213
- fix: Enable unified KV cache for embedding contexts to preserve full per-sequence context in batch embedding calls by @SanjanaB123 in #2217
1314

CONTRIBUTING.md

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
# Contributing
2+
3+
Hello human and AI contributors, this document exists to help you understand the project and set some rules for contributions.
4+
5+
## Contribution Workflow
6+
7+
Before opening a pull request, search existing issues and PRs to avoid duplicate work.
8+
Keep each PR focused on one feature, bug fix, or vendor update.
9+
Avoid mixing unrelated Python changes, generated binding updates, documentation edits, and `vendor/llama.cpp` changes unless they are required for the same fix.
10+
11+
Describe what changed, why it changed, and how it was tested.
12+
Link relevant issues, include any required build flags or hardware assumptions, and add a `CHANGELOG.md` entry for user-visible fixes or features (see `CHANGELOG.md` for examples).
13+
14+
BREAKING CHANGES WILL ALMOST CERTAINLY BE REJECTED OR REFACTORED.
15+
16+
## PR Titles and Changelog Entries
17+
18+
Use PR titles in the form `<tag>: <title>`, with an optional scope when it adds clarity: `feat: add X`, `fix(server): handle Y`, `fix(ci): repair Z`, or `chore: bump version to N`.
19+
Prefer tags already used in the project history, such as `feat`, `fix`, `chore`, `ci`, `docs`, and `refactor`.
20+
21+
Add changelog entries under `## [Unreleased]` using the PR title followed by `by @contributor in #1234`.
22+
23+
```md
24+
- feat(server): add support for X by @contributor in #1234
25+
- fix(ci): repair Y wheel builds by @contributor in #1234
26+
```
27+
28+
## Local Development
29+
30+
Prerequisites: Python 3.8+, CMake 3.21+, a C/C++ compiler, and Git submodules.
31+
From a fresh checkout of the repository, initialize submodules and create a virtual environment:
32+
33+
```bash
34+
git submodule update --init --recursive
35+
python3 -m venv .venv
36+
source .venv/bin/activate
37+
python -m pip install --upgrade pip
38+
make deps
39+
make build
40+
```
41+
42+
Run tests and lint checks before submitting changes:
43+
44+
```bash
45+
make test
46+
make lint
47+
```
48+
49+
Use backend-specific build targets when validating native acceleration or backend-specific fixes, for example `make build.openblas`, `make build.cuda`, `make build.metal`, or `make build.vulkan`.
50+
51+
## Testing Expectations
52+
53+
Add or update tests for behavior changes or fixing regressions.
54+
The test suite uses pytest and lives under `tests/`; name files `test_*.py` and test functions `test_*`.
55+
56+
For changes involving native backends, model behavior, performance, or platform compatibility, document the environment used for validation in the PR.
57+
If a change cannot be covered by automated tests, include a short manual validation recipe instead.
58+
59+
## Code Style
60+
61+
Python code is formatted with Ruff using an 88-character line length.
62+
Run `make format` to apply automatic fixes and `make lint` to check formatting and lint rules.
63+
64+
Use 4-space indentation, `snake_case` for functions and variables, `PascalCase` for classes, and `UPPER_CASE` for constants.
65+
Follow existing patterns when touching ctypes bindings or server APIs, and avoid adding dependencies unless they are necessary for the feature or fix.
66+
67+
## Documentation Style
68+
69+
Write Markdown with one sentence or core idea per physical line to keep diffs focused and easier to review.
70+
Do not manually wrap lines at a fixed column width.
71+
Keep `README.md` focused on user-facing setup and usage; link to this guide for contribution workflow details rather than duplicating them.
72+
73+
## Project Layout
74+
75+
The Python package lives in `llama_cpp/`, with tests in `tests/` and examples in `examples/`.
76+
Documentation lives in `docs/` and is built with `mkdocs.yml`.
77+
The `vendor/llama.cpp/` directory is a Git submodule containing the upstream llama.cpp sources used by the bindings.

README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -743,6 +743,7 @@ If you find any issues with the documentation, please open an issue or submit a
743743
## Development
744744

745745
This package is under active development and I welcome any contributions.
746+
See [CONTRIBUTING.md](CONTRIBUTING.md) for contribution workflow, PR title, changelog, testing, and style guidelines.
746747

747748
To get started, clone the repository and install the package in editable / development mode:
748749

0 commit comments

Comments
 (0)