- Short descriptions of your changes are in the release notes
(added as entry in
doc/news/_preparation_next_release.mdwhich contains_(my name)_) Please always add them to the release notes. - Details of what you changed are in commit messages
(first line should have
module: short statementsyntax) - References to issues, e.g.
close #X, are in the commit messages. - The buildservers are happy. If not, fix in this order:
- add a line in
doc/news/_preparation_next_release.md - reformat the code with
scripts/dev/reformat-all - make all unit tests pass
- fix all memleaks
- fix the CI itself (or rebase if already fixed)
- add a line in
- The PR is rebased with current master.
- I added unit tests for my code
- I fully described what my PR does in the documentation (not in the PR description)
- I fixed all affected documentation (see Documentation Guidelines)
- I fixed all affected decisions (see Decision Process)
- I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
- I updated all meta data (e.g. README.md of plugins and METADATA.ini)
- I mentioned every code not directly written by me in reuse syntax
- Documentation is introductory, concise, good to read and describes everything what the PR does
- Examples are well chosen and understandable
- Code is conforming to our Coding Guidelines
- APIs are conforming to our Design Guidelines
- Code is consistent to our Design Decisions
- Add the "work in progress" label if you do not want the PR to be reviewed yet.
- Add the "ready to merge" label if everything is done and no further pushes are planned by you.