From 33620e0638e998f4bd30e875eeb3ada20f6c9e59 Mon Sep 17 00:00:00 2001 From: Alexis Sellier Date: Mon, 21 Jun 2021 10:06:33 +0200 Subject: [PATCH] Add CONTRIBUTING.md --- CONTRIBUTING.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..e76f501c9 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,74 @@ +# CONTRIBUTING + +Contributions are very welcome. When contributing code, please follow these +simple guidelines. + +* Make sure you run `npx eslint .` to check for code formatting problems. + You can use the `--fix` flag to automatically fix any issues the linter catches. +* Before adding any code dependencies, check with the maintainers if this is okay. +* When using configuration parameters, eg. API URLs, API tokens or contract addresses, + add them to `config.json` and pass the `Config` object to functions that require + access to this configuraiton. +* Write properly formatted comments: they should be english sentences, eg: + + // Return the current UNIX time. + +* Make sure all commits are signed off, using `git commit -s`. +* Follow the guidelines when proposing code changes (see below). +* Write properly formatted git commits (see below). +* Read the DCO. + +Proposing changes +----------------- +When proposing changes via a pull-request or patch: + +* Isolate changes in separate commits to make the review process easier. +* Don't make unrelated changes, unless it happens to be an obvious improvement to + code you are touching anyway ("boyscout rule"). +* Rebase on `master` when needed. +* Keep your changesets small, specific and uncontroversial, so that they can be + merged more quickly. +* If the change is substantial or requires re-architecting certain parts of the + codebase, write a proposal in english first, and get consensus on that before + proposing the code changes. + +Writing Git commit messages +--------------------------- +A properly formed git commit subject line should always be able to complete the +following sentence: + + If applied, this commit will _____ + +For example, the following message is well formed: + + Add support for .gif files + +In addition, it should be capitalized and *must not* include a period. + +When it comes to formatting, here's a model git commit message[1]: + + Capitalized, short (50 chars or less) summary + + 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. + + Write your commit message in the imperative: "Fix bug" and not "Fixed bug" + or "Fixes bug." This convention matches up with commit messages generated + by commands like git merge and git revert. + + Further paragraphs come after blank lines. + + - Bullet points are okay, too. + + - Typically a hyphen or asterisk is used for the bullet, followed by a + single space, with blank lines in between, but conventions vary here. + + - Use a hanging indent. + +--- + +[1]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html