On this page, we describe the process of creating issues, tagging them with labels and how the workflow differs for different issue types.

Bug Report

When you think you have encountered a bug, you can create an issue of type Bug Report. This requires the following steps:

Create a new issue and choose the Bug Report template in the Description drop down. The template will automatically assign the labels issue-typebug and workflowdiscussion.

The workflow for issues of type bug then is as follows:

graph LR
  discussion --> confirmed
  confirmed --> planned
  planned --> doing
  doing --> testing
  testing --> done

Developers try to reproduce the bug and comment their results accordingly. If the main development team views this as proof of reproducibility, they add the workflow-label workflowconfirmed.
Possible solutions are then discussed. If a fix is agreed upon, the bug is mapped to a release, and the workflowplanned label is added.
The issue is open for developers to fix. Once someone is assigned to work on it (or assigns himself/herself), the workflowdoing is added.
Work is done in a respective branch via 'create branch'.
When the work is done in the eyes of the assignee, a merge request is added, as well as the label workflowtesting, and someone else is assigned, e.g. the bug reporter, for testing. This consists of two parts: First, see whether all automatic tests still work, and second, check (and comment on the issue) whether the bug is resolved. Other developers are open to check for themselves, whether the bug is fixed.
If the bug is indeed fixed, the label switches to workflowdone and we merge to the develop branch. On successful merge into the current release branch, the issue is closed.

Feature-Request

TBD

TBD

TBD

TBD

Please register or sign in to add a comment.