Issue Triage

How we triage issues

Before assigning a developer

First response

Bugs

1. Try to reproduce the bug (NOT OPTIONAL), if it is not obvious how, ask the creator of the issue for steps to reproduce.
2. If you can not reproduce it, investigate whether it has already been solved in develop.
3. Comment with whether you managed to reproduce or not (including the steps you took).
4. Think about possible causes / solutions, mention everything in the comments, @mention everyone you think might know more.
5. If possible give an estimate of the time / effort required or ask other devs (@mention).
6. If you know how to solve it and it is easy, assign it to yourself and solve it!
7. Add labels (see next section)

Feature request

1. Make sure the use case for the feature is clear, if it is not, ask for clarification
2. Make sure the feature is limited in scope and it is clearly defined what needs to be implemented.
3. Add an estimate of the effort required in the discussion, or ask people who might know (@mention)
4. Add labels (see next section)

Question

1. Respond to the question, if you don't know the answer, make sure to @mention other devs who might know.

Choosing labels

All issue labels are explained here. In any case it is a good idea to comment on why you attach a specific label.

Issue type

Start by assigning one of the four types: bug, feature request, accepted feature or question. They are mutually exclusive.

The type names should be self-explanatory, but note: do not label a feature request "accepted feature" unless you have time allocated to work on it or you know someone else on the team does. Also make sure the scope and use case of the a feature request are clear before you "accept" it.

If you are not 100% sure, assign the type you thinks fits best and add a comment to the issue's discussion why you think it fits best.

If no type applies, use your own judgement as to whether a new label is required or the issue is not useful at all and should be closed.

Priority

Next, we assign a priority, critical-blocking is only for bugs / missing features that absolutely have to be in the very next release (the blocking refers to both, bugs that block users from working with AiiDA and blocking the next release).

Comment on the issue with why you are assigning this priority.

The priority "nice to have" should be assigned to everything that is not crucial to the stable, reliable and user friendly working of aiida_core.

Priority "quality of life" is for proposed changes that make it easier for developers to work on aiida_core effectively.

Other labels

Attach other labels as you see fit, if it might be helpful at all for whoever might pick up this issue later, comment on why you are attaching labels

Assigning a developer

Only assign one (1) developer. Unless you are already assigned and are planning to collaborate on the issue with other devs.

@mention everyone else who might know more about the issue or be able to take it on.

Closing an issue

Before closing an issue, a label should be attached explaining why, check your options here. In most cases it will make sense to also document your decision in a comment!

Bugs

A bug should be closed by a pull request. Exceptions:

• When a bug has already been fixed but forgotten to close.
• When a bug can not be reproduced by multiple developers and the user reporting it fails to provide additional information. In this case it should be labelled wontfix before closing.

Feature requests

An accepted feature should be closed by a pull request. Exceptions:

• When a feature has already been implemented but forgotten to close.
• When a feature has become obsolete due to changes in design.

A feature request can also be closed after being marked wontfix if the whole team has decided that the feature should not be implemented in the forseeable future.

Questions

A question should be closed once it is too outdated. No label is required, however a comment with the reason should be left.