Anyone is welcome to contribute to Liana regardless of any arbitrary criterion. Contribution are only judged based on their technical relevance and quality.
Note that the development of Bitcoin software requires a high level of rigor, so it could take some time (and backs and forths) to polish a contribution before it's ready for merge.
Most of the communication is done on GitHub or on the #revault IRC channel on
Libera.
If you plan to contribute a non-trivial change, consider discussing it in the IRC channel or in a Github issue before going forward with the implementation.
If you are looking for first time contributions, you can git grep for FIXMEs and TODOs
as well as checking out the good first issues
on the issue tracker.
The codebase is maintained using the "contributor workflow" where everyone without exception contributes patch proposals using "pull requests" (PRs). This facilitates social contribution, easy testing and peer review.
In general, commits should be atomic and diffs should be easy to read. For this reason, do not mix any formatting fixes or code moves with actual code changes. Make sure each individual commit is hygienic: that it builds successfully on its own without warnings, errors, regressions, or test failures.
Commit messages should be verbose by default consisting of a short subject line, a blank line and detailed explanatory text as separate paragraph(s), unless the title alone is self-explanatory. Commit messages should be helpful to people reading your code in the future, so explain the reasoning for your decisions. For more guidelines about writing commit messages, see this blog post.
If your pull request contains fixup commits (commits that change the same line of code repeatedly) or too fine-grained commits, you may be asked to squash your commits before it will be merged.
Patchsets should always be focused. For example, a pull request could add a feature, fix a bug, or refactor code; but not a mixture. Please also avoid super pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult. Instead, prefer opening different focused pull requests.
Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. PR should be reviewed first on the conceptual level before focusing on code style or grammar fixes.
Any new contributed feature must come with tests. Preferably both an integration/functional tests demonstrating its usage in a blackbox manner (for instance calling an RPC command under different conditions), as well as unit tests exercising specific parts of the logic (for instance a database query).
lianad should always compile and pass tests using Rust 1.63. The rationale behind this is
support something reasonable, and preferably supported by all of:
To avoid endless bikeshedding, just use rustfmt.
Clippy is also often your friend.