Procedure for peer review
In this course each assignment is reviewed by two other colleagues. This implies that you need to review two assignments each week. To arrange this we are going to use the pull requests feature from GitHub. This pull request is where the reviewers place their comments.
Owner of the repo
GitHub classrooms should have automatically created a pull request on the
repository called “Feedback” for you. If not, you will need to create a pull
request from the
empty branch into the
master branch. These are the steps
to do so:
- Go to your repo.
- Click the New pull request button.
- In the next screen, select
emptyas your base branch, and
masteras your compare branch.
- Give it name similar to “Feedback”.
GitHub classrooms will have automatically created a pull request on the repository called “Feedback” (or the owner will do this manually). Each reviewer should place their comments in that pull request. To find it:
- Go to the repo you need to review
- Click on the Pull requests tab
- There you should find the PR titled “Feedback”; click on it
We expect you to do two kinds of reviewing:
General comments about the design and implementation, which should be in the Conversation tab.
An in-depth review of the code. To do this, go to the Files changed tab and select the Unified view. You can place a comment in one line by clicking on the small plus sign which appears when you place your mouse over the line number.
Owners of the repo can reply to those comments, and engage in conversation.
Once your review is finished, send an e-mail to
firstname.lastname@example.org with the grades of the two colleagues you reviewed. Include
a link to the two repositories you reviewed in your email so that we can go to
it directly. You do not need to leave the grade you assign in the
feedback/comments itself. As with the assignments themselves, the peer reviews
are due after one week.
How to write a good review
The main rule is to be constructive. This means that for every issue you find:
- Be clear about which is the problem;
- Explain or point to a possible solution. It is better to suggest improvements to the current code than a whole new approach;
- Distinguish clearly between “I would have done this differently” from “this is wrong or this does not work”;
- Raise questions about unclear parts.
Needless to say, be respectful about your colleagues’ work.
You will be graded on the quality of the feedback given.