You should:
- use GitHub reviews
- review against the Developer guide criteria
- resolve conflicts by rebasing
- assign zero or more
pr: *
labels
You should not use any:
- other labels
- milestones
When merging a PR, you should:
- Use your judgment for the number of approvals needed:
- one approval is usually fine for simple fixes
- two approvals are often useful for bigger changes
- If applicable, add a changeset using the GitHub interface:
- prefix the entry with either: "Removed", "Changed", "Deprecated", "Added", "Fixed" or "Security"
- if applicable, lead with the name of the rule, e.g. "Fixed:
unit-disallowed-list
false positives for custom properties".
- "Squash and merge" commits ensuring the resulting commit message:
- either matches the changeset entry but in the present tense, e.g. "Fix
unit-disallowed-list
false positives for custom properties" - or is in sentence case and descriptive, e.g. "Refactor
colour-no-named
to use new AST"
- either matches the changeset entry but in the present tense, e.g. "Fix