The following sections provide guideance on how to review a release PR / issue
...
- API definition files
- commonalities
- availability of linting report
- ICM
- versioning (checked in yaml)
- documentation (beyond in-line)
- check for Telco jargon / abbeviations
- user stories
- basic test files (for M3)
- is it necessary for a Feature to reference the API version ? as it is anyway in the same release package ?
- cover 200 response and all error responses (tbc)
- enhanced test files (for M4)
- all all error responses shall be covered by M4
- add guideline to use error codes in scenario names ?
- release numbering
- changelog
- certification - for stable public APIs
...
- if you see a release PR that is nearly ready, add a comment as follows: "Please add @release-management_maintainers to this PR once the PR is ready"