Closed GildasMorel closed 4 years ago
For the PR Template i would rearrange the sections to start with requirements and the type of change : this way you can check requirements are fullfilled and you get a quick overview of the goal of the PR (feel free to update the number of items and the order) :
## PR Checklist
Please check if your PR fulfills the following requirements:
- [ ] The commit message follows our guidelines: https://github.com/talk-control/talk-control/blob/master/CONTRIBUTING.md#commit
- [ ] Tests for the changes have been added (for bug fixes / features)
- [ ] Comments have been added only for tricky sections of the code (for bug fixes / features)
- [ ] self review has been performed (for bug fixes / features)
- [ ] New and existing unit tests pass locally with my changes
## PR Type
What kind of change does this PR introduce?
<!-- Please check the one that applies to this PR using "x". -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
- [ ] Code style update (formatting, local variables)
- [ ] Refactoring (no functional changes, no api changes)
- [ ] Build related changes
- [ ] CI related changes
- [ ] Documentation content changes
- [ ] Other... Please describe:
Then i would ask for the description :
## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
Issue Number: N/A
## What is the new behavior?
<!-- If this PR contains a breaking change, please describe the impact -->
## Other information
For the issue template, do you want to stick with a generic one? It might be useful to create one for issues and one for feature requests.
Closes #105