Use peer review to improve the proposal

“Looks good” cannot repair a method mismatch

• A peer reads the materials proposal and writes, “Nice topic and neat layout.” The encouragement is welcome, but it misses a problem: one draft paragraph still says the team will ask whether participants like the labels, while the question concerns sorting accuracy.
• This original GAC033-aligned lesson treats peer review as a reasoned check of the proposal. It is not permission to run a study or a judgement of the author's character. Useful feedback identifies a specific issue and why it matters.

Review the argument before the appearance

• Read in this order: purpose and question, evidence, method, ethics, analysis, feasibility, then clarity and presentation. A well-written sentence can still promise a measure the procedure never collects. Check the connections between sections.
• Apply criteria consistently. Does the background support the question? Is the outcome measurable? Could another helper follow the procedure? Is participation voluntary? Are claims limited to the sample and task? Do not require the team to obtain your preferred result.

Write a comment with a reason and a next step

• Use location → issue → consequence → suggestion. “Method paragraph 2 asks about preference, but the question concerns complete sorting success. This would leave the main question unanswered. Use the four-item task and keep preference, if collected at all, as a separate outcome.”
• Distinguish a necessary correction from an optional idea. Correcting the mismatch is necessary; adding a decorative colour theme is optional. If a detail is genuinely unclear, ask for clarification instead of claiming it is definitely absent from the whole project.

{callout:example} Specific feedback: “The consent script says sheets are anonymous, but the draft sheet asks for names. Remove the name field or explain and justify a different approved data plan; the current versions contradict each other.” {/callout}

Receive criticism without defending every sentence

• Pause and restate the concern before replying. “You noticed that our question and survey measure differ” shows understanding. Ask which part needs clarification and compare the comment with the actual draft, rather than assuming criticism means the project is worthless.
• You need not accept every suggestion. Reject one with a reason tied to scope or evidence: “We will not add a memory test because our question concerns immediate sorting and the extra task would change the approved procedure.” Respectful disagreement is compatible with useful review.

{callout:warn} Peer approval does not replace teacher approval, participant information or source verification. A positive review can still overlook a problem. Keep the relevant checks in the action plan. {/callout}

Make revisions traceable

• Keep a response log showing the comment, decision, change and reason. Mark accepted, partly accepted or not accepted; then identify the revised section. “Done” alone does not tell the reviewer whether the underlying issue was fixed.
• Recheck linked parts after a change. Removing a name field may affect data handling and withdrawal instructions. Changing the outcome requires updating the question and analysis. A revision that fixes one paragraph but leaves contradictions elsewhere is incomplete.

Close the review with a new check

• Give the reviewer the revised version and response log. Ask them to check whether the question, outcome and procedure now match. This is a focused follow-up, not a request to praise the entire project.
• Review a partner's one-page proposal using two substantive comments and one clear strength. Then revise your own draft and record one decision you did not accept, with a defensible reason. Keep all versions labelled so the final presentation uses the approved candidate.

{callout:key} Useful peer review is specific, criteria-based and respectful. A response log connects feedback with a justified revision and a check that the revision solved the problem. {/callout}