👍🎉 First off, thanks for taking the time to contribute! 🎉👍
Check out the Stellar Contribution Guide that applies to all Stellar projects.
- Ensure the issue was not already reported by searching on GitHub under Issues.
- Issues start with:
- The functional area most affected, ex.
ingestion: fix...
. - Or,
ci:
when changes or an issue are isolated to CI. - Or,
doc:
when changes or an issue are isolated to non-code documentation not limited to a single package.
- The functional area most affected, ex.
- Label issues with
bug
if they're clearly a bug. - Label issues with
feature request
if they're a feature request.
- Title: PR titles start with feat, fix, refactor, ci, or doc, followed by a short description of the change.
- Branching: PRs must be opened against the
develop
branch. - Scope: PRs must be focused and not contain unrelated commits.
- Refactoring: 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.
- Go Formatting: Ensure your code is formatted with
gofmt
. - Tests: Ensure your change is covered by tests. If you're adding a new feature or fixing a bug, you must add tests. If you're refactoring, you should add tests if possible.
- Documentation: Update README.md or other relevant documentation pages if necessary. For exported functions, types, and constants, make sure to add a doc comment conforming to Effective Go.
- Best Practices: * Follow Effective Go and Go Code Review Comments.
- Use the present tense ("Add feature" not "Added feature").
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...").
- Start commit message with the relevant issue number, e.g., #123 Fixed bug in XYZ module.
Help us keep Stellar open and inclusive. Please read and follow our Code of Conduct.