Add CONTRIBUTING.md

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