Disable fast-fail to let CI actually run even though beta is broken
[rust-lightning] / CONTRIBUTING.md
index e8a57d85f7f7e8a9cebe857f6011e7c84dee6b6d..3cf463ba02e220b7f1e12605398c344fc3d79628 100644 (file)
@@ -30,9 +30,13 @@ 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 context and culture before investing an asymmetric number of hours on
+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.
 
@@ -43,6 +47,8 @@ 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
 ---------------------
 
@@ -69,8 +75,7 @@ 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.30.0 (enforced by our Travis and
-GitHub Actions).
+The Minimal Supported Rust Version is 1.36.0 (enforced by our GitHub Actions).
 
 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.
@@ -108,6 +113,14 @@ 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
 --------