Skip to content

Commit

Permalink
add PR template
Browse files Browse the repository at this point in the history
  • Loading branch information
leifdenby committed Dec 9, 2024
1 parent 86aa6c1 commit be3380a
Showing 1 changed file with 52 additions and 0 deletions.
52 changes: 52 additions & 0 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
## Describe your changes

< Summary of the changes.>

< Please also include relevant motivation and context. >

< List any dependencies that are required for this change. >

## Issue Link

< Link to the relevant issue or task. > (e.g. `closes #00` or `solves #00`)

## Type of change

- [ ] 🐛 Bug fix (non-breaking change that fixes an issue)
- [ ] ✨ New feature (non-breaking change that adds functionality)
- [ ] 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] 📖 Documentation (Addition or improvements to documentation)

## Checklist before requesting a review

- [ ] My branch is up-to-date with the target branch - if not update your fork with the changes from the target branch (use `pull` with `--rebase` option if possible).
- [ ] I have performed a self-review of my code
- [ ] For any new/modified functions/classes I have added docstrings that clearly describe its purpose, expected inputs and returned values
- [ ] I have placed in-line comments to clarify the intent of any hard-to-understand passages of my code
- [ ] I have updated the documentation to cover introduced code changes
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] I have given the PR a name that clearly describes the change, written in imperative form ([context](https://www.gitkraken.com/learn/git/best-practices/git-commit-message#using-imperative-verb-form)).
- [ ] I have requested a reviewer and an assignee (assignee is responsible for merging)

## Checklist for reviewers

Each PR comes with its own improvements and flaws. The reviewer should check the following:
- [ ] the code is readable
- [ ] the code is well tested
- [ ] the code is documented (including return types and parameters)
- [ ] the code is easy to maintain

## Author checklist after completed review

- [ ] I have added a line to the CHANGELOG describing this change, in a section
reflecting type of change (add section where missing):
- *added*: when you have added new functionality
- *changed*: when default behaviour of the code has been changed
- *fixes*: when your contribution fixes a bug

## Checklist for assignee

- [ ] PR is up to date with the base branch
- [ ] the tests pass
- [ ] author has added an entry to the changelog (and designated the change as *added*, *changed* or *fixed*)
- Once the PR is ready to be merged, squash commits and merge the PR.

0 comments on commit be3380a

Please sign in to comment.