2. Does the code have enough context to be clearly understood?
[!IMPORTANT]
Add a link to the specification document, pointing at the specific section.
Any implementation detail that could be considered idiosyncratic and not direct from the specification, should be
explained.
Always consider what someone new would need to know for the code to make sense, and add this context to it.
3. Who are the specification authors and who is accountable for this PR?
[!IMPORTANT]
Ping the original specification author(s) and add them as reviewers, alongside any other from the engineering team.
You are accountable for the PR and its rapid resolution, so make sure anyone involved is aware and actively
advancing
the review.
4. Is the specification accurate and complete?
[!IMPORTANT]
If not, engage in a conversation directly with the authors, prompting any updates in the document.
You are accountable of this process, and the specification author needs to give priority to unblocking you.
5. Does the implementation introduce changes in the specification?
[!IMPORTANT]
Contact the specification author(s) and engage in the necessary conversation to agree on the proposed
modification/solutions.
Ensure the new changes are on par with the implementation at the end of the process.
The PR should not be merged until parity between implementation and specifications has been reached.
Checklist
[!WARNING]
Do not merge the PR if any of the following is missing:
[ ] 1. Description added.
[ ] 2. Context and links to Specification document(s) added.
[ ] 3. Main contact(s) (developers and specification authors) added
[ ] 4. Implementation and Specification are 100% in sync including changes. This is critical.
1. What does this PR implement?
2. Does the code have enough context to be clearly understood?
3. Who are the specification authors and who is accountable for this PR?
4. Is the specification accurate and complete?
5. Does the implementation introduce changes in the specification?
Checklist