Reviewer Information

Guide to GigaByte transparent peer review

Thank you if you have agreed to review a manuscript submitted to GigaByte. Our aim with GigaByte is to champion high standards of documentation, testing, and reproducibility of the creation and analyses of large-scale FAIR (findable, accessible, interoperable and usable) research objects (data and software). GigaByte therefore has strict requirements on data availability, licensing, documentation and testing. To achieve this, as a referee we will ask you to review manuscripts that present novel datasets with a specific eye toward making certain that the minimum standards for the field are fulfilled and that all appropriate testing of data accuracy has been carried out. Please see our Editorial policies and reporting standards guide for more details. If reviewers feel they are unable to assess specific issues concerning data, please state this in your comments to the editor.

Open Peer-Review Policy

GigaByte has an open (non-anonymous) peer-review as it improves the transparency of review processes and publication as a whole. Therefore, as a default, we will pass a reviewer's name on to the authors along with the comments. We do not have an option for anonymous peer review. Reviewers are asked to declare any competing interests and to agree to Open Peer Review, which works on two levels: the authors receive the signed report and, if the manuscript is published, the same report will be made available to the readers. We are happy to encourage co-refereeing of our articles, and the referees are all asked to sign their names on the bottom of the report. Co-referees' names are then published, so that they also receive full credit. Reviewer reports are made public under an Open Access license Creative Commons CC-BY license ( The pre-publication history (initial submission, reviews and revisions) will also be posted on the Web as supplementary files with the published article. 

GigaByte supports the open science approach to peer-review and the publication process. We support the principles of the open peer-review oath and encourage reviewers to use such an approach (see Aleksic et al. 2015, doi: 10.12688/f1000research.5686.2 for more details):

Principles of the open peer-review oath

  • Principle 1: I will sign my name to my review
  • Principle 2: I will review with integrity
  • Principle 3: I will treat the review as a discourse with you; in particular, I will provide constructive criticism
  • Principle 4: I will be an ambassador for the practice of open science

Reviewing the manuscript. Suitability of research for publication in GigaByte is dependent primarily on the data quality and utility and on the soundness of the biological conclusions from all data analyses, rather than on a subjective assessment of its immediate impact. Note, that although GigaByte will not make general interest level the primary criterion for publication, it aims to provide its readership with the highest quality large-scale and FAIR data, data analysis tools, and analyses that will have significant usability and utility for the community. As a referee we ask that you assess the paper on its own merits. The following list of potential issues may be helpful. 

GigaByte uses a Reviewer Checklist for reviewers to fill out to help speed the peer review process. 

If any question on the checklist is unclear, please see the following to obtain guidance on what to look for each question. There are different checklists for Data Release and Technical Release papers. If you cannot answer Yes or No, please write "not my expertise" in the “Additional Comments” box. 

Data Release criteria

  • Is the language of sufficient quality?

Although the editorial team may also assess the quality of the written English, please do comment if you consider the standard is below that expected for a scientific publication.

  • Is the data all available and does it match the descriptions in the paper? 

The data should be plausable and consistent with the description, and credit should be given for transparency and provision of all supporting information.

  • Is the data and metadata consistent with relevant minimum information or reporting standards?

This is an essential component as ease of reproducibility and usability are key criteria for manuscript publication. Have the authors followed and used reporting checklists recommended in GigaDB and our page on the FAIRsharing network? Our curators will check for this during the curation process but your input is also useful on this question. If the methods are amenable, have the authors used workflow management systems such as Galaxy or one of the many related systems listed on MyExperiment? We also encourage use of virtual machines and containers such as Docker, and the use and deposition of both wet-lab and computational protocols in a protocols repository like, and code in the cloud-based computational reproducibility platform CodeOcean.

  • Is the data acquisition clear, complete and methodologically sound? 

Please remark on whether the methods are clear and if more detail should be included.  Please note, the methodology sections should never contain “protocol available upon request” or “e-mail author for detailed protocol”.

  • Is there sufficient detail in the methods and data-processing steps to allow reproduction?

Please remark on the suitability of the methods for the study.  Please note, the methodology sections should never contain “protocol available upon request” or “e-mail author for detailed protocol”.

  • Is there sufficient data validation and statistical analyses of data quality?

Please remark on the suitability of the statistics for the study. If statistical analyses have been carried out, please indicate if you feel they need to be assessed specifically by an additional reviewer with statistical expertise. 

  • Is the validation suitable for this type of data? 

Please comment on any improvements that could be made to the study design to enhance the quality of the results. If any additional experiments are required, please give details. If novel experimental techniques were used please pay special attention to their reliability and validity.

  • Is there sufficient information for others to reuse this dataset or integrate it with other data?

Please comment if any accessions are missing and should be included, or if there are issues with the integrity of the data.

Following community standards for data sharing is a requirement of the journal. Additionally, data sharing in the broadest possible manner expands the ways in which data and tools can be accessed and used. 


Technical  Release criteria

  • Is the language of sufficient quality?

Although the editorial team may also assess the quality of the written English, please do comment if you consider the standard is below that expected for a scientific publication.

  • Is there a clear statement of need explaining what problems the software is designed to solve and who the target audience is?

The authors should clearly state what problems the software is designed to solve and who the target audience is.

  • Is the source code available, and has an appropriate Open Source Initiative license been assigned to the code?

We require all source code to be openly available for reproducibility and reuse. Did the authors indicate where the software tools and relevant source code are available, under an appropriate  Open Source Initiative compliant license? 

  • As Open Source Software are there guidelines on how to contribute, report issues or seek support on the code? 

There must be clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

  • Is the code executable?

Can this tool be easily run on a computer? If not, please comment on what problems were encountered.  

  • Is the documentation provided clear and user friendly?

There must be enough clear information in the documentation to run this tool and information on where to seek help if required.

  • Is installation/deployment sufficiently outlined in the paper and documentation, and does it proceed as outlined?

Please comment on any problems with installation/ deployment. Should this be handled with an automated package management solution?

  • Is there a clearly-stated list of dependencies, and is the core functionality of the software documented to a satisfactory level?

A clear list of dependencies should be included. Are they using readthedocs or do they have a well documented code repository? Please comment if more is required.

  • Have any claims of performance been sufficiently tested and compared to other commonly-used packages? 

If there are performance claims and are insufficiently tested, please comment. If there are no performance claims, please comment “not applicable”.

  • Are there (ideally real world) examples demonstrating use of the software?

  • Is automated testing used or are there manual steps described so that the functionality of the software can be verified?

Automated testing is listed in the bioinformatics best practice checklist. Have the authors used a test framework to check the functionality of their software? If there is no automated testing, do the authors provide example data for testing their software and define what the expected results are?