· 6 min read

UoPeople Peer Assessment: Grade It Like a Code Review

How I handle UoPeople peer assessment with habits from code review, so each grade is fair, backed by the rubric and quick to write.

UoPeople peer assessment is the task most students treat as a chore. Every week you open three anonymous papers from classmates, pick a score for each rubric item and write a comment. It is easy to rush: give everyone full marks, type "Good job" and move on. That is a mistake, and not only because it is unfair to the person who wrote the paper. Your peer reviews are graded too. I study for a BSc in Computer Science at University of the People while working full-time as a mobile developer, and the thing that made this task fast and fair for me was simple: I grade a paper the way I review a pull request.

How UoPeople peer assessment works

The rules come from the UoPeople catalog. In short:

The key line is the fourth one. Peer assessment is not a favor to your classmates. It is graded work, and the instructor can see whether your scores match the papers.

Why code review is the right model

A code review and a peer assessment ask the same question: does this work do what it was supposed to do? In both, someone else's effort is in front of you, and your job is to judge it against a standard, not against your mood.

Good code reviewers have a few habits:

Each of these maps directly onto a peer assessment. The ticket is the assignment prompt. The diff is the paper. The review checklist is the rubric.

Read the prompt and the rubric first

Before I open the first paper, I read two things: the assignment prompt and the rubric. Then I write a short checklist in my notes. One line per rubric item, in my own words, with what "full marks" means for this assignment.

For a typical written assignment, the checklist can look like this:

1. Answers all parts of the question (a, b, c)
2. Code / pseudocode runs or is correct as written
3. Explains the reasoning, not just the result
4. Word count in range
5. References in APA style, in-text and list

This takes five minutes, and it saves time on every paper after that. Without it, I judge the first paper by gut feeling and then compare the other two against the first. That is the same as reviewing a pull request without reading the ticket: you check the code against your own idea of the feature, not the real one.

Grade each rubric item on its own

The most common mistake is to form one overall opinion and then fill in every item to match it. A paper that "feels good" gets full marks everywhere, a messy one gets low marks everywhere.

Instead, I go through the checklist one item at a time, and for each item I look for evidence in the paper:

This is like a reviewer checking a pull request against the acceptance criteria. A clean diff that skips one requirement is still incomplete. A messy diff that meets every requirement still works. The style issues go into the comment; they do not erase the points the work earned.

It also protects you. If the instructor looks at your score, every point you gave or took away has a reason you can name.

Write comments that point at something

"Great work!" and "Needs improvement" are the review equivalent of "LGTM" on a 500-line diff. They tell the author nothing, and they tell the instructor you did not read closely.

A useful comment has three parts: where, what and how to fix. For example:

Part (b) asks for the time complexity of your solution. The paper gives the code but does not state the complexity. Adding one line, for example "This loop runs n times, so it is O(n)", would cover it.

Some rules I follow:

For an English-language degree with students from many countries, the last two rules matter even more. Many of your classmates write in their second or third language. Grade the content the rubric asks for, and be kind about language that is clear but not perfect.

Be honest about weak and very strong work

Two situations make people uncomfortable, and both have a code review answer.

A weak paper. It is tempting to give a few extra points so nobody feels bad. Do not. The catalog says too-generous reviews lower your own grade, and the author learns nothing. In a code review, approving a broken change does not help the author either; it just moves the bug to production. Give the score the rubric gives, and make the comment helpful enough that the next paper is better.

A very strong paper. Some reviewers feel they must find something wrong to look thorough. That is the reviewer who blocks a good pull request over a variable name. If a paper meets every item, give full marks and say why. That is a correct review.

A suspected plagiarism case. If parts of a paper look copied, do not guess and do not accuse the author in the comment. Follow the instructions in the course and the assessment form for reporting it, and grade what you can see.

Fit it into the week

Peer assessment is carry-over work from the previous week, so it needs its own fixed slot. In my UoPeople study schedule it sits on Sunday, before the new written assignment takes over.

With the checklist ready, three papers stop being an evening task. In my case, the first paper takes the longest, because I am still learning what the strong and weak answers look like. The next two go faster, because the checklist already holds the standard.

There is also a side benefit. Reading three other answers to a question you just answered yourself shows you approaches you did not think of. It is the same reason reviewing other people's code makes you a better developer.

Takeaways