# Contributing to py-xiaozhi
Looking for the Chinese version? See [CONTRIBUTING_ZH.md](./CONTRIBUTING_ZH.md).
Thank you for helping improve `py-xiaozhi`. We welcome bug reports, documentation fixes, tests, tooling improvements, and well-scoped features.
## Before You Start
- Search existing issues and pull requests before opening a new one.
- Open an issue first for large features, architectural changes, or behavior changes.
- Small bug fixes, docs fixes, and focused improvements can usually go straight to a pull request.
## Development Setup
### Requirements
- Python `>=3.10`
- Git
- A working microphone and speaker if you need to verify audio behavior
### Install Dependencies
```bash
git clone https://github.com/huangjunsen0406/py-xiaozhi.git
cd py-xiaozhi
# Base install
uv sync
# GUI + development tools
uv sync --extra gui --group dev
```
If you do not use `uv`, use the fallback commands below:
```bash
pip install -e .
pip install -e '.[gui]'
pip install pytest pytest-asyncio ruff pyinstaller
```
## Workflow
1. Fork the repository and create a topic branch from `main`.
2. Keep the change focused on one bug, feature, or documentation task.
3. Follow Conventional Commits such as `fix(audio): handle empty frame`.
4. Update docs when behavior, configuration, or public APIs change.
5. Add or update tests when the change affects correctness or regression risk.
Recommended branch names:
- `feature/xxx`
- `fix/xxx`
- `docs/xxx`
- `refactor/xxx`
- `test/xxx`
## Quality Bar
Run the checks that apply to your change before opening a pull request:
```bash
ruff check .
ruff format .
pytest
```
Please also verify the relevant runtime path when applicable, for example:
- GUI changes: launch `python main.py`
- CLI changes: launch `python main.py --mode cli`
- Protocol changes: verify `websocket` or `mqtt` behavior
- Docs changes: preview under `documents/`
## Pull Request Expectations
Each pull request should:
- Explain the problem and the proposed solution clearly.
- Link the related issue when one exists.
- Include validation steps, screenshots, or logs when they help review.
- Stay reasonably small and avoid mixing unrelated refactors.
- Respect the existing coding style and project structure.
## Maintainer Workflow
Maintainers generally review contributions using the following workflow:
1. Triage the change as `bug`, `feature`, `docs`, `refactor`, or `maintenance`.
2. Check whether the scope is clear, reproducible, and aligned with project direction.
3. Review tests, docs, and validation evidence before requesting changes or approval.
4. Merge after CI passes and review feedback is addressed.
5. Ship through the normal release process; merge does not guarantee an immediate release.
## Detailed Guides
- Documentation site:
- Detailed contribution guide:
- Chinese contribution guide:
Thanks again for contributing.