Labels for reporting issues

The following labels are useful to describe the priority of issues as well the area in which the issues apply. Please use those each time you report a new issue.

Workflow (grey tags)

The following labels are used to track issues through their lifecycle. Notice that only **one **of these progress labels should be on the issue at any time:

0. Backlog
1. Planning
2. Ready
3. Working
4. In review: a pull requests for review will be sent

Bugs resolution ( red tags )

These labels help to track how a bug has been resolved (blue colors). Those labels were inspired on documentation from [DOT Net](https://github.com/dotnet/roslyn/wiki/Labels-used-for-issues. Notice that only **one **of these labels should be on the issue at the same time:

• Fixed
• Not applicable: The issue is not relevant to code in this repo and is not an external issue.
• Not reproducible:The developer couldn’t reproduce the bug.
• Wontfix: A real bug, but the issue is not impactful enough to spend time on.
• by Design: The behavior reported in the issue is actually correct.
• Duplicate: An earlier issue is already tracking this behavior (the developer resolving a duplicate should link to the other issue in the text).
• help wanted: issues where contributors can contribute

Issue type (green tags)

• docs: Documentation
• refactor
• feat: A new feature
• test: Adding missing tests or correcting existing tests
• bugs

Scope (pink tags)

name of the module affected

• common
• HLCL
• solver
• dynsup
• gui
• IO
• reasoner
• all: useful for issues that are done across all packages

VariaMos source code knowledge (purple tags)

• beginer: require minimal context and are well-suited for new contributors.
• intermediate
• advanced: require high comprehension of VariaMos architecture and source code.

Priority (blue tags)

We consider everything to have normal priority. So we only define a label to mark things that need immediate attention.

• urgent