Skip to content

Latest commit

 

History

History
46 lines (25 loc) · 4.34 KB

CONTRIBUTING.MD

File metadata and controls

46 lines (25 loc) · 4.34 KB

Contributing

By contributing code to this project, you affirm that it is your original work and implicitly grant permission for it to be distributed under the AGPL-3.0 license.

Check out our Developer Guide for recommendations on developing with xud.

Read about how you can earn XUC for your contributions in our how-to guide.

Contribution Guidelines

Read the following sections before contributing to xud. If you are new to contributing to open sources projects on GitHub, you can also check out this how-to.

Feature Branches & Pull Requests

We use feature branches for development. Each branch and pull request should focus on a particular feature or issue. Ensure that new branches are created from the latest code in master. A branch must be approved by a user with commit access and must pass automated regression tests and lint checks before it can be merged into master.

Pull requests will be reviewed and changes may be requested. If changes are required, make new commits directly to the feature branch. If there have been conflicting commits to master since a feature branch was created, either merge master into the branch or rebase the branch onto master using git rebase.

When multiple commmits pertain to the same issue or feature, uou should squash then into a single commit or a maintainer will squash them before merging. For more complex pull requests that touch many parts of the code or implement multiple distinct changes to the code, please collapse commits according to their scope and affected changes. This can be performed through an interactive rebase with git rebase -i. Use git commit --amend when fixing minor typos or bugs with the most recent commit. These practices help maintain a clean and coherent commit history while preserving contribution authorship.

Further recommended reading:

Commit Messages

Commit messages should follow the AngularJS Commit Guidelines. The message header should start by specifying the type of change the commit implements, followed by the scope of the change in parentheses, and then a subject message summarizing the change. For example: fix(orderbook): remove orders with 0 quantity. The body of the commit message should elaborate on the changes and explain the motivation for the change.

A git commit template is provided to assist with crafting proper commit messsages. You can enable it by running the following command in the folder where you have cloned xud:

git config commit.template .git-commit-template.txt

Linting & Testing

New test cases are appreciated for any pull requests that changes or adds new functionality. Although the current test suites are in early stages, thorough testing and code coverage is an important long term goal.

All code is linted with eslint using a slightly modified version of Airbnb's typescript style guide. Style rules are enforced with prettier. Ensure that your contributions pass all linting rules by running npm run lint or using a code editor with support for eslint and prettier. Per-line or per-file exceptions to linting rules are allowable in certain cases.

Commenting & Documentation

Make your code legible by using descriptive variable, function, and class names. For blocks of codes, variables, and methods whose purpose is not readily apparent, add comments explaining what they do.

Xud uses TypeDoc and follows the Oracle Javadoc Style Guide - any comments documenting specific classes, methods, properties should follow this convention.