Reviewing pull requests
Rules of thumb:
- Use the GitHub review system.
- Review against the Developer Guide criteria.
- Assign one or more of the appropriate
PR: needs *labels when requesting a change.
- Resolve conflicts by rebasing, rather than merging the target branch into the pull request branch.
- Make sure the pull request has the correct number of approvals:
- For simple documentation fixes: one;
- For all other pull requests: two.
- "Squash and merge" commits, ensuring the resulting commit message is consistently formatted:
- Sentence case.
- Update the CHANGELOG directly via the GitHub website for all merged PRs (except documentation changes):
- Create a
## [Head]heading if one does not exist already.
- Create a compare URL for
[Head]heading if one does not exist already. e.g.
- Prefix the item with either: Removed, Changed, Deprecated, Added, or Fixed.
- Order the item within the group by the widest reaching first to the smallest, and then alphabetically by rule name.
- Suffix the item with the relevant pull request number, using the complete GitHub URL so that it works on the website.
- If applicable, lead the item with the name of rule e.g. "Fixed:
unit-blacklistfalse positives for SCSS nested properties".
- Create a
- Lastly, post the item as a comment to the pull request.