This document defines the checklists for creating and reviewing various types of pull-request (PR).
Also refer to Development, design, and review processes.
Backend pull request checklist
- Do the changes meet the intended purpose described in the feature or story?
- Do the tests reflect the change in behaviour?
- Do the tests describe scenarios that are described in the story or feature?
- Do the tests describe common failure or validation scenarios?
- Has the API changed? (If yes, refer to the interface change checklist.)
- Is the change compatibility breaking? (link to guidance) If yes, refer to the breaking interface change checklist.
- Does the change alter or remove existing requests to other modules, or introduce new requests? (If yes, refer to external requests / dependencies checklist.)
- Do the automated checks pass (e.g. tests, sonar, lint)?
- Does each PR title reference a Jira issue for the correct project (at the beginning of the title)?
- Does that issue have a “Fix Version”?
- Should the implementation version change (link to guidance)?
- Are any of the library dependencies a snapshot or pre-release version?
Interface change checklist
- Do the RAML checks pass (e.g. lint-raml-cop)?
- Do the JSON Schema checks pass (e.g. lint-raml-schema)?
- Has the interface version been updated?
- In the ModuleDescriptor?
- In the interface definition?
- Do new properties follow standards and conventions (see guidance)?
- Does the name describe the property specifically?
- Is the name formatted correctly (e.g. camel case)?
- Do they use the correct types (e.g. ID references should be UUIDs)?
- Are server derived properties marked as read-only?
- Does a new JSON object disallow additional properties?
- Have the examples that are used in the RAML been updated?
- Have the sample / reference records been updated?
- Do new endpoints follow standards and conventions (see guidance)?
- Is the path formatted correctly (e.g. hyphens separating words)?
- Is the endpoint nested within another resource appropriately?
- Does the endpoint have its own permission in the ModuleDescriptor?
- Does that permission exist in the
circulation.all) permission set?
- Does the endpoint have the correct module permissions?
- Are there sample or reference records for the new endpoint?
- Does the change fit in an existing interface or should a new interface be provided?
- Is the current interface too large?
- Do parts of the interface have different reasons to change?
- Is a new endpoint experimental?
Interface compatibility breaking change checklist
Note: Only merge the breaking change pull request when all other compatibility pull requests are also ready to be merged.
- Clearly mark the pull request as “
Do not merge” (i.e. in PR title and description, by Label, or both) until all related PRs are ready.
- Identify modules dependent upon the changed interface:
- Are there Jira issues in the relevant project for each dependent module?
- Do they contain the appropriate level of detail? Which endpoints/schemas changed, etc.
- Do they block the issue which introduces the breaking change?
- Are the Jira tickets under active development?
- If not, contact the project’s PO and make sure that they are aware of the urgency.
- Are pull requests raised to make each impacted module be compatible?
- Have they been approved?
External requests / dependencies checklist
Use this when changes are made to a dependent interface, either when:
- New features (e.g. new properties) of that interface are used;
- Requests are added to, or removed from, the implementation of an endpoint;
- Changes are needed for a breaking compatibility change in the interface.
- Has the interface version been updated in the ModuleDescriptor?
- Is it at least the interface version where the feature was introduced?
- If the new version is a major change, can dual support be offered?
- Are the dependent interface versions provided by another module?
- Are the correct module permissions expressed on each endpoint that uses the interface?
Frontend pull request checklist
TODO: Add content.