Reviewing Pull Requests

Getting a patch reviewed and landed is a three step process.

A pull request should be created (or refreshed) and assigned (on GitHub) to someone with the appropriate knowledge base to review the code properly. The reviewer selection process is left to the patch creator’s discretion, but there are guidelines listed below. The reviewer should use the GitHub UI to leave any notes or suggestions on the pull request. It is generally recommended that the reviewer checks out the reviewee’s branch to test it manually. This can be done by adding the reviewee’s repository as a remote and simply checking out the pull request branch (further details below).

If the reviewer deems the patch unready to be pulled, he/she should assign the patch back to the reviewee and the process returns to step one.

If the patch is ready to be pulled, it should be labeled ‘Reviewed’ and assigned to the release manager.

The release manager will merge in the patch, label the corresponding issue ‘In-Testing,’ and add a note for testers regarding how to test the change.

Choosing a Reviewer

Generally, patches can be categorized as one of three kinds:
Framework/Backend (rails)
Visualization (coffee script)
User Interface (html, erb, and scss)

Please never review your own patch.

Checking Out a Reviewee’s patch

To set up a remote for the other person, substitute ‘username’ with the reviewee’s GitHub username and use the following:

$ git remote add username https://github.com/username/rSENSE.git

To checkout the reviewee’s branch, substitute ‘username’ with the reviewee’s GitHub username and ‘branchname’ with the name of the branch you are reviewing and use the following:

$ git fetch username
$ git checkout username/branchname