An Overview of ing.grid’s Open Peer Review: Author Perspective

Submission

• The authors must upload a PDF version of the manuscript or descriptor via the submissions page.
• Links to the software or data as well as other supplementary material must be provided through the option “Add supplementary file” at step 3 of the submission form.

Once the submission passes an initial editor screening, the editors publish it on the preprint server and the peer review possess begins. ing.grid uses an open peer review process in which authors and reviewers communicate in public comments which are moderated by the editors.

As an author, you are :

• obliged to respond to invited review comments when requested by the editors. This may occur after a decision is taken regarding the submission.
• not obliged to respond to community comments, though this is strongly encouraged by ing.grid.

There are three possible outcomes of the review process, of which the authors are informed via comment by the editor:

• revise
• accept
• reject

In case revisions are required, authors must upload a new version of their manuscript or descriptor or update the software and/or dataset accordingly.Authors are free to write a rebuttal letter to the responsible editor if they want to address specific details of the review but do not want these comments to be public.If the submission is accepted, the authors must provide the LaTeX version collated into a single ZIP folder and upload this as a new version of their preprint. The editors will then pass the submission to the ing.grid journal for copyediting and typesetting before it is ultimately published as an article.If the submission is rejected, authors have the option to leave the submission on the preprint server or ask editors to unpublish the submission.If, during the open peer review process, authors do not respond for a long time, it may lead to a rejection for publication at ing.grid.

The Author Guidelines are structured as follows: 

• General Author Guidelines (that consist of Quality Guidelines and Formal Guidelines) that hold for all submission types. 
• Author Guidelines for Manuscript Submission. 
• Author Guidelines for Software Submission. 
• Author Guidelines for Dataset Submission. 

General Author Guidelines

Ing.grid recognises three submission types: 

• Manuscript submission 
• Mandatory : Manuscript
• Optional :
  • Link to Data
  • Link to Software
• Software submission 
• Mandatory :
  • Descriptor
  • Link to Software
• Optional : Link to Data
• Dataset submission
• Mandatory :
  • Descriptor
  • Link to Data
• Optional : Link to Software

For each submission type, a written manuscript has to be submitted. In case of software and dataset submissions, the manuscript is referred to as a descriptor. Each submission type may also contain supplementary "optional material", as mentioned above. 

Quality Guidelines

As the author, you need to ensure that the submission fulfills the following quality requirements:

• The novelty and originality of the content presented in each submission must be made clear.
• The work must be clearly placed in the state of the art with reference to relevant literature
• The presented work must be the result of substantial scholarly effort.
• FAIR Principles: The submission must align with the FAIR principles and must meet domain-relevant community standards of FAIR data. The minimal requirements for adherence to FAIR principles for ing.grid are listed below in the relevant sections.

Formal Guidelines

As the author, you must ensure that the submission meets the following formal requirements.

Authorship

• The authorship of manuscripts must align with the authorship specifications described in our Publication Ethics section.
• Globally unique and persistent identifiers (PID) are an essential tool for ensuring findability. Accordingly, all authors may provide an ORCID upon submission(optional).
• Authors should clearly state their contributions. (for example using the CRediT taxonomy)

Format

Template

• All manuscripts and descriptors must be submitted using the LaTeX template available on the Submissions page. Submissions that do not follow the template will not be considered. 
• Upon submission, authors should ensure that line numbering is activated.  

Recommended Manuscript Length

• The manuscripts should have an appropriate length. The recommended manuscript length including references is 15 to 20 pages. The manuscript must not exceed a length of 25 pages.

Fonts and Styling

• The LaTeX template defines the fonts and the styling for the manuscripts. Authors should ensure that this predefinition is not lost. 

Graphs, Images and Tables

• Graphs and images must be provided in a vector format (SVG) or a high-resolution pixel-based format (300dpi or better, as JPEG or PNG).  
• The mechanism in the LaTeX template should be used for numbering and captioning them according to the instructions described in the model.   
• All graphs and images should also be submitted in a ZIP archive at the moment of submission.  
• Tables should be submitted in the form of editable text, following the styling provided by the template.   
• It is crucial to assure the copyright of these items before submitting them to the journal once all the content is available in ing.grid under the chosen CC-BY licence. If this is not possible, the authors should contact the editors before submission.   
• To increase accessibility, it is desired to ensure that colour images are accessible to all, including those with impaired colour vision.

