Every GitHub pull request must go through a code review and get approved before it will be merged into the master branch.
Both authors and reviewers need to answer these general questions:
Additionally, we recommend every author to look over your own reviews just before committing them and check if you are following the recommendations below.
We usually check these kinds of things while skimming through
git diff --cached just before committing.
Commit message format:
<component>: This is a short description of the change. If necessary, more sentences follow e.g. to explain the intent of the change, how it fits into the bigger picture or which implications it has (e.g. other parts in the system have to be adapted.) Sometimes this message can also contain more material for reference e.g. benchmark numbers to justify why the change was implemented in this way.
// Prefer complete sentences when possible.
During the review make sure you address all comments. Click Done (reviewable.io) or reply with "Done." (GitHub Review) to mark comments as addressed. There should be 0 unresolved discussions when it's ready to merge.
If you want to address your review to a particular set of teammates, add them as Assignee (righthand side on the pull request). They'll receive an email.
During discussions, you can also refer to somebody using the @username syntax and they'll receive an email as well.
If you want to receive notifications even when you aren't mentioned, you can go to the repository page and click Watch.
As a reviewer you can approve a pull request through two ways:
Pull requests can be merged after they were approved and the Travis tests have passed. External contributions will be merged by a team member. Internal team members can merge their own pull requests.
Most of the bugs the team is working on are tracked internally.
We reference to them as
BUG=######## in commit messages and comments.
External users can ignore these.