How to contribute

Ollama accepts contributions through GitHub pull requests. Before opening a non-trivial PR, file an issue first — the project explicitly asks for that in CONTRIBUTING.md so design questions are settled before code is written.

Pickup

The project flags three buckets of issues as the easiest place to start:

• Bugs — anything that breaks an existing flow.
• Performance — make inference, downloads, or uploads faster.
• Security — disclose privately, see SECURITY.md.

Things that have a higher bar:

• New API fields or environment variables (surface area is hard to remove later).
• Large refactors (long review cycles).
• Big documentation expansions (hard to maintain).
• Anything that breaks API backwards compatibility — generally not accepted.

PR process

1. Branch from main.
2. Implement your change with tests. Strive to test behavior, not implementation (CONTRIBUTING.md).
3. Run go test ./... and golangci-lint run (config: .golangci.yaml).
4. Open the PR. Use the commit message format below.
5. Address review feedback, keeping commits small and focused.

Commit message format

From CONTRIBUTING.md:

<package>: <short description>

<package> is the most affected Go package (or directory name if the change is non-Go). The description starts with a lowercase verb that fits in the sentence "This changes Ollama to …".

Good examples (from the repo):

• llm/backend/mlx: support the llama architecture
• tokenizer: fix multi-regex BPE offset handling
• server/launch: add model recommendations cache endpoint
• app: align the app launch page with ollama launch

Avoid Conventional-Commit prefixes (feat:, fix:, chore:) — they're called out specifically as bad examples in CONTRIBUTING.md.

Definition of done

• New behavior is exercised by tests.
• go test ./... is clean.
• golangci-lint run is clean.
• Public API changes (HTTP, Go client, Modelfile) are backward-compatible or motivated in the linked issue.
• The change is documented in docs/ if user-facing.

Sub-pages

• Development workflow — branch, build, test, ship.
• Testing — how the test suite is organized.
• Debugging — logs, common failure modes, and the env vars that change behavior.
• Patterns and conventions — error handling, configuration, naming.
• Tooling — build system, lint, code generation, CI.

Help

The project's primary support channel is its Discord server.