Merge branch 'master' into develop

CONTRIBUTING.md

@@ -0,0 +1,34 @@
+# How to contribute
+
+I'm really glad you're reading this, if you are willing to contribute to this project in some form.
+This is a quite small project with relatively low complexity so conventions are not as strict as they might be elsewhere. I am keen to learn whether and how this thing was useful to you, where you had problems and what you think could be improved.
+
+Here are some important resources:
+
+  * This [Blogpost](https://www.commander1024.de/wordpress/2020/03/fotos-mit-daten-zu-radioaktiver-strahlung-taggen) tells you about intention and scope for this tool (in German).
+  * For questions and suggestions, you can [E-Mail](mailto:commander@commander1024.de) me directly.
+  * Bugs? [Gitlab](https://gitlab.warpzone.ms/Commander1024/radiation-tagger/issues) is where to report them.
+
+## Submitting changes
+
+Please send a [GitLab Pull Request to radiation_tagger](https://gitlab.warpzone.ms/Commander1024/radiation-tagger/tree/develop) in the develop branch with a clear list of what you've done (read more about [pull requests](http://help.github.com/pull-requests/)). Please follow our coding conventions (below) and make sure all of your commits are atomic (one feature per commit).
+Keep in mind that I am a bloody beginner and probably make more mistakes than you, so I am always open for improvements.
+
+Always write a clear log message for your commits. One-line messages are fine for small changes, but bigger changes should look like this:
+
+    $ git commit -m "A brief summary of the commit
+    > 
+    > A paragraph describing what changed and its impact."
+
+## Coding conventions
+
+Start reading the code and you'll get the hang of it. We optimize for readability:
+
+  * We indent using 4 spaces (soft tabs).
+  * We use "describing" variables with underscores like 'position_list'.
+  * Classes and functions go to functions.py to keep the main program small and easy to understand.
+  * We generally follow the Python 3 coding style guidelines.
+  * This is open source software. Consider the people who will read your code, and make it look nice for them. It's sort of like driving a car: Perhaps you love doing donuts when you're alone, but with passengers the goal is to make the ride as smooth as possible.
+
+Thanks,
+Commander1024