Reviewer handbook

Becoming a reviewer

Reviewer is a capability added to an ordinary account, so you keep publishing your own work while you review. Applications are read by a human — there is no automatic approval.

1. 1

   Sign in, then apply

   Applications are tied to your account, so you need to be signed in. Open the reviewer application.

2. 2

   Tell us what you actually work on

   Pick your research areas from the list — EEG, fNIRS, EMG, MEG, motor imagery, P300, SSVEP, neurofeedback, deep learning, signal processing, feature extraction, clinical BCI, rehabilitation, cognitive neuroscience. These become your expertise tags, and they are what reviewer matching reads.

3. 3

   Write the motivation properly

   A short statement of why you want to review and what you can judge competently. It is the part the decision actually turns on. Optional links — publications, GitHub, ORCID — help.

4. 4

   Accept the reviewer agreement

   Confidentiality, conflicts of interest, and conduct. You must accept it to submit, and it binds you for every review you take.

5. 5

   Wait for the decision

   Applications are reviewed manually and answered by email, usually within a few days. One pending application at a time.

What you are eligible for

Doing a review

1. 1

   Join the stage

   Joining is what puts the submission in your queue and starts the clock. It is idempotent — joining twice does nothing extra. A due date is set from the stage SLA.

2. 2

   Decide whether to claim the decision

   Each stage has exactly one decision owner. Claim it if you intend to carry the outcome; leave it if you are contributing an opinion. Claiming is race-safe, so a lost race is reported cleanly rather than producing two owners.

3. 3

   Declare any conflict

   Shared supervisor, same lab, direct competitor, prior collaboration — declare it. Declarations are recorded against the review, and clearing one later is recorded too.

4. 4

   Work through the checklist

   The guidance checklist is per reviewer and per version. It never decides anything on its own; it exists so nothing obvious gets skipped, and the decision owner can see the checklists of everyone on the stage before deciding.

5. 5

   Comment

   Use the comment type deliberately — general, minor issue, major issue, approval, or rewrite request — and anchor comments to the specific part of the work where you can. Comments start internal to the review team; share the ones the author needs.

6. 6

   Record the decision

   Decision owners only. One of approved, changes_requested, or rejected, with a note. Recording it completes your participation and writes to the permanent decision log.

What your approval triggers

• Below the stage quorum, the submission holds where it is and waits for the other reviewers.
• At quorum with a later stage, it advances and that stage's reviewers are notified.
• At quorum on the last stage, the submission is approved and the study is published.
• changes_requested hands it back to the author, who resubmits into this same stage.
• rejected closes the submission.

Conduct and confidentiality

Everything under review is confidential

Do not circulate, reuse, or act on unpublished material you see as a reviewer, including data, code, and results.

Review the work, not the author

Comments should be specific and actionable. "The split policy is not stated, so leakage cannot be ruled out" is useful; "this is sloppy" is not.

Declare conflicts early

Before commenting, not after a decision is questioned.

Internal is for deliberation, not concealment

Anything the author needs in order to fix the work should be shared. Sharing and unsharing are both audited.

Blind means blind both ways

On a blind pipeline the author sees you as a numbered label. Do not defeat it by identifying yourself in a shared comment.

Load, deadlines, and metrics

• Your queue shows every active participation with its due date and how long it has been open.
• An overdue sweep notifies you and reports aging reviews to administrators. Nothing is decided on your behalf.
• Your reviewer metrics — volume, turnaround, decisions — are visible to you, and inform pool membership.
• If your workload changes, ask an administrator to adjust your maximum active load rather than silently going quiet.
• Review history can be exported as JSON or CSV, which is what you want when writing a service statement for a promotion file.

Team admins are not global reviewers

A team administrator can comment on work authored by their own team members, but those comments are always internal and they cannot approve, reject, or publish anything. Sharing comments with an author and moving a study through review are reserved for reviewers and administrators.

Credit

Completing a stage on a submission that goes on to publish adds you to its contributor list with your role and stage — under your anonymised label if the pipeline was blind. Reviewers also appear in the public reviewer directory and on the community leaderboard.

Related