GitHub released in February a new functionality that the community has been asking for years. It’s now possible to set up templates for issues and pull requests!
Implementing these new templates is quite easy.
.github folder in the root directory of your project.
cd ../path/to/your/project mkdir .github
Add a PULL_REQUEST_TEMPLATE.md or/and ISSUE_TEMPLATE.md in the .github folder you’ve just created.
cd .github vim PULL_REQUEST_TEMPLATE.md # your template for PRs vim ISSUE_TEMPLATE.md # your template for issues
Here is an example of what your pull request template might look like:
## Link to the user story [ ]( ) ## Screenshots ## Types of changes - [ ] Bug fix - [ ] New feature - [ ] Breaking change ## Maintainability & Security - [ ] The feature is tested - [ ] My PR complies with the security checklist - [ ] The code coverage is higher than 80% ## Coding Style - [ ] Functions are no longer than 30 lines - [ ] Each function is only performing one task - [ ] Files are no longer than 200 lines <!-- You can add as many items as you like. Your imagination is the limit. -->
If you feel like you can get easily bored by this task, you might want to use this bookgame 😉.
Commit, push and that’s it, you are ready to go 😃. Now each time a contributor will open a pull request or an issue on your project, the body of their request will be pre-filled with the template you’ve created.
It is so easy to implement, that it seems to be a little thing. It can actually make both your life and those of your contributors easier:
- Your contributors will know exactly what information they have to give you and what actions they have to perform in order to see their request treated.
- Your contributors know the standards they must follow therefore it increase the code quality of your application.
- You will be able to assess how much time you will have to spend on the request without having to put extra effort looking for the information you need.
At Theodo we are quite fond of this new feature since it helps us constantly improving the quality of our work. For instance, we’ve noticed that functionalities have often been refused by our product owner for the same reason (e.g. we didn’t follow the wireframe). We added an item to the checklist prevent this reason from appearing again. In our case, it was “I have checked that the functionality complies with the wireframes”. Thanks to the template we never forget to follow the wireframe thus never waste the time of our product owner with this problem anymore. That’s why templates are a good way to increase the value we bring to our clients.