Merge pull request #678 from rubyforgood/issue-and-pr-templates

Create a new pull request template

.github/PULL_REQUEST_TEMPLATE/pull_request_template.md

@@ -0,0 +1,95 @@
+## Why
+
+<!--
+A summary of what problem this pull request is trying to solve. **Always** include a #reference to an existing issue, which should provide a more detailed explanation of the problem, as well as any discussion about the nature of the problem.
+
+If appropriate, use github's [issue linking keywords](https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) to automatically close any issues that this pull request resolves.
+-->
+
+### Pre-Merge Checklist
+
+**All these boxes should be checked off before any pull request is merged!**
+
+- [ ] All new features have been described in the pull request
+- [ ] Security & accesibility have been considered
+- [ ] All outstanding questions and concerns have been resolved
+- [ ] Any next steps that seem like a good ideas have been created as issues for future discussion & implementation
+- [ ] High quality tests have been added, or an explanation has been given why the features cannot be tested
+- [ ] New features have been documented, and the code is understandable and well commented
+- [ ] Entry added to CHANGELOG.md if appropriate
+
+
+## What
+
+<!--
+A list of the changes included in this pull request. A checkbox list is probably a good choice here, and the boxes should be checked off as tasks are completed. This section may be omitted if the Why section provides enough information and only a few changes were made (eg, for simple bug reports).
+
+Always highlight breaking changes or any changes that effect the behaviour of user facing components of the application
+
+- [ ] Put your changes in a list like this
+- [x] Then you can check them off like this!
+
+
+Also, include screenshots if you can!
+-->
+
+## How
+
+<!--
+Describe how you solved the problem. This is not a replacement for documentation, but should give people context and a high-level understanding of your solution before/without reading your code. In particular, if your solution implements or makes use of any algorithms, protocols or paradigms that some developers may be unfamiliar with (such as using a cryptographic hash function, implementing a particular high performance datastructure or using functional programming concepts, etc) you should mention it here, and ideally one or two links that point people to learning resources. Also, if you found anything difficult, or you feel that your solution is "clever", you should probably talk about it here, and explain what you did.
+-->
+
+### Testing
+
+<!--
+If possible you should add tests to ensure that any changes you make work as expected! Describe the tests you added, or make note of anything you couldn't figure out how to test. You don't need to go into a whole lot of detail (good tests should be pretty self explanatory) but at a minimum make note of where you put any new tests in the code base.
+
+IF YOU CHANGED THE BEHAVIOR OF ANY TESTS THAT WERE PREVIOUSLY IMPLEMENTED ALWAYS MAKE A NOTE OF IT AND DESCRIBE WHAT YOU CHANGED AND WHY!
+-->
+
+
+## Next Steps
+
+<!-- THIS SECTION IS OPTIONAL. DELETE IF NOT USED.
+
+This section is to highlight any ideas you have for how this feature could be extended in the future.
+
+You should also consider adding issues for these next steps
+-->
+
+
+## Outstanding Questions, Concerns and Other Notes
+
+<!-- THIS SECTION IS OPTIONAL. DELETE IF NOT USED.
+
+In particular, you should
+
+Any questions or concerns you were unable to address while implementing this solution. For example, "I've implemented heat vision resistance, but do we expect to be attacked by superman?"
+
+If you find that this section is getting long, or the questions and concerns have a significant impact on the quality of this solution, consider making this a ["draft"](https://github.blog/2019-02-14-introducing-draft-pull-requests/) pull request to ensure that it is not merged until it is ready.
+
+This may be another place where a checklist is a good choice, so people can see which questions have been resolved.
+-->
+
+### Accessibility
+
+<!-- THIS SECTION IS OPTIONAL. DELETE IF NOT USED.
+
+If this change will make any significant changes to either physical accesibility (eg, making the website work better with screenreaders) and technical accesibility (eg, making the website load faster for people with marginal internet), you should explain what they are, and highlight any issues or concerns you might have that haven't been resolved.
+
+-->
+
+
+### Security
+
+<!-- THIS SECTION IS OPTIONAL. DELETE IF NOT USED.
+
+Address how this change will improve/lessen the security of the application - for example, it improves HTML sanatization or opens a new attack surface. Always explain so that developers without a security background can understand. Similarly, address how this change will impact the accessibility of the application. Be sure to address both physical accesibility (eg, making the website work better with screenreaders) and technical accesibility (eg, making the website load faster for people with marginal internet). If you're not sure what to put here, don't worry! Just explain what you can, and make sure to note that you think this issue needs to be reviewed with security & accesibility in mind
+-->
+
+### Meta
+
+<!-- THIS SECTION IS OPTIONAL. DELETE IF NOT USED.
+
+Any additional notes you have regarding your experience working on this pull request as a contributer. If this is very detailed, it would be a good idea to create an issue to address it
+-->