We're striving to keep master's history with minimal merge bubbles. To achieve this, we're asking PRs to be submitted rebased on top of master.
To keep your local repository in a "rebased" state, simply run:
git config --global branch.autosetuprebase always
changes the default for all future branches
git config --global branch.master.rebase true
changes the setting for branch master
Note: you may still have to run manual "rebase" commands on your branches, to rebase on top of master as you pull changes from upstream.
The first place to start is always looking over the current github issues for the project you are interested in contributing to. Issues marked with help wanted
are usually pretty self contained and a good place to get started.
stellar.org also uses these same github issues to keep track of what we are working on. If you see any issues that are assigned to a particular person that means someone is currently working on that issue.
Of course feel free to make your own issues if you think something needs to added or fixed.
Please ensure that all tests pass before submitting changes. The local testsuite can be run as make check
or src/stellar-core --test
,
see README for details on running tests.
Code formatting wise, we have a .clang-format
config file that you should use on modified files.
Try to separate logically distinct changes into separate commits and thematically distinct commits into separate pull requests.
When submiting changes that may impact performance, you need to also provide some evidence of the improvement (which also implies no regression). See the performance evaluation document for more details.
Please sign the Contributor License Agreement.
All content, comments, and pull requests must follow the Stellar Community Guidelines.
Submit a pull request rebased on top of master
- Include a descriptive commit message.
- Changes contributed via pull request should focus on a single issue at a time.
At this point you're waiting on us. We like to at least comment on pull requests within one week (and, typically, three business days). We may suggest some changes or improvements or alternatives.