Check-list for New Issues
=========================

**Just like for good code practice, always keep in mind that an issue
has to be understandable either by somebody else or by yourself in a
couple of months.**

Bugs
----

For bugs, the person in charge of solving it should be able to
understand what the reporter meant; similarly for the person in charge
of closing a resolved bug.

Therefore, when filling up a **bug**, please do the following:

\* state precisely how to reproduce the issue; such a description should
contain the following information:

1.  **step-by-step to reproduce**
2.  **expected behavior**
3.  **actual behavior**

-   attach a screenshot of the buggy behavior
-   attach a af3 model allowing to reproduce the issue
-   make the attached model minimal: having a huge model coming from a
    real use case makes it hard to precisely identify the problem

Features
--------

For features, the person in charge of testing the feature or closing the
issue should be able to understand what the reporter (who is often the
same person as the reporter) meant.

Therefore, when filling up a **feature** issue, please do the following:

\* provide one or more precise scenario(s) describing the use case for
the feature:

1.  **feature description** step-by-step to get the situation where the
    feature should apply
2.  **expected behavior**
3.  **actual behavior** (if not neccessary, just put “Nothing”)

Examples
--------

Good
====

[Issue 1950](https://git.fortiss.org/af3/af3/-/issues/1950)

[Issue 2044](https://git.fortiss.org/af3/af3/-/issues/2044)

Bad
===

[Issue 2021](https://git.fortiss.org/af3/af3/-/issues/2021)