Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
64 lines (44 loc) · 3.73 KB

CONTRIBUTING.md

File metadata and controls

64 lines (44 loc) · 3.73 KB

How to contribute

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

Check out the Stellar Contribution Guide that applies to all Stellar projects.

Contribution Quality Standards

We welcome meaningful contributions that add real value to the project. To maintain code quality and project integrity, please note:

  • No trivial contributions for credit farming - We do not accept PRs that make minimal changes solely to gain contribution credits or build activity history (e.g., whitespace-only changes, single character fixes, unnecessary formatting changes).
  • Substantial contributions only - All contributions should address real issues, add meaningful functionality, or provide genuine improvements to the codebase.
  • Genuine engagement - Contributors should demonstrate understanding of the codebase and the problem they're solving.

Contributions that appear to be made solely for gaining credits or building fake activity may be closed without review.

Style guides

Issues

  • Ensure the issue was not already reported by searching on GitHub under Issues.
  • Issues start with:
    • The functional area most affected, ex. disbursements: 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.
  • Label issues with bug if they're clearly a bug.
  • Label issues with feature request if they're a feature request.

Branches

  • Branches follow these naming conventions:
    • feat/SDP-123-description for features. SDP-123 is the ticket/issue number.
    • bugfix/SDP-123-description for bugs/fixes.
    • chore/SDP-123-description for general cleanups, continuous improvements, documentation, etc.
    • release/x.x.x for releases (usually created automatically by CI), e.g. release/6.4.0

Pull Requests

  • Title: PR titles contain the following:
    • ticket/issue number (e.g. SDP-123) (if applicable)
    • feat, fix, refactor, ci, chore or doc
    • 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.

Git Commit Messages

  • 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.

Development Environment

All SDP services can be started using the docker-compose.yml file in the dev directory. Please refer to the README for more information.

Code of Conduct

Help us keep Stellar open and inclusive. Please read and follow our Code of Conduct.