👍🎉 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...")
- Issues and PR titles start with:
- The package name most affected, ex.
ingest: fix.... - Or, for services and tools, the service most affected, ex.
services/horizon: fix...,services/ticker: add... - 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 or an issue are broad, ex.all: update.... - Or,
doc:when changes or an issue are isolated to non-code documentation not limited to a single package.
- The package name most affected, ex.
- Label issues with
bugif they're clearly a bug. - Label issues with
feature requestif they're a feature request.
- PR titles follow the same rules as described in the Issues section above.
- 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
gofmtor preferablygoimportsto 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.