Thanks for contributing to ChoreOps.
- Fork and clone the repository
- Create a feature branch from
main - Make focused changes with tests when applicable
- Run validation locally
- Open a pull request
Run these before opening a PR:
./utils/quick_lint.sh --fixmypy custom_components/choreops/python -m pytest tests/ -v --tb=line
If your change only affects a narrow area, you may run a targeted test suite, but include rationale in your PR.
- Follow
docs/DEVELOPMENT_STANDARDS.md - Follow
docs/ARCHITECTURE.md - Follow
docs/QUALITY_REFERENCE.md - Use constants instead of hardcoded user-facing strings
- Use lazy logging (for example,
LOGGER.debug("value: %s", value)) - Keep changes minimal and scoped to the problem
- Link the issue when applicable (
Closes #...) - Explain what changed and why
- Describe validation performed
- Note documentation impact (README/wiki/docs)
- Call out breaking changes and migration impact when relevant
Use a pull request to main so automation can close issues and categorize release notes.
- Include a closing keyword in the PR body when applicable (
Closes #...) - Apply the correct release-note label for the change type
- Remove excluded triage or status labels before merge
- Use a release-note-friendly PR title
- Complete the PR template sections for validation and release notes
See docs/DEVELOPMENT_STANDARDS.md for the canonical main-merge and release automation contract.
- Do not submit dashboard template source changes to this repository.
- Any PR that changes files under
custom_components/choreops/dashboards/will be closed and redirected. - Submit dashboard template, registry, and preference documentation changes to
ccpk1/ChoreOps-Dashboards. - Dashboard assets in this repository are synchronized from
ccpk1/ChoreOps-Dashboards.
- Use GitHub Discussions for questions and early ideas
- Use GitHub Issues for actionable bugs and feature requests
- Support and usage questions: GitHub Discussions
- Bug reports: GitHub Issues templates