Skip to content

Latest commit

 

History

History
58 lines (46 loc) · 5.25 KB

CONTRIBUTING.md

File metadata and controls

58 lines (46 loc) · 5.25 KB
Raw

Contributing Guideline

Thank you for your interest in contributing to LNDK! This project is still experimental, but all contributions are welcome and wanted.

Please note the project's code of conduct if you're interested in helping out.

Types of Contribution

Contributions of various kinds are welcome here:

  1. Review of open pull requests: considerate review of open PRs is a great way to start contributing to the project. PRs tagged with the review wanted label, and those that have no reviewers assigned are a good starting point.
  2. Feature requests: Creation of issues for new features or small tasks are a useful way to help guide the project's priorities.
  3. Code contributions: Anyone is welcome to "scratch their own itch" and open up a PR implementing a feature they're interested in, or pick up a task labeled with help wanted or good first issue.
  4. Documentation improvements: Pull requests or issues aimed at improving documentation are a great way to "pay it forward" to the next confused user that comes along.
  5. Testing and bug reports: Local testing and bug report filing is one of the most helpful ways to improve the quality of the project.
  6. Support: Supporting other users by answering questions posed in issues or bug reports helps cut down maintenance time and share knowledge.

Code Contribution

General guidelines for code contribution:

  1. Commits should be logically structured, and pass all tests so that git bisect can be used.
  2. Refactor commits should be done in their own commits, separately from logical changes.
  3. Wherever possible, new code should be covered by tests.
  4. Bug fixes should start with a test demonstrating the bug, then add the fix and update the test to illustrate that the bug has been addressed.
  5. It is recommended to always use cargo-crev to verify the trustworthiness of any added dependencies, which should be kept to a minimum where possible.
  6. Test changes on regtest where possible. See Github Discussions for guides on setting up local development environments (and other meta topics).
  7. If the code introduces any new lnd grpc calls, remember to update the bakemacaroon command in the README docs to keep it up to date.

Process

  1. Issue creation: If no issue is open for the work you'd like to implement, please open one as a preliminary step so that other contributors can comment on the proposed approach and suitableness of the feature for the repo.
  2. Issue assignee: Github's "assignee" field is used to track who's working on a task, to ensure that work is not duplicated. When you want to pick up an issue, comment on it to check whether anybody is working on it and it will be assigned to you.
  3. Pull request: Open a pull request implementing the feature. Feel free to use github's draft feature to open early to get early, high level feedback on the change.
  4. Review cycle:
    1. When your PR is ready for review and passing all CI checks, move it out of draft and add a comment indicating that it is ready for a look.
    2. If review capacity is available, reviewers will be assigned. If nobody is available, it will be tagged with review wanted and added to the queue.
    3. Reviewers will post comments and suggestions on the PR, be sure to address all comments (either with a code change, or an explanation why you're not changing it) before requesting review again.
    4. When all outstanding comments are addressed, use Github's "request review" feature to restart the review process. Pushes to a PR will not be interpreted as a request for review.

Conventions

The following conventions are use for code style (and enforced by the CI):

  1. Rust format: cargo fmt -- --config unstable_features=true --config wrap_comments=true --config comment_width=100. We require a few config parameters when formatting to enforce a maximum comment length per-line.
  2. Clippy:
rustup component add clippy
cargo clippy
  1. String formatting
    1. Logs: Capitalize and include a . terminating.
    2. Error String: Lower case, no . terminating.
    3. Display imps: Lower case, no . terminating.

Running tests

To run just the unit tests use the command:

cargo test --bin lndk

The integration tests require a Makefile to create an lnd binary. You'll need to install Go and then run them with this command:

make itest