* 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 ~workflow::confirmed.
* Possible solutions are then discussed. If a fix is agreed upon, the bug is mapped to a release, and the ~workflow::planned label is added.
* The issue is open for developers to fix. Once someone is assigned to work on it (or assigns himself/herself), the ~workflow::doing is added.
* Work is done in a [respective branch](Developer/Documentation/Repository-Layout) via 'create branch'.
* Work is done in a [respective branch](/Developer/Documentation/Release-Plan) via 'create branch'.
* When the work is done in the eyes of the assignee, a merge request is added, as well as the label ~workflow::testing, 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 ~workflow::done and we merge to the develop branch. On successful merge into the current release branch, the issue is closed.
