Pull Request and Issue Labels

You are here: Home > Maintainer Documentation > Pull Request and Issue Labels

---

These are the meaning so labels that should be used to work with issues and pull requests:

Regarding the PR/Issue itself

• question: the issue is a question. add the milestone regarding to the version of the code that is discussed (usually the current open milestone that is closed next or the last stable release's milestone).
• duplicate: the PR/issue itself was is open (in an other). Link the previous one, add the label and close.
• outdated/wontfix: the PR/issue is not up-to-date (concerning old code, etc.) or unfixable (out-of-scope, not in the goals of the project/lib, concepts broadly missing, etc.)
• [WIP] prefix in title: used to signal that the author is still working on it or needs to add/refactor the code during reviews. encourage authors to prefix their PR with [WIP] ... if necessary since they can change this themselves.

Regarding the code/change

• warning: code produces/produced a warning
• bug: a bug in the code
• affects master: a bug that affects the latest stable release
• backported to master: if the patch was backported to create a new stable release (revision), the responsible maintainer sets this flag after the backport
• libPMacc: in libPMacc
• core: in elementary PIConGPU routines (e.g., initalization)
• plugin: in a PIConGPU plugin
• examples: affects a PIConGPU example (or with the libPMacc flag + examples for GoL)
• documentation: regarding documentation or wiki discussions
• refactoring: code change to improve performance or to unify a concept but does not change public API
• tools: scripts and CMake
• backend: bugs or functionality only affecting a subset of the backends
• install: install related questions and issues
• user input: signals changes in user API such as .param files, .cfg syntax, etc. - will be highlighted in the changelog!
• good first issue: only for issues to signal new contributors where they can start

Compatibility

Especially for pull requests, review is faster and focused when some elements are not combined.

The general idea for pull requests is: change one thing at a time and let your patch fit "naturally" into the "surrounding code" in the file. (See more information on reviewing and code style in the other guides.)

The following list is a best-practice to allow fast reviews, possibility for efficient regressions, easy backports and writing of the change log:

Avoid adding a feature and fixing a bug in the same pull request. Bugs fixes are ideally minimal, so one can backport them if needed to older releases. Bug and warning can sometimes show up if it's the same code, but if it's affecting independent code it should be separated. Changes in the PIConGPU core, plugin and libPMacc should be, if not ridiculous, made in separate pulls (tools can always be independent pull requests). If examples are changed, ideally the functionality from it's feature is put in a separeate pull request followed by the "user interface" change that exposes it examples (always make sure that the reference fill in src/picongpu/include/simulation_defines/ are updated, too).