It is the role of the Handling Editor to assign peer-reviewers to a submission and make a recommendation for publication to the Editor-in-Chief. Handling Editor's are assigned by the Editor-in-Chief and are expected to take on the assigned submission barring any conflict of interest or major issue preventing a timely review. The Handling Editor will carefully review the work and determine if the work is ready for peer-review. If accepted for peer-review, the Handling Editor will select reviewers until two-three reviews are received.
Handling Editors should also be familiar with Aperture Neuro's Code of Conduct as well as the Author Guidelines.
Aperture Neuro reviewers are asked to complete a review of a submission within three-weeks. If a reviewer needs more time, the Journal Manager(s) will work with these on a case-by-case basis. All Aperture Neuro Reviewers and Editors must log in to the submission platform with their Orcid ID and create a profile, this is how reviewers will be assigned submissions.
Reviewers will be able to attach their comments via a docx file or PDF or in the platform and reviewers can go into as much details as needed. Reviewers will be able to chat with the editorial team within the platform and leave confidential comments to the editorial team.
Aperture Neuro encourages an open peer-review process, but reviewers are able to remain anonymous to the author after publication.
For further questions about Aperture's review process, please contact the Journal Manager.
Aperture Neuro welcomes code submissions and criteria for reviewing these are as follows:
- Reviewers are encouraged to provide their main impression of the software, including whether it is in line with the mission of Aperture (including quality and impact of submissions), and whether it adds to an already existing software base.
- Reviewers are invited to summarize the aim and context of the software in a short paragraph. This shows the editor they have read and understood the software submission.
- Reviewers should make an assessment of the software and whether it follows the intended scope of the Software submission as expressed in the comprehensive summary. For example, if authors claim that the code is readable and generally applicable, the reviewers are tasked to assess these claims.
- The reviewer should download, install, and execute the code and test it in reasonable scenarios. The reviewer is not required to read every line of code. However, the reviewer is welcome to assess any parts of the software as they feel necessary.
- Reviewers should assess both the technical soundness as well as the scientific appropriateness of the implemented algorithms.
- Reviewers are allowed to comment on the coding style, keeping in mind that individual programmers might have different coding conventions. It is possible that inelegant code can still have great value if it performs a certain function well.
- Reviewers are invited to comment on the level of documentation, presence of developer guidelines (for new contributions), ease of extensibility, and/or whether the code has high (or low) efficiency (e.g., execution time, CPU usage, RAM usage, etc.). However, reviewers should bear in mind that code may have substantial value even if it is not doing its very best on one or more of these factors.
- Reviewers should not feel responsible to look for bugs in the software. However, if bugs are identified, they can be reported to the authors. If the general code is sound, but let down by too many bugs for general applications, recommend to the editor that the author(s) have their code validated on more test cases.
- While conventional plagiarism guidelines of research articles' text are not straightforwardly applicable to code, reviewers should indicate if they suspect plagiarism of code or fraud, or have any other ethical concerns.
- Reviewers are invited to see if Authors have credited all contributors appropriately (either with authorship or clear acknowledgement). Authors may be given a chance to explain any exceptions.