diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 000000000..8a41e733e
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,55 @@
+# User
+
+Before you open a new issue, please search for older ones that cover the same issue.
+In general "me too" comments/issues are frowned upon.
+You can add a :+1: emoji to the issue if you want to express interest in this.
+
+# Developer
+
+We use `clang-format` version `3.8` to consistently format the code base. There is a helper script under `scripts/format.sh`.
+
+In general changes that affect the API and/or increase the memory consumption need to be discussed first.
+Often we don't include changes that would increase the memory consumption a lot if they are not generally usable (e.g. elevation data is a good example).
+
+## Pull Request
+
+Every pull-request that changes the API needs to update the docs in `docs/http.md` and add an entry to `CHANGELOG.md`.
+Breaking changes need to have a BREAKING prefix. See the [releasing documentation](docs/releasing.md) on how this affects the version.
+
+Early feedback is also important.
+You will see that a lot of the PR have tags like `[not ready]` or `[wip]`.
+We like to open PRs as soon as we are starting to work on something to make it visible to the rest of the team.
+If your work is going in entirely the wrong direction, there is a good chance someone will pick up on this before it is too late.
+Everyone is encouraged to read PRs of other people and give feedback.
+
+For every significant code change we require a pull request review before it is merged.
+If your pull request modifies the API this need to be signed of by a team discussion.
+This means you will need to find another member of the team with commit access and request a review of your pull request.
+
+Once your pull request is reviewed you can merge it! If you don't have commit access, ping someone that has commit access.
+If you do have commit access there are in general two accepted styles to merging:
+
+1. Make sure the branch is up to date with `master`. Run `git rebase master` to find out.
+2. Once that is ensured you can either:
+  - Click the nice green merge button (for a non-fast-forward merge)
+  - Merge by hand using a fast-forward merge
+
+Which merge you prefer is up to personal preference. In general it is recommended to use fast-forward merges because it creates a history that is sequential and easier to understand.
+
+# Maintainer
+
+## Doing a release
+
+There is an in-depth guide around how to push out a release once it is ready [here](docs/releasing.md).
+
+## The API
+
+Changes to the API need to be discussed and signed off by the team. Breaking changes even more so than additive changes.
+
+## Milestones
+
+If a pull request or an issue is applicable for the current or next milestone, depends on the target version number.
+Since we use semantic versioning we restrict breaking changes to major releases.
+After a Release Candidate is released we usually don't change the API anymore if it is not critical.
+Bigger code changes after a RC was released should also be avoided.
+