|
| 1 | +# How to contribute |
| 2 | + |
| 3 | +We definitely welcome your patches and contributions to convoy! |
| 4 | + |
| 5 | +If you are new to github, please start by |
| 6 | +reading [Pull Request howto](https://help.github.com/articles/about-pull-requests/) |
| 7 | + |
| 8 | +## Guidelines for Pull Requests |
| 9 | + |
| 10 | +How to get your contributions merged smoothly and quickly. |
| 11 | + |
| 12 | +- Create **small PRs** that are narrowly focused on **addressing a single concern**. We often times receive PRs that are |
| 13 | + trying to fix several things at a time, but only one fix is considered acceptable, nothing gets merged and both |
| 14 | + author's & review's time is wasted. Create more PRs to address different concerns and everyone will be happy. |
| 15 | + |
| 16 | +- The convoy package should only depend on standard Go packages and a small number of exceptions. If your contribution |
| 17 | + introduces new dependencies which are NOT in the [list](https://pkg.go.dev/github.com/frain-dev/convoy?tab=imports), |
| 18 | + you need a discussion with the convoy creators. |
| 19 | + |
| 20 | +- For speculative changes, consider opening an issue and discussing it first. If you are suggesting a behavioral or API |
| 21 | + change, consider starting with a proposal draft. |
| 22 | + |
| 23 | +- Provide a good **PR description** as a record of **what** change is being made and **why** it was made. Link to a |
| 24 | + github issue if it exists. |
| 25 | + |
| 26 | +- Don't fix code style and formatting unless you are already changing that line to address an issue. PRs with irrelevant |
| 27 | + changes won't be merged. If you do want to fix formatting or style, do that in a separate PR. |
| 28 | + |
| 29 | +- Unless your PR is trivial, you should expect there will be reviewer comments that you'll need to address before |
| 30 | + merging. We expect you to be reasonably responsive to those comments, otherwise the PR will be closed after 2-3 weeks |
| 31 | + of inactivity. |
| 32 | + |
| 33 | +- Maintain **clean commit history** and use **meaningful commit messages**. PRs with messy commit history are difficult |
| 34 | + to review and won't be merged. Use |
| 35 | + `rebase -i upstream/main` to curate your commit history and/or to bring in latest changes from main (but avoid |
| 36 | + rebasing in the middle of a code review). |
| 37 | + |
| 38 | +- Keep your PR up to date with upstream/main (if there are merge conflicts, we can't really merge your change). |
| 39 | + |
| 40 | +- **All tests need to be passing** before your change can be merged. We recommend you **run tests locally** before |
| 41 | + creating your PR to catch breakages early on. |
| 42 | + - `make all` to test everything, OR |
| 43 | + - `make vet` to catch vet errors |
| 44 | + - `make test` to run the tests |
| 45 | + - `make testrace` to run tests in race mode |
| 46 | + |
| 47 | +- For convenience, run `make setup` to run set relevant configurations, like a pre-commit hook to regenerate openapi docs on every commit to files in the server folder. |
| 48 | +- Exceptions to the rules can be made if there's a compelling reason for doing so. |
0 commit comments