issue labeling scheme
Each pull-request (PR) and issue is labeled along five "dimensions", each with its own color family:
To get an overview of how often each label is used go to the labels page.
Label Rules
- the category letters ensure same order in issue list
- only single label per category is allowed
A component label specifies in which part of NEST the issue is located.
- changes in the NEST kernel
- Documentation updates, fixes, ...
- changes in the build system or CI scripts
- issues regarding the installation of NEST, e.g. on different platforms
- changes in the SLI iterpreter
- new or modified neuron or synapse models
- changes in the high level python interface of NEST
The interface label specifies if and where there are changes for users and/or developers.
- changes to the user interface
- changes to the semantics of parameters or return values, while keeping the same API
- changes in the effect of a method
- external API is what is defined in nest.h
- change that requires users of NEST to change their code accordingly
- internal API is everything that is not external: Typically the kernel interfaces, managers, etc.
- change that modifies the calls to functions not usually handled by users
- NEST developers need to be aware about the new structure/parameters/methods...
- no change to any API that would break existing code
- anything that compiled before should still compile afterwards
The progress label gives information about the status of the issue/PR. The normal work-flow would be pending -> in progress -> PR created (-> closed).
- work on this issue is not possible due to another issue
- blocked by another PR that has to be merged first
- the issue advanced a lot, a solution exists and a corresponding pull request has been created
- someone started and is actively working on this issue
- new issue where no-one has worked on yet
- nothing to be worked on, just to keep in mind. Typically goes together with T:Discussion.
- critical, bugs that need to be fixed asap.
- needs to be fixed before the next release
- default priority for bugs, important enhancements
- default priority for everything but bugs, bugs that appear in very corner cases
The type label specifies what this issue actually describes.
- bugs
- bugs that result from software outside, that we can not fix ourselves / that are beyond our control
- new/added features
- anything that NEST couldn't do before
- refactoring
- cleaning of unused NEST::Names
- ideas, wishlist, everything that needs comments from the community or has to be condensed to a more concrete plan
This scheme was inspired by
