Skip to content

Latest commit

 

History

History
67 lines (57 loc) · 4.82 KB

CONTRIBUTING.md

File metadata and controls

67 lines (57 loc) · 4.82 KB
Raw

Contributing

The XRP Ledger has many and diverse stakeholders, and everyone deserves a chance to contribute meaningful changes to the code that runs the XRPL. To contribute, please:

  1. Fork the repository under your own user.
  2. Create a new branch on which to write your changes. Please note that changes which alter transaction processing must be composed via and guarded using Amendments. Changes which are read only i.e. RPC, or changes which are only refactors and maintain the existing behaviour do not need to be made through an Amendment.
  3. Write and test your code.
  4. Ensure that your code compiles with the provided build engine and update the provided build engine as part of your PR where needed and where appropriate.
  5. Write test cases for your code and include those in src/test such that they are runnable from the command line using ./rippled -u. (Some changes will not be able to be tested this way.)
  6. Ensure your code passes automated checks (e.g. clang-format and levelization.)
  7. Squash your commits (i.e. rebase) into as few commits as is reasonable to describe your changes at a high level (typically a single commit for a small change.)
  8. Open a PR to the main repository onto the develop branch, and follow the provided template.

Major Changes

If your code change is a major feature, a breaking change or in some other way makes a significant alteration to the way the XRPL will operate, then you must first write an XLS document (XRP Ledger Standard) describing your change. To do this:

  1. Go to XLS Standards.
  2. Choose the next available standard number.
  3. Open a discussion with the appropriate title to propose your draft standard.
  4. Link your XLS in your PR.

Style guide

This is a non-exhaustive list of recommended style guidelines. These are not always strictly enforced and serve as a way to keep the codebase coherent rather than a set of thou shalt not commandments.

Formatting

All code must conform to clang-format version 10, unless the result would be unreasonably difficult to read or maintain. To change your code to conform use clang-format -i <your changed files>.

Avoid

  1. Proliferation of nearly identical code.
  2. Proliferation of new files and classes.
  3. Complex inheritance and complex OOP patterns.
  4. Unmanaged memory allocation and raw pointers.
  5. Macros and non-trivial templates (unless they add significant value.)
  6. Lambda patterns (unless these add significant value.)
  7. CPU or architecture-specific code unless there is a good reason to include it, and where it is used guard it with macros and provide explanatory comments.
  8. Importing new libraries unless there is a very good reason to do so.

Seek to

  1. Extend functionality of existing code rather than creating new code.
  2. Prefer readability over terseness where important logic is concerned.
  3. Inline functions that are not used or are not likely to be used elsewhere in the codebase.
  4. Use clear and self-explanatory names for functions, variables, structs and classes.
  5. Use TitleCase for classes, structs and filenames, camelCase for function and variable names, lower case for namespaces and folders.
  6. Provide as many comments as you feel that a competent programmer would need to understand what your code does.

Maintainers

Maintainers are ecosystem participants with elevated access to the repository. They are able to push new code, make decisions on when a release should be made, etc.

Code Review

New contributors' PRs must be reviewed by at least two of the maintainers. Well established prior contributors can be reviewed by a single maintainer.

Adding and Removing

New maintainers can be proposed by two existing maintainers, subject to a vote by a quorum of the existing maintainers. A minimum of 50% support and a 50% participation is required. In the event of a tie vote, the addition of the new maintainer will be rejected.

Existing maintainers can resign, or be subject to a vote for removal at the behest of two existing maintainers. A minimum of 60% agreement and 50% participation are required. The XRP Ledger Foundation will have the ability, for cause, to remove an existing maintainer without a vote.

Existing Maintainers