Skip to content

Latest commit

 

History

History
89 lines (75 loc) · 3.71 KB

PULL_REQUEST_TEMPLATE.md

File metadata and controls

89 lines (75 loc) · 3.71 KB
Raw

Purpose

Approach

TODOS and Open Questions

Learning

Pre-Merge Checklist:

Before merging this PR, please go through the following list and take appropriate actions.

  • Does this PR meet or exceed the expected quality standards?
    • Code coverage on new code is 80% or greater
    • Duplications on new code is 3% or less
    • There are no major code smells or security issues
  • Does this introduce breaking changes?
    • Were any API paths or methods changed, added or removed?
    • Were there any schema changes?
    • Did any of the interface versions change?
    • Were permissions changed, added or removed?
    • Are there new interface dependencies?
    • There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

  • What other modules will these changes impact?
  • Do JIRAs exist to update the impacted modules?
    • If not, please create them
    • Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
    • Do they have all the appropriate links to blocked/related issues?
  • Are the JIRAs under active development?
    • If not, contact the project's PO and make sure they're aware of the urgency.
  • Do PRs exist for these changes?
    • If so, have they been approved?
  • Did you modify code to call some additional endpoints?
    • If so, do you check that necessary module permission added in ModuleDescriptor-template.yaml file?

Ideally, all the PRs involved in breaking changes would be merged on the same day to avoid breaking the folio-testing environment. Communication is paramount if that is to be achieved, especially as the number of inter-module and inter-team dependencies increase.

While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.