Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
37 lines (28 loc) · 2.27 KB

CONTRIBUTING.md

File metadata and controls

37 lines (28 loc) · 2.27 KB

Contributing to ChatMock

We welcome thoughtful improvements. This guide calls out the expectations that keep reviews quick and the project stable.

How should I contribute?

Before changing code...

  • Open an issue before large or risky efforts so scope is agreed up front.
  • Keep pull requests focused and easy to follow & break sweeping changes into a series when possible.
  • Treat documentation, code, and packaging (CLI, Docker, GUI) as a single surface (your updates should apply to all).

Getting Set Up

  • Review the Quickstart section in README.md
  • Go through the codebase, and ensure you understand the current codebase.
  • Confirm you can log in and serve a local instance, then make a couple of sample requests to understand current behaviour so you know if it broke later on.

Working With Core Files

  • prompt.md and related Codex harness files are sensitive. Do not modify them or move entry points without prior maintainer approval.
  • Be cautious with parameter names, response payload shapes, and file locations consumed by downstream clients. Coordinate before changing them.
  • When touching shared logic, update both OpenAI and Ollama routes, plus any CLI/GUI code that depends on the same behaviour.

Designing Features and Fixes

  • Prefer opt-in flags or config switches for new capabilities & leave defaults unchanged until maintainers confirm the rollout plan.
  • Document any limits, or external dependencies introduced by your change.
  • Validate compatibility with popular clients (e.g. Jan, Raycast, custom OpenAI SDKs) when responses or streaming formats shift.

Pull Request Checklist

  • Rebased on the latest main and issue reference included when applicable.
  • Manual verification steps captured under "How to try locally" in the PR body.
  • README.md, DOCKER.md, and other docs updated—or explicitly noted as not required.
  • No generated artefacts or caches staged (build/, dist/, __pycache__/, .pytest_cache/, etc.).
  • Critical paths (prompt.md, routing modules, public parameter names) reviewed for unintended edits and discussed with maintainers if changes were necessary.

Need Help?

  • If you're not sure about about scope, flags, or how to implement a certain feature, always create an issue before hand.

Thank you for you contribution!