Image Accesibility Guidelines

• High contrast images and colorblind friendly palettes can make images more accessible for people with colorblindness and other vision disabilities.  In figures, authors must use a high-contrast or colorblind-friendly palette.(for example, the seaborn colorblind palette in python, or Matlab color-blind friendly palette when using Matlab).
• Figure, table and image captions are mandatory. Authors are encouraged to make the figures, tables and images more accessible to readers, reviewers and editors that cannot see them by using captions that describe the content well. (for example by following the guidelines of the ACM Special Interest Group on Accessible Computing)

Language, Units and Abbreviations

• Authors must use a consistent English variation (e.g. British English, American English) in the entire text and take care of grammar corrections before submission. ing.grid does not offer a grammatical and/or a spelling check.   
• We strongly encourage using inclusive language in text and communication.   
• All mentioned units should follow the international system of units (SI). If it is necessary to mention other units incompatible with the SI, the authors should present the equivalent of the non-SI unit in the SI system.   
• For abbreviations, it is essential to define those that are not standard by footnotes for better clarification to editors, reviewers and readers.

Math Equations

• Math equations should be submitted as editable text and can be presented in line with standard text. If it is necessary to display an equation as an expanded citation, authors should place it accordingly with the LaTeX template.   

References

• Every reference should be cited in the text using a numeric referencing style such as IEEE. Authors should use the LaTeX template mechanism described in the template guidelines to organise and style the text.  
• Data and preprint references are also accepted when submitting to ing.grid.  

Manuscript Submission Guidelines

Overview

ing.grid is open to manuscript submissions that include but are not limited to the following: 

• FAIR data management methods for various domains of engineering sciences 
• Education concepts for FAIR data management all stages of an engineering career 
• Best practice examples of FAIR data management methods, workflows and operationalisation  
• Tutorials related to FAIR data management
• Collaboration and interdisciplinary research
• Discussions of the seven core aspects of FAIR data management defined in the scope  

Content

All manuscripts must contain: 

• Title 
• Author list (including ORCIDs, if existing)
• Affiliations (including PIDs, where possible)
• Abstract 
• Keywords 
• Theoretical background
• State of the art 
• Methods (if applicable, methods related to creating data/software)
• Results
• Discussion 
• Conclusion
• Code and/or Software availability (if applicable) 
• Acknowledgements 
• Author Contributions 
• Conflicts of interest 
• Funding sources (optional)
• References 

Furthermore, the following points should be addressed in the manuscript :

• Authors are strongly encouraged to provide supplementary material, especially software and data. If a full version of utilised research software or datasets is available as supplementary material, authors should ensure findability and accessibility of this material by providing links or DOIs to the repositories where the software or dataset is deposited.
• Whenever applicable, manuscripts should include minimal examples of utilised research software and sample dataset or course material which should be submitted as supplementary material. This material should be licensed in a way that allows viewing and reuse while ensuring attribution.
• When providing supplementary material, authors should orient themselves on Software and Dataset Submission Guidelines which are designed to help ensure findability and accessibility. Descriptors for supplementary material must not be provided, but the respective relevant points should be addressed in the manuscript if applicable. 

Software Submission Guidelines

Overview

Software submissions consist of a software descriptor and the software itself with an optionally included dataset as supplementary material. The software descriptor is a written document describing the software. It is this document that authors submit to ing.grid through the submission form. The descriptor must contain a link to the software repository.

ing.grid publishes software descriptors about research data management software. This definition includes all software with a clear relation to research data management (RDM). Software submissions may either be dedicated tools for supporting scientists in good RDM practice or general research software which also addresses specific RDM issues.

This includes but is not limited to software that :

• solves complex modelling problems in an engineering context
• supports functioning of research instruments or the execution of research experiments
• extracts knowledge from large datasets, or similar

Authors must ensure that the following guidelines for both the software itself and the software descriptor are followed.

 

Software Guidelines

Software published in inggrid must follow the FAIR Principles for Research Software :

