Workflow.md

+# Motivation
+
+In order to fully use the capabilities of GitLab it is necessary to establish a certain set of prescribed workflow steps with following goals:
+
+* Localized changes (don't change the whole system at once but by parts)
+* Localized notification
+* Localized responsibility
+*
+
+## Localized Change
+
+This does not mean to only change a file, but to have one dedicated issue/merge-request for a concrete problem. Branches will be deleted after merge.
+
+## Localized Notification
+
+By the use of [labels](https://collaborating.tuhh.de/cfg0846/research-topics-mat-tuhh/-/labels), the classification of issues allows to only notify the ones that are needed during the handling of the follow-up merge-request:
+
+### General Labels
+
+These labels should be subscribed by the persons in charge of authorizing new features:
+
+* `feature`
+
+Theses labels are then used to inform the persons in charge about a proposed feature and also to classify the development process as something that is a new addition.
+
+### Technical Labels
+
+Technicians should subscribe to the following labels:
+
+* `bug` (prioritized)
+* `tech-maintenance`
+
+These labels are then specified to inform technical maintainers that something about the webpage, repo does not work as expected or to classify development projects that do not add new functionality (e.g. [code refactoring](https://en.wikipedia.org/wiki/Code_refactoring).
+
+### Redactional Labels
+
+Professors, Chief-Engineers and other people responsible for redactional quality assurance should subscribe to at least one of the following labels:
+
+* `aa-content`
+* `cm-content`
+* `dm-content`
+* `nm-content`
+* `st-content`
+
+These labels are then specified by the users who need quality assurance on their research topic by their supervisor.
+
+# DRAFT: Implementation (open for discussion)
+
+Every user needs (technical or redactional) needs to adhere to the Contribution-Guidelines.
+