X-Git-Url: http://git.bitcoin.ninja/index.cgi?p=rust-lightning;a=blobdiff_plain;f=CONTRIBUTING.md;h=3cf463ba02e220b7f1e12605398c344fc3d79628;hp=c54701ddfde83c1fe6dc3334f4c0f32c79334cd9;hb=refs%2Fheads%2F2021-07-broken-beta;hpb=edbc7e8d99af8853cc8e63afeea524f6028566fa diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c54701dd..3cf463ba 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -15,12 +15,40 @@ you'll learn. Communications Channels ----------------------- -Communication about Rust-Lightning happens primarily on #ldk-dev on the [LDK slack](http://www.lightningdevkit.org/), -but also #rust-bitcoin on IRC Freenode. +Communication about Rust-Lightning happens primarily on #ldk-dev on the +[LDK slack](http://www.lightningdevkit.org/), but also #rust-bitcoin on IRC Freenode. Discussion about code base improvements happens in GitHub issues and on pull requests. +Major projects are tracked [here](https://github.com/rust-bitcoin/rust-lightning/projects). +Major milestones are tracked [here](https://github.com/rust-bitcoin/rust-lightning/milestones?direction=asc&sort=title&state=open). + +Getting Started +--------------- + +First and foremost, start small. + +This doesn't mean don't be ambitious with the breadth and depth of your contributions but rather +understand the project culture before investing an asymmetric number of hours on +development compared to your merged work. + +Browsing through the [meeting minutes](https://github.com/rust-bitcoin/rust-lightning/wiki/Meetings) +is a good first step. You will learn who is working on what, how releases are drafted, what are the +pending tasks to deliver, where you can contribute review bandwidth, etc. + +Even if you have an extensive open source background or sound software engineering skills, consider +that the reviewers' comprehension of the code is as much important as technical correctness. + +It's very welcome to ask for review, either on IRC or LDK Slack. And also for reviewers, it's nice +to provide timelines when you hope to fulfill the request while bearing in mind for both sides that's +a "soft" commitment. + +If you're eager to increase the velocity of the dev process, reviewing other contributors work is +the best you can do while waiting review on yours. + +Also, getting familiar with the [glossary](GLOSSARY.md) will streamline discussions with regular contributors. + Contribution Workflow --------------------- @@ -47,11 +75,17 @@ be covered by functional tests. When refactoring, structure your PR to make it easy to review and don't hestitate to split it into multiple small, focused PRs. -The Minimal Supported Rust Version is 1.22.0 (enforced by our Travis). +The Minimal Supported Rust Version is 1.36.0 (enforced by our GitHub Actions). -Commits should cover both issues fixed and solutions' rationale. +Commits should cover both the issue fixed and the solution's rationale. These [guidelines](https://chris.beams.io/posts/git-commit/) should be kept in mind. +To facilitate communication with other contributors, the project is making use of +GitHub's "assignee" field. First check that no one is assigned and then comment +suggesting that you're working on it. If someone is already assigned, don't hesitate +to ask if the assigned party or previous commenters are still working on it if it has +been awhile. + Peer review ----------- @@ -67,6 +101,26 @@ Coding Conventions Use tabs. If you want to align lines, use spaces. Any desired alignment should display fine at any tab-length display setting. +Our CI enforces [clippy's](https://github.com/rust-lang/rust-clippy) default linting +[settings](https://rust-lang.github.io/rust-clippy/rust-1.39.0/index.html). +This includes all lint groups except for nursery, pedantic, and cargo in addition to allowing the following lints: +`erasing_op`, `never_loop`, `if_same_then_else`. + +If you use rustup, feel free to lint locally, otherwise you can just push to CI for automated linting. + +```bash +rustup component add clippy +cargo clippy +``` + +Significant structures that users persist should always have their serialization methods (usually +`Writeable::write` and `ReadableArgs::read`) begin with +`write_ver_prefix!()`/`read_ver_prefix!()` calls, and end with calls to +`write_tlv_fields!()`/`read_tlv_fields!()`. + +Updates to the serialized format which has implications for backwards or forwards compatibility +must be included in release notes. + Security -------- @@ -89,11 +143,23 @@ Fuzzing is heavily encouraged: you will find all related material under `fuzz/` Mutation testing is work-in-progress; any contribution there would be warmly welcomed. +C/C++ Bindings +-------------- + +You can learn more about the C/C++ bindings that are made available by reading the +[C/C++ Bindings README](lightning-c-bindings/README.md). If you are not using the C/C++ bindings, +you likely don't need to worry about them, and during their early experimental phase we are not +requiring that pull requests keep the bindings up to date (and, thus, pass the bindings_check CI +run). If you wish to ensure your PR passes the bindings generation phase, you should run the +`genbindings.sh` script in the top of the directory tree to generate, build, and test C bindings on +your local system. + Going further ------------- You may be interested by Jon Atack guide on [How to review Bitcoin Core PRs](https://github.com/jonatack/bitcoin-development/blob/master/how-to-review-bitcoin-core-prs.md) and [How to make Bitcoin Core PRs](https://github.com/jonatack/bitcoin-development/blob/master/how-to-make-bitcoin-core-prs.md). -While there are differences between the projects in terms of context and maturity, many of the suggestions offered apply to this project. +While there are differences between the projects in terms of context and maturity, many +of the suggestions offered apply to this project. Overall, have fun :)