Loading files
This file is pinned to the selected release. Download the original to open it in your design tool.
126616f26This file is pinned to the selected release. Download the original to open it in your design tool.
# Contributing
Pull requests of all sizes are welcome.
Examples of useful contributions:
- New accessories, cases, and schematics improvements
- Firmware fixes and new examples on top of the firmware
- Tooling, CI, and development environment improvements
- Documentation fixes and translations
## Before opening a pull request
- Base your branch on `develop`
- Use `feat/*` for feature work and `fix/*` for fixes
- Open pull requests against `develop` unless the maintainers ask for another base branch
- Keep each pull request focused on a single topic
- Run the relevant checks before opening the pull request
For firmware changes:
```bash
cd firmware
npm run format
npm run lint
npm run test
```
If your change depends on Moddable or ESP-IDF tooling, include the build or runtime command you used in the pull request description.
## Pull request expectations
- Describe the problem and the intended change
- List the directories or subsystems affected
- Include verification steps that another contributor can run
- Call out any breaking change or hardware-specific behavior
- Classify the release impact as `none`, `patch`, `minor`, or `major`
- If the PR changes a released firmware or web deliverable, include the release note or changeset text, or explain why no release note is needed
## Review expectations
- Reviewers should confirm the stated release impact matches the actual user-visible change
- Firmware and web changes that affect released behavior should not merge without a release note or an explicit reason it is not needed
- Docs, CI, repository metadata, case, and schematics changes should be checked for release impact before asking for a release note or changeset
## Branch and release flow
The repository uses `main <- release/* <- develop <- feat/* | fix/*` for a frozen release.
- `main` is the stable branch and should represent released or release-ready source.
- `develop` is the default branch and integration branch for the next release.
- A release branch is cut from a fixed `develop` commit and reviewed through a `release/*` to `main` pull request.
- After publication, `main` is merged back into `develop` so version and release metadata remain in the next development cycle.
See `docs/operations/release-flow.md` for the detailed branch policy.
## Issue reports
Bug reports should include:
- Steps to reproduce
- Expected and actual behavior
- Logs, screenshots, or photos when they help
- Your OS, editor, target device, and firmware branch/version
Take it easy and stay healthy. Thank you very much.