Contributing pull requests¶

️RFCs¶

If the proposed changes require design input, open a Request For Comment issue.

Discuss the feature with project maintainers to be sure that your change fits with the project vision and that you won’t be wasting effort going in the wrong direction.

Once you get the green light 🟢 from maintainers, you can proceed with the PR.

Pull requests¶

Contributions / PRs should follow the Forking Workflow. In short:

Fork it: https://github.com/[your-github-username]/tamr-client/fork
Create your feature branch:
```
git checkout -b my-new-feature
```
Commit your changes:
```
git commit -am 'Add some feature'
```
Push to the branch:
```
git push origin my-new-feature
```
Create a new Pull Request

Commits¶

Split and squash commits as necessary to create a clean git history. Once you ask for review, only add new commits (do not change existing commits) for reviewer convenience. You may change commits in your PR only if reviewers are ok with it.

Commit messages must follow the Conventional Commits. CI for pull requests will enforce this and fail if commit messages are not formatted correctly.

We recommend the Commitzen CLI to make writing Conventional Commits easy, but you may write commit messages manually or use any other tools.

Also, your commit messages should explain any things that are not obvious from reading your code!

CI checks¶

Continuous integration (CI) checks are run automatically for all pull requests. CI runs the same dev tasks that you can run locally.

You should run dev tasks locally before submitting your PR to cut down on subsequent commits to fix the CI checks.