👍🎉 First off, thanks for taking the time to contribute! 🎉👍
Check out the Stellar Contribution Guide that apply to all Stellar projects.
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- PR titles start with:
- The package name most affected, ex.
services/horizon: fix...
. - Or, multiple package names separated by a comma when the fix addresses multiple packages worth noting, ex.
services/horizon, services/friendbot: fix...
. - Or,
all:
when changes are broad, ex.all: update...
. - Or,
doc:
when changes are isolated to non-code documentation not limited to a single package.
- The package name most affected, ex.
- PRs must update the CHANGELOG with a small description of the change
- PRs are merged into master or release branch using squash merge
- Carefully think about where your PR fits according to semver. Target it at master if it’s only a patch change, otherwise if it contains breaking change or significant feature additions, set the base branch to the next major or minor release.
- Keep PR scope narrow. Expectation: 20 minutes to review max
- Explicitly differentiate refactoring PRs and feature PRs. Refactoring PRs don’t change functionality. They usually touch a lot more code, and are reviewed in less detail. Avoid refactoring in feature PRs.
- Use
gofmt
or preferablygoimports
to format code - Follow Effective Go and Go Code Review Comments
- Always document exported package elements: vars, consts, funcs, types, etc.
- Tests are better than no tests.