Peer Review

Overview

You are required to grade and provide feedback on both the .html output and .Rmd syntax files for peer homeworks. After each homework, students will be randomly assigned a homework from a peer and given until the following class meeting to provide peer review. The ability to read and evaluate the work of others is important and useful. A good programmer realizes that most coding problems have been solved by others in the past; the trick is figuring out how to read existing code and apply it to new problems. You will begin to develop this skill by reading others’ code, evaluating their approach to problems, providing suggestions, and pointing out when you learned something new.

Evaluation of Peer Review

For each homework assignment, you will receive either 0 or 1 point for your peer review. 25% of your overall course grade comes from evaluation of peer review. Additionally, failure to complete peer reviews may result in points removed from homeworks.

Good peer reviews:

• Give constructive, polite, and insightful comments
• Are specific and concise
• Use the grading rubric and guidelines below
• Point out where you learned from their code (if you did)

Poor peer reviews:

• Are impolite or unprofessional
• Generic or non-specific; could be applied to anyone’s homework
• Fail to offer praise, show what you learned, or provide useful suggestions

Grading Rubric

Homeworks will be evaluated by peers on a 0 to 3 scale. The overall scores are shown below with example situations in bullets below each.

0: Didn’t turn anything in

1: Turned in but low effort, ignoring many directions

• No attempt made on any one problem.
• Attempts made on all problems but nothing worked
• .html file did not knit / was not provided
• .Rmd file not provided

2: Decent effort, followed directions with some minor issues

• Some code fails to work, but a reasonable attempt was made.
• .html file knitted but is poorly formatted
• .Rmd syntax is disorganized or hard to follow

3: Nailed it

• All problems answered with no errors or omissions
• Code and output are clearly organized
• Clever or elegant possibly solutions used

Some Review Suggestions

These guidelines for reviewing scientific computing code from Andrea Zonca are concise and should be used to direct your feedback.

Coding style should not be the main focus of the review, the most important feedback for the author are high-level comments on software organization. The reviewer should focus on what makes the software more usable and more maintenable.

A few examples:

• can some parts of the code be simplified?
• is there any functionality that could be replaced by an existing library?
• is it clear what each part of the software is doing?
• is there a more straightforward way of splitting the code into files?
• is documentation enough?
• are there some function arguments or function names that could be easily misinterpreted by a user?

The purpose is to improve the code, but also to help the code author to improve her coding skills.

When to Contact the Instructor

A number of situations may warrant contacting the instructor:

1. If you believe you have received an unfair peer review, you can resubmit your homework for evaluation by the instructor. The assignment will be regraded, which may result in a higher, same, or lower grade.
2. If you wish for more feedback on a particular part of the homework, you can ask the instructor for additional explanation without resubmitting during lab or over email.
3. If you receive no feedback, the instructor will provide gentle peer review on request.

Acknowledgements: These peer review guidelines are adapted from Jenny Bryan’s UBC STAT545 course.