diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..62b09b92
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,37 @@
+## 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.
\ No newline at end of file