Create CONTRIBUTING.md

CONTRIBUTING.md

@@ -0,0 +1,38 @@
+
+## Contribution Guidelines
+
+👉 Please start by reading our guidelines here: https://kleros.gitbook.io/docs/contribution-guidelines/overview
+
+## Opening an issue
+
+You should usually open an issue in the following situations:
+
+* Report an error you can’t solve yourself
+* Discuss a high-level topic or idea (for example, community, vision or policies)
+* Propose a new feature or other project idea
+
+### Tips for communicating on issues:
+
+* **If you see an open issue that you want to tackle,** comment on the issue to let people know you’re on it. That way, people are less likely to duplicate your work.
+* **If an issue was opened a while ago,** it’s possible that it’s being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
+* **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
+
+## Opening a pull request
+
+You should usually open a pull request in the following situations:
+
+* Submit trivial fixes (for example, a typo, a broken link or an obvious error).
+* Start work on a contribution that was already asked for, or that you’ve already discussed, in an issue.
+
+A pull request doesn’t have to represent finished work. It’s usually better to open a *draft* pull request early on, so others can watch or give feedback on your progress. Just mark it as a “WIP” (Work in Progress) in the subject line. You can always add more commits later.
+
+As a contributor who is not an organization member, here’s how to submit a pull request:
+
+* **Fork the repository** and clone it locally. Connect your local to the original repository by adding it as a remote. Pull in changes from this repository often so that you stay up to date so that when you submit your pull request, merge conflicts will be less likely.
+* **Create a branch** for your edits.
+* **Reference any relevant issues** or supporting documentation in your PR (for example, “Closes #37.”)
+* **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
+* **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don’t break the existing project.
+* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+
+If you are an organization member, a branch can be created directly in this repository, there is no need to fork it.