| summary | Contribution guidelines including quality gates and PR workflow. | |||
|---|---|---|---|---|
| read_when |
|
Thank you for your interest in contributing! This guide covers how to contribute effectively.
- Fork and clone the repository:
git clone <repo-url>
cd <project-name>- Build the project:
# adapt: replace with project build command- Run tests:
# adapt: replace with project test command- Make your changes and test locally.
- Code compiles without warnings
- Tests pass
- No linter warnings
- Code formatted
- Documentation updated (if behavior changes)
- Commit messages are clear and descriptive
- Create a feature branch:
git checkout -b feature/my-feature- Make commits with clear messages:
git commit -m "feat: add new feature"- Push and open PR:
git push origin feature/my-feature- In your PR description:
- Explain what changed and why
- Reference any related issues
- Note any breaking changes
- All PRs require at least one review
- Address review feedback promptly
- CI must pass before merge
- Maintainers may squash commits on merge
Run these before pushing:
# adapt: replace with project-specific commands
bin/validate-docs- Follow project idioms and formatting conventions
- Run linters and fix all warnings
- Keep functions focused and small
- Use meaningful variable names
- See
docs/STYLE.mdfor full conventions
If your change affects user-facing behavior:
- Update
README.mdfor user-facing changes - Update
docs/PRIMARY_TODO.mdif architecture changes - Add/update examples if applicable
- Open an issue for bugs or feature requests
- Join discussions in existing issues
- Check
docs/for architecture and setup information
By contributing, you agree that your contributions will be licensed under the project's license.