• Findable: Software, and its associated metadata, is easy for both humans and machines to find
• Accesible: Software, and its metadata, is retrievable via standardized protocols
• Interoperable: Software interoperates with other software by exchanging data and/or metadata, and/or through interaction via application programming interfaces (APIs), described through standards
• Reusable: Software is both usable (can be executed) and reusable (can be understood, modified, built upon, or incorporated into other software)

Authors must ascertain that the software aligns with the above mentioned principles by ensuring the following minimal criteria:

Accessibility and Findability:

• Authors must deposit the software code to a repository and ensure that the code is open to be accessed, viewed, browsed and cloned anonymously. (F,A)

Licensing:

• Software submissions must not depend on proprietary software. (R)
• The software must be licensed under an Open Source license as defined by the OSI. The repository must contain a plain text licensing file. It should also include copyright and licensing statements of any third-party software that are legally bundled with the code in compliance with the conditions of those licenses. (R)

Documentation:

• The repository should contain a README file (or similar documentation explaining installation procedure, system requirements as well as purpose, scope and usage). The installation procedure should be automated as far as possible, ideally by a package management system. (R) 
• Installation instructions must clearly and comprehensively detail all required dependencies, including required version numbers. Additionally, repositories should make use of language and domain standard automated dependency management tooling.  (For example:  Python applications should use required.txt or a common virtual environment definition, node applications should include a package.json file, C++ applications should include a CMakeList.txt or makefile).  Similarly, approaches such as the use of docker deployments are also expected. (I, R)
• The software should be described by metadata using a formal, accessible, shared, and broadly applicable language for knowledge representation. Metadata must clearly and explicitly include the identifier of the software they describe. (F, R)
• Authors should include a working example of the software. Required minimal example data should be included in the software repository. Authors are strongly encouraged to provide a reference to a data repository using a DOI in which users can find a dataset relevant to the software as supplementary material. (R)

Maintenance:

• Instructions on how to contribute to the project should be included in the repository. (This may be as minimal as submitting an issue or as broad as providing instructions on how to set up a development environment, what coding styles are used, whether automated tests should be run or written or which other minimal testing process is used, what the code architecture is, etc). (R)

Software Quality:

• The software code must comply with formal standards regarding commenting, formatting conventions, coding standards and structure. Furthermore, authors should ensure easy readability and make use of community or language-accepted common code structures. (I, R)
• The repository should use version control. (F, R)
• The repository should allow issue tracking and allow submission of issues. (R)
• The authors must ensure that the functionality of the software adopts a testing method, preferably by automated tests, though a clearly described testing procedure is also acceptable. (R)

Software Descriptor Guidelines

All software descriptors should contain:

• Title
• Author list (including ORCIDs, if existing)
• Affiliations (including PIDs, where possible)
• Abstract
• Keywords
• Software code identified by title, creator, publisher and location (e.g. URL), version number
• Software license (an open source license is mandatory)
• State of the art and novelty of the approach
• Statement of need
• Purpose and scope/limits of the application
• Utility of the software
• User notes
• Sample data availability and reference to related datasets
• Acknowledgements
• Author Contributions
• Conflicts of interest
• Funding sources (optional)
• References

Furthermore, the following points should be addressed in the software descriptor:

• Findability of software: The software descriptor must contain a link to the repository where the software is deposited and a version ID.
• Authorship: The authorship of the software should be consistent with the authorship of the submitted software descriptor. If there are differences, authors must clarify these.
• Novelty: The authors are expected to provide a technical analysis evaluating the source code via: a discussion of how the software compares to other similar and related alternative software in terms of scope and provided functionality; commentary on how near or far the source code is to meeting domain and language known best practices such as adherence to coding styles, package management, documentation, and use of automated testing, collaboration, and deployment infrastructure and tools; optionally, a demonstration of the software's performance numerically via standardized benchmarking techniques or otherwise relevant quantifiable metrics.(The novelty of the approach and the scholarly effort of designing the software and writing the code must be made clear)
• A statement of need should clearly indicate the utility of the software to the community and the software should have a clear (research) data management application. Readers should be able to recognise the relevance of the software for supporting them in their daily challenges of data management and research. Thus, a statement of need, the application and a user story should be part of the submitted software paper.
• Software Documentation: Software architecture and usage should be sufficiently described.

