# bestool Contributions Guide
Thank you for taking the time to contribute, and welcome to this open-source project!
## Code of Conduct
This project and everyone participating in it is governed by the
[BES Open Source Code of Conduct](CODE_OF_CONDUCT.md).
By participating, you are expected to uphold this code. Please report unacceptable behavior
to [opensource@tamanu.io](opensource@tamanu.io).
## Copyright Attribution
All open-source contributors to bestool will be required to sign a Contributor License Agreement (CLA)
before BES can accept your contribution into the project code. This is done so that we can continue
to maintain the codebase covered by a single license. Signing a CLA can be done through GitHub
before merging in your first pull request.
## Making Your Code Contribution
### Code Quality
When making your contribution, please ensure that your code is of high quality. Follows best
practices, write clean and readable code, add comments where necessary, and thoroughly test your
code. We have a code review process for all contributions, and have a high standard for quality.
### Branching Strategy
1. When creating a branch for your contribution, branch off the latest `main`.
2. Make your commits on the branch you made.
3. Once your changes are complete, pull from the latest `main` and create a pull request on GitHub.
### Commit Convention
The subject (first line) of commit messages must be in [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/)
format. This is used to automatically generate the changelog.
```plain
type: <description>
type(scope): <description>
```
When a Linear card is applicable, the Linear card number should be included:
```plain
type: TEAM-123: <description>
type(scope): TEAM-123: <description>
```
The following types are conventional:
- `ci` for changes to the CI/CD workflows (ignored in changelogs)
- `deps` for changes to dependencies or dependency upgrades
- `doc` for documentation changes
- `feat` for new features
- `fix` for bug fixes
- `fmt` for automatic formatting changes (ignored in changelogs)
- `merge` for merging between branches (ignored in changelogs))
- `perf` for performance optimisations
- `refactor` for code refactorings
- `release` for changes that are part of the release process (generally automated commits, not manual use)
- `repo` for changes to the repository structure, or for config/dotfiles (e.g. `.gitignore`, `.editorconfig`, etc)
- `revert` for reverting a previous commit
- `style` for stylistic changes that do not affect the meaning of the code
- `test` for adding missing tests or correcting existing tests
- `tweak` for minor changes that do not fit into any other category
- `wip` or `draft` for features committed in a half-working state (must be feature-gated)
This list is informational, the authoritative list is in the [git-cliff config](./cliff.toml).
Additional change lines can be added to the body of a commit message.
### Pull Requests
When your contribution is ready for review, create a pull request. A BES developer will review
your changes and provide feedback. If your pull request has been approved by a reviewer, it
will then go through a round of internal testing. Once your changes have passed testing, they
can be merged into main and be included in an upcoming release.
We prefer a linear history with commits rebased on merge, but may opt for a squash-merge from
times to times to clean up the changelog entries of the pull request.
Before merging, the pull request must be up to date with `main`; use the rebase method to keep
a linear history.
## License
Any contributions you make will be licensed under [the General Public License version 3.0](./COPYING).