Skip to content

Labels

Labels

The current list of labels are here. They can be used for Issues, PRs, or both. We use auto to automate our semantic versioning and Pypi upload, so it's extremely important to use the right PR labels!

Issue & PR labels

  • Documentation Improvements or additions to documentation. This category includes (but is not limited to) docs pages, docstrings, and code comments.

  • Duplicate Whatever this is, it exists already! Maybe it's a closed Issue/PR, that should be reopened.

  • Enhancement New features added or requested. This normally goes with a minormod label for PRs.

  • Outreach As part of the scientific community, we care about outreach. Check the relevant section about it, but know that this Issue/PR contains information or tasks about abstracts, talks, demonstrations, papers.

  • Paused Issue or PR should not be worked on until the resolution of other issues or PRs.

  • released This Issue or PR has been released.

  • Testing This is for testing features, writing tests or producing testing code. Both user testing and CI testing!

  • Urgent If you don't know where to start, start here! This is probably related to a milestone due soon!

Issue-only labels

  • BrainHack This issue is suggested for BrainHack participants!

  • Bug Something isn't working. It either breaks the code or has an unexpected outcome.

  • Community This issue contains information about the physiopy community (e.g. the next developer call)

  • Discussion Discussion of a concept or implementation. These Issues are prone to be open ad infinitum. Jump in the conversation if you want!

  • Good first issue Good for newcomers. These issues calls for a fairly easy enhancement, or for a change that helps/requires getting to know the code better. They have educational value, and for this reason, unless urgent, experts in the topic should refrain from closing them - but help newcomers closing them.

  • Hacktoberfest Dedicated to the hacktoberfest event, so that people can help and feel good about it (and show it with a T-shirt!). Such commits will not be recognised in the all-contributor table, unless otherwise specified.

  • Help wanted Extra attention is needed here! It's a good place to have a look!

  • Refactoring Improve nonfunctional attributes. Which means rewriting the code or the documentation to improve performance or just because there's a better way to express those lines. It might create a majormod PR.

  • Question Further information is requested, from users to developers. Try to respond to this!

  • Wontfix This will not be worked on, until further notice.

PR-only labels

Labels for semantic release and changelogs

  • BugFIX These PRs close an issue labelled Bug. They also increase the semantic versioning for fixes (+0.0.1).

  • dependencies Pull requests that update a dependency file

  • Documentation See above. This PR won't trigger a release, but it will be reported in the changelog.

  • Majormod These PRs call for a new major release (+1.0.0). This means that the PR is breaking backward compatibility.

  • Minormod This PR generally closes an Enhancement issue. It increments the minor version (0.+1.0)

  • Minormod-breaking This label should be used during development stages (<1.0.0) only. These PRs call for a new minor release during development (0.+1.0) that will break backward compatibility.

  • Internal This PR contains changes to the internal API. It won't trigger a release, but it will be reported in the changelog.

  • Testing See above. This PR won't trigger a release, but it will be reported in the changelog.

  • Skip release This PR will not trigger a release.

  • Release This PR will force the trigger of a release.

Other labels

  • Invalid: These PRs don't seem right. They actually seem so not right that they won't be further processed. This label invalidates a Hacktoberfest contribution. If you think this is wrong, start a discussion in the relevant issue (or open one if missing). Reviewers are asked to give an explanation for the use of this label.

Good First Issues

Good First Issues are issues that are either very simple, or that help the contributor get to know the programs or the languages better. We use it to help contributors with less experience to learn and familiarise with Git, GitHub, Python3, and physiology. We invite more expert contributors to avoid those issues, leave them to beginners and possibly help them out in the resolution of the issue. However, if the issue is left unassigned or unattended for long, and it's considered important or urgent, anyone can tackle it.