Data Submission Guidelines

Overview

Data submissions consist of a data descriptor and a dataset with an optionally included software repository as supplementary material. The data descriptor is a written document describing the dataset. It is this document that the authors submit to ing.grid through the submission form. The descriptor must contain a link to the dataset.

ing.grid publishes data descriptors about datasets relevant to an engineering or data management context. The datasets should themselves be examples of good (research) data management (RDM) practice.

Datasets may be for example :

• experimental data (images, laboratory measurements,…)
• simulation data
• materials data
• geospatial data
• field data
• survey results

Data Guidelines

Data published in inggrid must follow the FAIR Principles :

• Findable: Data, and its associated metadata, is easy for both humans and machines to find
• Accesible: Data, and its metadata, is retrievable via standardized protocols
• Interoperable: The data must be able to interoperate with other applications or workflows for analysis,storage and processing
• Reusable: Data is both usable and reusable

Authors must ascertain that the dataset aligns with the above mentioned principles by ensuring the following minimal criteria:

Accessibility and findability:

• Authors must deposit the data in a repository that offers a DOI (digital object identifier) as unique and persistent identifier and that is listed in the index re3data. (F, A)
• The dataset must be available in open access, with an option for reviewers to access it anonymously. (A)

Documentation:

• The repository should, if possible, contain a README file or similar documentation explaining purpose, scope and usage. (R)
• All necessary information required for replicating the measurements, reproducing the figures or other representations must be provided in the dataset or the descriptor. (R)
• The dataset should be described by metadata using a formal, accessible, shared, and broadly applicable language for knowledge representation. (I)
• Metadata must contain the DOI of the dataset (F)

Licensing:

• The repository must provide licensing information of the dataset. As a rule, the Creative Commons Attribution (CC-BY 4.0) license should be used by authors. (R)

Quality:

• The dataset should use a format that is commonly used in the respective community and is non-proprietary. (R)
• The content of the dataset must comply with formal standards and conventions (for example regarding data structure and uncertainty quantification). The data must be logically and consistently organised as well as being easily readable and usable. (I)

Data Descriptor Guidelines

All dataset descriptors must contain:

• Title 
• Author list (including ORCIDs, if existing)
• Affiliations (including PIDs, where possible)
• Abstract 
• Keywords 
• Dataset identified by title, DOI, creator, publisher and location (e.g. URL), publication date, subject field, version
• Dataset license (an open access license is mandatory) 
• State of the art and novelty of the approach 
• Description of the content of the dataset
• Data Collection or Generating Methods 
• Description of Employed Tools 
• Technical validation
• Quality evaluation
• Usage notes 
• Code availability with link and license
• Acknowledgements 
• Author contributions 
• Conflicts of interest
• Funding sources (optional)
• References

Moreover, the following guidelines hold:

• Dataset findability: The dataset must be referenced in the data descriptor using the DOI. 
• Authorship: The authorship of the data should be consistent with the authorship of the submitted dataset descriptor. If there are differences, authors must clarify these.
• Supplementary material should include a minimal software example to illustrate the data set's generation and/or processing. 
• Novelty: Authors must describe the utility of the dataset to the community. Readers should be able to recognise the relevance of the dataset for the field. In order for the data to be reusable, the methods need to be made as transparent as possible and the precision of the data needs to be quantified using domain relevant measures of uncertainty.
• Documentation: Methods of data collection/generation should be sufficiently described. The novelty of the approach and the scholarly effort of gathering the data must be made clear. Both hardware and software tools applied need to be specified appropriately. Estimation of errors or uncertainty must be disclaimed, and authors should use common standards for comparison. (If data is sensitive to age, disability status, sex, gender identity, racial and ethnic identity, sexual orientation, and/or socioeconomic status, authors must inform accordingly)
• Reproducibility: All necessary information required for replicating the measurements, reproducing the figures or other representations must be provided in the dataset or descriptor.
• Ideally, a minimal example for using the dataset. Authors are strongly encouraged to provide a reference to a software repository using a link and version ID.