CONTRIBUTING file / guidelines

Rough draft to implement #597

Adapting from CC0-licensed
https://github.com/nayafia/contributing-template

CONTRIBUTING.md

@@ -0,0 +1,34 @@
+# Introduction
+
+Thank you for considering contributing to OpenMapTiles. It's people like you that make OpenMapTiles such a great project. Talk to us at the OSM Slack **#openmaptiles** channel ([join](https://osmus-slack.herokuapp.com/)).
+
+Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
+
+OpenMapTiles is an open source project and we love to receive contributions from our community — you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into OpenMapTiles itself.
+
+# Ground Rules
+
+ * Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
+ * Keep feature versions as small as possible, preferably one new feature per version.
+ * Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the [Python Community Code of Conduct](https://www.python.org/psf/codeofconduct/).
+
+# Getting started
+
+1. Create your own fork of the code
+1. Do the changes in your fork
+1. Create a pull request
+
+# Code review process
+
+We all make mistakes and bad coding decisions. So apart from the obvious fixes, all changes must be reviewed by another member of the project. This also helps with the [bus factor](https://en.wikipedia.org/wiki/Bus_factor) -- there should always be another person on the team who knows why a change was made.
+
+For any non-trivial changes, all pull requests must be approved by at least one member of the OpenMapTiles team. Afterwards you can merge the PR if you have the rights, or another person must do it for you.
+
+As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:
+* Spelling / grammar fixes
+* Typo correction, white space and formatting changes
+* Comment clean up
+* Changes to ‘metadata’ files like .gitignore, build scripts, etc.
+* Moving source files from one directory to another
+
+_This policy was adapted from the CC0-licensed [nayafia/contributing-template](https://github.com/nayafia/contributing-template)_