🎉🎉🎉 Yay! Thanks for taking the time to contribute!
This document contains a set of guidelines to help guide you as you get started contributing the XRP Ledger Server. Remember, this is an open source project and these are mostly guidelines, not unbreakable rules. You should use your best judgement and, where you think improvements to this document are necessary, should follow the process outlined below to contribute improvements.
Your contributions to this codebase help improve the XRP Ledger. The XRP Ledger seeks to build a network that is opened to anyone but controlled by no one, and allows for value to move as fast and seamlessly as informatio does today.
The first step is to create a GitHub account, if you don't already have one. GitHub is a web-based collaboration and version control system, that makes it possible for multiple people to work on shared project, like the XRP Ledger Server.
You don't need to pay anything to open a GitHub account; you can sign up at https://github.com/signup/free.
What happens next, depends on what you're trying to do.
ℹ️ Please do not file issues to ask questions. There are better, faster ways to get answers.
If you are believe you've encountered a bug or other issue, we urge you to report it. Using GitHub Issues provides both transparency and tracking, making it easier for everyone to collaborate in fixing bugs and addressing issues.
Before reporting an issue or problem, you should check through existing issues or bug reports, to see if it has already been reported.
Assuming that it has not, you can create a new issue.
ℹ️ While nobody has the ability to prevent the implementation of a new feature or other enhancement, a feature request is just that: a request. Most developers work on what they find interesting. If a particular feature is of interest to you, you may want to consider sponsoring a bounty.
If you want to ask that an existing feature be extended or enhanced, you should first check whether an issue has already been opened (and, perhaps, already been closed) and if not, you should create a new issue.
If you want to propose an entirely new feature, chances are that you will need at least a specification, outling the changes that you propose, which has already garnered support.
At this time, proposals are introduced and discussed in the XRPL-Standards repo.
ℹ️ The bar for new feature proposals is high: new features impose costs on every participant in the XRP Ledger and new feature proposals are unlikely to gather sufficient support unless the benefits outweight the costs.
If you are looking to contribute code, the best place to start is by looking at existing open issues. Whether you are new to programming or new to the XRP Ledger Server codebase, we recommend starting with issues marked with the Good First Issue label.
If you intend to work on a particular issue, you should publicly announce it in the issue itself, so that others know that you're working on it. You can also use the issue to discuss the changes or modifications, solicit feedback and generally interact with other developers about this issue.
Once you have a patch that addresses the issue, you should open a new pull request, which will allow others to review your proposed code changes, make suggestions about potential improvements or point out problems. Depending on the changes you make, the review may take a while; it's just part of the process.
ℹ️ It is always difficult to have our code critiqued, but code review is important to help maintain the quality of the codebase. As you go through code review, remember that we all share a common goal: to improve the codebase.
- Create a branch from where you want to base your work; this will usually be the
developbranch. - Add tests appropriate to your changes and ensure that all tests pass.
- Open a Pull Request
- Each Pull Request should focus on a single issue.
- The Pull Request should have a descriptive message.
- Each commit in the Pull Request should have a good commit message.
If you're looking to contribute documentation for [xrpl.org], then please visit the xrpl-dev-portal repo.
For code documentation, we use Doxygen-style comments, which are automatically processed to generate a searchable, cross-referenced list of classes, structs, functions, enumerations, concepts and more. See: [http://ripple.github.io/rippled/].
But like with all fast-moving projects, that programmer documentation sometimes suffers. So if you're looking to contribute programmer documentation (changes in README files or comments embedded in the code), thank you!
Once you make changes, please feel free to open a pull request, requesting to merge your changes. The process is similar to that described above.