| ... | ... | @@ -4,28 +4,28 @@ This page shortly lists the available labels and their usage. We categorise labe |
|
|
|
|
|
|
|
This describes the type of issue. At the moment, we have
|
|
|
|
|
|
|
|
* feature-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 `workflow::discussion`) before they're accepted as actual request and are marked as `workflow::planned` and added to a release-milestone.
|
|
|
|
* bug-report: 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 `workflow::confirmed`.
|
|
|
|
* code-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`.
|
|
|
|
* documentation: Requests for extending or improving the documentation in the Wiki (or the DSLs).
|
|
|
|
* help-request: Not really issues, but question for usage of EvoAl. Might turn into documentation later on.
|
|
|
|
* ~"issue-type::feature-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 ~"workflow::discussion") before they're accepted as actual request and are marked as ~"workflow::planned"££ and added to a release-milestone.
|
|
|
|
* ~"issue-type::bug" 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 ~"workflow::confirmed".
|
|
|
|
* ~"issue-type::code-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-type::documentation" Requests for extending or improving the documentation in the Wiki (or the DSLs).
|
|
|
|
* ~"issue-type::help-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:
|
|
|
|
|
|
|
|
* generator: Everything that has to do with data generation or validation.
|
|
|
|
* machine-learning: Everything concerning learning models, serialising or deserialising them, computing goodness-of-fit measures.
|
|
|
|
* optimisation: Everything relating to optimisation algorithms.
|
|
|
|
* core: Everything concerning the main functionality of EvoAl.
|
|
|
|
* ~"component::generator" Everything that has to do with data generation or validation.
|
|
|
|
* ~"component::machine-learning" Everything concerning learning models, serialising or deserialising them, computing goodness-of-fit measures.
|
|
|
|
* ~"component::optimisation" Everything relating to optimisation algorithms.
|
|
|
|
* ~"component::core" Everything concerning the main functionality of EvoAl.
|
|
|
|
|
|
|
|
### Workflow
|
|
|
|
|
|
|
|
Workflow labels describe the current status of the issue in shorthand.
|
|
|
|
|
|
|
|
* discussion: Issues marked as discussion are not yet well-defined or confirmed, and can therefore not be mapped to a milestone.
|
|
|
|
* confirmed: 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.
|
|
|
|
* planned: When an issue is well-defined, it can be moved to a release and is thus marked planned.
|
|
|
|
* doing: To be named `doing`, an issue has to be well-defined, planned and assigned to an assignee.
|
|
|
|
* testing: If applicable (e.g. for feature requests or bugs), issues are tested after they have exited the doing phase.
|
|
|
|
* done: Assignee views this as done, needs four-eye principle to be closed. |
|
|
\ No newline at end of file |
|
|
|
* ~"workflow::discussion" Issues marked as discussion are not yet well-defined or confirmed, and can therefore not be mapped to a milestone.
|
|
|
|
* ~"workflow::confirmed" 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.
|
|
|
|
* ~"workflow::planned" When an issue is well-defined, it can be moved to a release and is thus marked planned.
|
|
|
|
* ~"workflow::doing" To be named ~"workflow::doing", an issue has to be well-defined, planned and assigned to an assignee.
|
|
|
|
* ~"workflow::testing" If applicable (e.g. for feature requests or bugs), issues are tested after they have exited the doing phase.
|
|
|
|
* ~"workflow::done" Assignee views this as done, needs four-eye principle to be closed. |
|
|
\ No newline at end of file |
