Contributions are always welcome. The codebase is maintained using the "contributor workflow" where anyone can contribute proposals using pull requests.
The contribution workflow is as follows:
- Fork the repository.
- Create a topic branch.
- Commit changes to the branch.
- Push changes to the fork.
- Create a pull request to merge the branch of the fork into this repository.
- If you had someone specifically in mind, ask them to review the pull request. Otherwise, just wait for a code review: most members with merge permissions receive notifications for newly created pull requests.
- Address review comments, if any.
- Merge and submit the pull request. If you don't have merge permissions, a reviewer will do it for you.
NOTE: Before starting a particular feature, please make sure to check if a related issue already exists and is not already assigned to somebody. If there is no issue created, open up a new issue if you want to first discuss and to agree on the optimal way of solving a particular problem.
If you don't know where to start, look for issues labeled with good first issue.
The Rust source code should be formatted according to cargo fmt and have no linting errors from cargo clippy. Any changes to public facing functions or structs should be adequately documented according to rustdoc. Comments on code should be written clearly and concisely, and written in English.
If there are any changes to the SDK's interface, they also need to be updated in the bindings interface. The SDK uses UniFFI and Flutter Rust Bridge to generate the bindings code for several different languages.
Please update the following crates when you change an SDK interface:
- lib.rs - Update the Rust interface for the UniFFI bindings.
- breez_sdk_liquid.udl - Update the UniFFI interface definition language file.
- bindings.rs - Update the Rust interface for the Flutter Rust Bridge bindings.
After making these changes the Dart, Flutter and React Native bindings code also need to be regenerated and included in your pull request. You can regenerate these from the project root using make codegen. Please see the prerequisites for Flutter and React Native if this is your first time generating code.
Please adequately test your code using the existing tests and write additional tests for new features. You can run the tests from the project root using make test. You can also make use of the CLI to test changes while developing your feature.
A pull request contains one or more related git commits. Please, do not bundle independent and unrelated commits into a single pull request.
Just like a git commit message, a pull request consists of a subject and a body. If a pull request contains only one git commit, set its title and description to the commit's subject and the body. Otherwise, make an overall summary of what all the commits accomplish together, in a way similar to a commit message. If you are addressing an existing issue, please reference it in the pull request body.
See the following docs on creating github pull requests.
Before creating a pull request, please make sure all tests and lints pass locally on your machine. In a case where a pull request isn't ready for a regular code review and you're just looking for some early feedback, it's ok to let some tests fail but please mention it explicitly in the request description.
You can run all the following commands in the project root directory to comply to the contribution guide:
- Format and lint the source code:
make fmt clippy - Generate code Flutter and React Native bindings:
make codegen - Test the code:
make test
You can run all these in one command: make all