Skip to content

Latest commit

 

History

History
70 lines (52 loc) · 3.42 KB

pull_request_template.md

File metadata and controls

70 lines (52 loc) · 3.42 KB

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. As of 2021, most regular OTP contributors participate in our twice-weekly conference calls. For all but the simplest and smallest PRs, participation in these discussions is necessary to facilitate the review and merge process. Other developers can ask questions and provide immediate feedback on technical design and code style, and resolve any concerns about long term maintenance and comprehension of new code.

Summary

Explain in one or two sentences what this PR achieves.

Issue

Link to or create an issue 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 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 ?

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?
  • Were any new configuration options added? If so were the tables in the configuration documentation updated?

Changelog

The changelog file is generated from the pull-request title, make sure the title describe the feature or issue fixed. To exclude the PR from the changelog add the label skip changelog to the PR.

Bumping the serialization version id

If you have made changes to the way the routing graph is serialized, for example by renaming a field in one of the edges, then you must add the label bump serialization id to the PR. With this label Github Actions will increase the field otp.serialization.version.id in pom.xml.