Project

General

Profile

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: super easy to do, all OS
    allow to do this in a simple way
  • attach a model allowing to reproduce the issue; super easy to do as
    well: just use the "Save" function of AF3... (see FAQ below for NDA problems)
  • make the attached model minimal: having a huge model coming from a
    real use case does not allow to precisely identify the problem
  • doing all the above is the job of the reporter, not of the programmer
    (even if these two persons are the same: remember that you might have to
    understand your own issue after a couple of months - and strugle).

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 an issue, please do the following:
  • provide one or more precise scenario(s) describing the use case for
    the feature:
    1. step-by-step to get the situation where the feature should apply
    2. expected behavior
    3. actual behavior (might be "Nothing")

Write this scenario having in mind that it should be understood by somebody who does not know the feature

  • as for bugs, but only if relevant, provide screenshots and/or models
  • doing all the above is the job of the reporter, not of the programmer
    (even if these two persons are the same: remember that you might have to
    understand your own issue after a couple of months - and strugle).

FAQ

"My model is under NDA"

Having a model under NDA is not an excuse not to provide a
model: rename the model, make it minimal, do whatever is needed but it
is important for tracking that a model allowing to reproduce the issue
is attached to the issue itself so that we do not have to rely on the
issue author (who might be unavailable for whatever reason) to
understand the issue.

Examples

Good

[[https://af3-developer.fortiss.org/issues/1950]]

[[https://af3-developer.fortiss.org/issues/2044]]

Bad

[[https://af3-developer.fortiss.org/issues/2021]]