DRAFT: This is a collection of personal recommendations. The workflow is open for discussion!

The workflow within this repository should be driven by Issues (and Incidents). Every series of changes starts by creating an issue.

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 (based on localized (to issue type or chair) responsibility)
• Localized assurance (technical and editorial quality assurance)

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 (Repository setting). There are standard rules about how large commits etc. should be...

Localized Notification and (Quality) Assurance

During creation of an issue, one can optionally choose an Assignee to handle this issue. Furthermore, GitLab-labels can be used for classification and notification: The use of labels during issue creation allows to only notify the ones that are needed during the handling of the follow-up merge-request.

The labels of this repository can be divided into different classes. See here for a list of currently active labels.

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 (Development and standard tasks in order to assure operability that add nono new functionality)
• typo (for marginal changes to existing pages that have already undergone quality assurance)

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).

Editorial Labels

Professors, Chief-Engineers and other people responsible for editorial 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.

Other Labels

New labels can be added by everyone but the subscription needs to be carried out individually. Therefore it is better to reuse existing labels.

DRAFT: Implementation (open for discussion)

[name=Fabian] I think that this should entirely go to Contributing.md.

Every user needs (technical or redactional) needs to adhere to the Contribution-Guidelines.