Issue/PR workflow

Handling new issues

New issues do not get an assignee by default.

If you can reproduce a newly reported bug, please remove the unconfirmed label and assign the issue to the milestone of the version in which the bug needs to be fixed (e.g. 4.9). Otherwise, please leave the unconfirmed label in place and add a short comment.

Do not assign feature requests to a milestone.

Handling new PRs

Please assign new PRs to their creator.

After reading a new PR, please label it either as bug or as feature.

If the PR is targeted against an active version branch (e.g. 5.7), please assign it to the corresponding milestone.

Reviewing bug reports

If you can reproduce the bug, please remove the unconfirmed label. If it is unclear how to fix the bug, please add the up for discussion label.

If you want to work on the bug yourself, self-assign the ticket.

If nobody assigns themselves a ticket, it will get the help wanted label to indicate that we are looking for volunteers to complete it.

If the bug cannot be fixed without breaking backwards compatibility, please add the BC break label.

Reviewing feature requests

If it is unclear how to implement the feature, please add the up for discussion label to the ticket. If the feature cannot be implemented without breaking backwards compatibility, please add the BC break label.

Branch naming convention for pull requests

When opening a new PR, please consider the following branch naming convention to make reviewing easier. A proper prefix immediately indicates the type of change that you want to PR:

For bug fixes, use fix/

• e.g. fix/disable-turbo-navigation-on-hover

For new features, use feature/

• e.g. feature/datacontainer_edit_twig_templates

For CI or build-chain relates changes, use ci/

• e.g ci/my-buildchain-fix-or-feature