[ci skip]Add pull request template (#264)

.github/pull_request_template.md

@@ -0,0 +1,64 @@
+[//]: # (Adapted from https://github.com/opentripplanner/OpenTripPlanner/blob/dev-2.x/.github/pull_request_template.md)
+
+## PR Instructions
+
+When creating a pull request, please follow the format below. For each section, *replace* the
+guidance text with your own text, keeping the section heading. If you have nothing to say in a
+particular section, you can completely delete the section including its heading to indicate that you
+have taken the requested steps. None of these instructions or the guidance text (non-heading text)
+should be present in the submitted PR. These sections serve as a checklist: when you have replaced
+or deleted all of them, the PR is considered complete.
+
+### Summary
+
+Explain in one or two sentences what this PR achieves.
+
+### Issue
+
+Link to or create an [issue](https://github.com/entur/netex-validator-java/issues) that
+describes the relevant feature or bug. You need not create an issue for small bugfixes and code
+cleanups, but in that case do describe the problem clearly and completely in the "summary" section
+above. In the linked issue (or summary section for smaller PRs) please describe:
+
+- Motivation (problem or need encountered)
+- How the code works
+- Technical approach and any design considerations or decisions
+
+Remember that the PR will be reviewed by another developer who may not be familiar with your use
+cases or the code you're modifying. It generally takes much less effort for the author of a PR to
+explain the background and technical details than for a reviewer to infer or deduce them. PRs may be
+closed if they or their linked issues do not contain sufficient information for a reviewer to
+proceed.
+
+Add [GitHub keywords](https://help.github.com/articles/closing-issues-using-keywords/) to this PR's
+description, for example:
+
+Closes #45
+
+### Unit tests
+
+Write a few words on how the new code is tested.
+
+- Were unit tests added/updated?
+- Was any manual verification done?
+- Any observations on changes to performance?
+- Was the code designed so it is unit testable?
+- Were any tests applied to the smallest appropriate unit?
+- Do all tests
+  pass [the continuous integration service](https://github.com/entur/netex-validator-java/actions)
+  ?
+
+### Documentation
+
+- Have you added documentation in code covering design and rationale behind the code?
+- Were all non-trivial public classes and methods documented with Javadoc?
+
+### Bumping the project version
+
+Versioning should follow [semantic versioning](https://semver.org/).
+In short:
+- Increment the patch version for bug fixes, documentation updates or cosmetic changes.
+- Increment the minor version for added functionalities that do not break backward compatibility.
+- Increment the major version for breaking changes.
+
+