Firstly, thanks for wanting to help with the development of the KORD protocol. All contributions, code or documents, should come from a forked version of the respective repository. Then the proposed changes must be submitted via a pull request to the master branch. All pull requests must be reviewed by the maintainers of the repository in question. Once a pull request has been reviewed & approved; you should merge and rebase, and then delete the branch. GitHub keywords should be used when closing pull requests and issues.
If you wish to submit more substantial changes or additions, please see the feature contributions section below.
Branches should be named with a brief semantic title. Commit messages should be capitalised and follow these rules:
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: #1, #2
A properly formed Git commit subject line should always be able to complete the following sentence:
If applied, this commit will Your subject line here
Please refer to this guide for additional information.
For the submission of more substantial changes or additions, an issue should be opened outlining what is being proposed for implementation. The title of the issue should be descriptive and brief, follow the same rules as a commit message, as outlined above. The body of the issue should detail the reasoning for the need of the work to be carried out and the desired outcome.
All Javascript must be formatted with ESLint using the JAAK configuration.
Go code should match the output of gofmt -s.
Go code should be documented by following the official Go commentary guidelines.
All Solidity files must follow the style guide found here.