LogoLogo
  • Start Here
    • Introduction to NCIL
      • Welcome
      • Mission Statement
      • Getting Started
      • Make this handbook better!
  • Policies & Expectations
    • Working in NCIL
      • Aaron's Philosophy on Supervision
      • General Policies
      • Roles & Expectations
        • Interpersonal and Working Relationships
        • Lab Director: Aaron Newman
        • Lab Manager: Cindy Hamon-Hill
        • Collaborators
        • Postdocs
        • Lab Research Assistants
        • Graduate Students
        • Undergraduate Students
      • Work Ethic
        • Vacations & Absences
      • Money
        • Employment
        • Undergraduate Research Awards
        • Graduate Student Funding
    • Communication
      • Basecamp
      • Lab Meetings
      • Communication Among Lab Members
      • Communicating with Research Participants
      • Website & Social Media
      • Meetings with Supervisor
      • Response Times
    • Lab Space and Resources
      • Hours of Operation
        • After-Hours Research
      • Safety
    • Intellectual Property
      • Data
      • Authorship
      • Publishing: Where and When
  • Data Management & Analysis
    • Data Science Tools
      • Jupyter
        • JupyterLab
      • Python
      • R
      • How to set up your computer for NCIL data science
    • Servers & Computers
      • Accounts
      • File Server (NCILNAS)
        • Accessing NCILNAS
      • Compute Server
        • Jupyter
        • VS Code - Setup
        • VS Code - Everyday Use
      • GitHub Copilot
    • Data Analysis
      • Behavioural Data
      • EEG Analysis
      • fMRI Analysis
        • Processing fMRI Data with SPM
        • fMRI Analysis in SPM
      • Power analysis with simR in R
    • Data Management
      • Github
      • Open Science
    • Learn Some Coding
  • How To Run Experiments
    • How to Get a Research Study Started
      • Research Ethics
      • Your Research Protocol
        • Components of a Research Protocol
      • Pilot Testing
    • Running a Participant
      • Communicating With Participants
      • Recruiting
      • Before Each Participant Arrives
      • When a Participant is in the Lab
    • Experiment Programming
      • Stimulus Presentation Programs
      • Brain-Computer Interface Programs (BCI)
      • EEG Trigger Codes
        • Lab Streaming Layer
        • Trigger Code Hardware Setup
        • Timing Test
    • Data Storage & Protection
    • Word Similarity Measures
  • Communicating Science
    • Submitting papers to Aaron for review
    • Lab Meeting Talks
    • Independent Study Course
    • Honours Thesis
      • Getting Started
    • Master's Thesis
    • 😓PhD Dissertation
    • PhD Comps
    • Conferences
    • Publications
    • Reviewing Journal Manuscripts
  • Old
    • VS Code on NCIL server
Powered by GitBook
On this page

Was this helpful?

  1. Communicating Science

Reviewing Journal Manuscripts

PreviousPublicationsNextVS Code on NCIL server

Last updated 5 years ago

Was this helpful?

A routine job for any scientist is acting as a peer reviewer for journals. This is a necessary part of making science work, and any paper you see published has inevitably passed the scrutiny of several reviewers, often over multiple rounds of reviews. People are not paid as reviewers, it's a strictly volunteer gig (which helps in principle to maintain independence), but it is definitely something you can and should put on your CV (as "ad hoc reviewer for..." and the name of the journal - never say what specific paper(s) you reviewed unless it was an open review process).

You also learn a lot about what makes a good (or bad) scientific article by reviewing others' work, and potentially you get to learn cool new stuff before just about anyone else in the world! Since it's a valuable educational opportunity, I typically ask students in the lab to help be review manuscripts. If you are asked, the expectations are that you:

  • read the manuscript

  • submit your first draft review to me, within 7-10 days of receiving it (typically they want reviews within 2 weeks of accepting an assignment)

    • This first draft should be in point form, highlighting what you thought were the 4-6 (or fewer) most significant issues

  • meet with Aaron to discuss your impressions and hear what he thought

  • draft a second version of the review, in full prose format (not point form), integrating Aaron's suggestions

  • Aaron will read, possibly revise, and then submit this. Your name will be mentioned to the editor handling the review, so that your contribution is acknowledged

Tips on Reviewing

You are providing a review of the science, not the writing or grammar. Focus on big issues like experimental design, data analysis, presentation of data, and whether the conclusions are justifiable given the data. See the links below for more info on things to look for.

The sad reality is that bad papers consume way more reviewing time than good ones. However, these should not take over your life. I try not to spend ore than 1-2 hours reviewing a paper; as a newbie you might spend double that (or more, depending on your reading speed) but you should not spend days on this task. Your time is not worth it. So, if there are a lot of issues with the paper, this is where it's most important to identify the biggest ones. If you are recommending rejection of the paper, it's sufficient to identify 1-2 issues that render the paper unpublishable, and not worry about the rest. If the paper is potentially publishable but requires extensive revision, you will need to be more exhaustive in your suggestions, but try to (a) order your comments by priority (biggest issues first); (b) be concise in all your feedback; (c) provide examples (e.g., quotes with page/line numbers) where necessary to make it clear what you're talking about; (d) separate issues by major/minor.

If the writing or grammar are poor, you have to decide if it is so severe a problem as to make it difficult or impossible to understand well enough to review; understandable but in need of editing by a native English speaker; or just sloppy. Your comments should reflect this, but in general you should not identify individual typos or grammatical errors unless there are so few that they seem to have slipped through the cracks of otherwise-good editing.

Here are some other resources. Many of these are from PLoS ONE, but are pretty general except as noted:

  • Peer Review checklist:

  • 10 Tips for Getting Started as a Peer Reviewer:

  • Ten Simple Rules for Reviewers:

  • PLoS ONE reviewer guidelines (specific to that journal):

https://reviewers.plos.org/resources/peer-review-checklist/
https://reviewers.plos.org/resources/10-tips-for-getting-started-as-a-reviewer/
https://journals.plos.org/ploscompbiol/article?id=10.1371/journal.pcbi.0020110
https://journals.plos.org/plosone/s/reviewer-guidelines