...
Your pull request should address a single issue.
It’s better to split large or complicated PRs into discrete steps if possible. This makes review more manageable and reduces the risk of conflicts with other changes.
Give your pull request a brief title, and use the description to provide key information:
Provide a list of the key changes
If your PR addresses an existing ticket, link to it with “Fixes #123”. This will make it easy to refer back to the original ticket and automatically close it when the PR is merged.
If you’ve discussed the issue, or just want to alert someone to your PR, tag them by including their @username.
Link to relevant resources, such as Wiki pages, mailing list threads, specifications, or other tickets. This makes it easier to understand the full context of your PR.
Please be patient. Your PR may not be reviewed right away, since the people doing code review are often busy, and may be traveling, in a different time zone, or otherwise not available to review your code immediately.
Especially if it’s blocking other work, it’s fine to ask someone to review, either by tagging them in a comment or asking on Slack or at the weekly tech call.
Respond to code review comments, with discussion where it’s appropriate or by pushing additional commits to the branch. They will be added to the same PR automatically.
If another PR is merged and conflicts with your changes, you may need to rebase your PR.
See GitHub’s rebasing documentation and One Commit Per Pull Request for more information on rebasing.
...