This page shortly lists the available labels and their usage. We categorise labels into three groups: issue-type, workflow, and component. If possible, every issue should contain one label of each group (there may be reasons to do otherwise, but consider this as general idea.
Issue-Type
This describes the type of issue. At the moment, we have
-
issue-typefeature-request A new functionality for EvoAl. Issues of this type should conform to the corresponding template
feature-request. Feature requests are first discussed and possibly refined (staying in workflowdiscussion) before they're accepted as actual request and are marked as workflowplanned and added to a release-milestone. -
issue-typebug A bug can be reported via the template
bug-report. If its description is complete and the error can be reproduced, we'll add the label workflowconfirmed. -
issue-typecode-quality Tasks to improve code quality, like the addition of tests or reworkings for code-quality improvement can be issued via using the template
code-quality. - issue-typedocumentation Requests for extending or improving the documentation in the Wiki (or the DSLs).
- issue-typehelp-request Not really issues, but question for usage of EvoAl. Might turn into documentation later on.
Component
This describes the main component of EvoAl that is affected by the issue. It has no greater effect but supports with collecting open issues on the same component. We mainly differentiate four components:
- componentgenerator Everything that has to do with data generation or validation.
- componentmachine-learning Everything concerning learning models, serialising or deserialising them, computing goodness-of-fit measures.
- componentoptimisation Everything relating to optimisation algorithms.
- componentcore Everything concerning the main functionality of EvoAl.
Workflow
Workflow labels describe the current status of the issue in shorthand.
- workflowdiscussion Issues marked as discussion are not yet well-defined or confirmed, and can therefore not be mapped to a milestone.
- workflowconfirmed At the moment, this is usually only used for bugs, and is added as soon as there is enough information present to reproduce and thus confirm the bug.
- workflowplanned When an issue is well-defined, it can be moved to a release and is thus marked planned.
- workflowdoing To be named workflowdoing, an issue has to be well-defined, planned and assigned to an assignee.
- workflowtesting If applicable (e.g. for feature requests or bugs), issues are tested after they have exited the doing phase.
- workflowdone Assignee views this as done, needs four-eye principle to be closed.