Write a generic contribution guide

CONTRIBUTING.md

+# Preparation
+
+- [Upload your SSH public key](https://gitlab.paragon-es.de/profile/keys)
+- Install these tools:
+  - Git
+  - Git Flow
+  - Node
+  - Composer
+- Clone the develop branche of this reporisotry: `git clone -b develop <address>`
+- Initialize your project locally
+  - `composer install`
+  - `composer drupal-scaffold`
+  - `git flow init -d`
+- Configure settings.php for local environment
+  - Define database settings
+  - Define trusted host pattern
+- Setup your web server, the DocumentRoot is the `web` sub-directory of this project
+- Pull the database from live and import into your local database (TODO: this needs further description)
+
+# Configure the Drupal theme
+
+This is only necessary once at the beginning of the project and you should edit the file `composer.json` and especially look into the section `extra/theme-d8-sass/bower_assets`. The two sections `fonts` and `sass` initially contain all available assets. YOu certainly do **not** need them all. That's why you should remove those that you don't require and then call `composer update`. This will then update the theme and all assets making sure that everything stays consistent.
+
+You can also provide a new name to the theme in the composer.json file, this will then create a new directory and you can then delete the old one.
+
+# Workflow
+
+This project uses the [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) workflow which means in short:
+
+We are developping in the `develop` branch (if only one developer is doing something and it is a quick task) or in feature branches (if multiple people are working in parallel or a task takes longer).
+
+How to work with feature branches and how to deploy to the live server, follows below.
+
+Just note that at any time you can switch between branches and do several things with `git checkout <name>`, so that you can work on multiple features in parallel.
+
+## Feature branch naming convention
+
+Below we are using `<name>` as a placeholder for feature branch names and those names will aloways have to be in the format of `issue-#-label` where you have to create an issue on GitLab first and then use the issue number to replace `#` and replace label with a short description of what the feature is all about (only lower case characters, no spaces, try to be shorter than 16 characters).
+
+## Start a new feature
+
+```
+git flow feature start <name>
+git flow feature publish <name>
+```
+
+Then you can start development in that branch and when ever you've completed a step, call `git flow feature publish <name>` again so that it gets pushed to the server. **Motto: push often!**
+
+## Finish a feature
+
+```
+git flow feature finish <name>
+```
+
+Call this only when you're completely done with a feature and code review and tests have been successful. This will then push everything to the server, merge the feature into the `develop` branch and delete the feature branch locally.
+
+## Deploy a new version to the live server
+
+```
+git flow release start <YYYY-mm-dd-hh-mm>
+git flow release finish <YYYY-mm-dd-hh-mm>
+```
+
+This will merge the current version of the `develop` branch into `master` and push that to GitLab. There this will trigger the deployment and you can watch the progress in the pipeline of the project.
+
+# Drupal specific workflow
+
+In general, development always happens locally and content editing happens on the live server. Here is how this workflow is working:
+
+### Prepare local environment
+
+Before developing or changing settings locally, always pull the latest version from the live server. This means you just grab a copy of the database and replace your local one with that dump. (TODO: describe how to do that).
+
+For files (images and documents) please use the stage_file_proxy module, which is already available in this project.
+
+### Push your local changes to the live server
+
+When you've done changes in the configuration locally that need to be deployed, you can call `drush -y cex sync`. This will write the current configuration into the `config/default/sync` directory and you should review the changes and add new files to the git repository.
+
+If everything is OK, commit that to Git just like any other development described in the workflow above and the new settings will be deployed to the server like any other development as well.
+
+### Adding new modules or themes
+
+To add new or update existing projects, use `composer require drupal/<project>`. This will update composer.json and also download everything that's needed for that project, including dependencies.