Author Guidelines

How ing.grid's Open Peer Review Works

Submission

Upload a PDF of your manuscript or descriptor via the submissions page. At step 3 of the submission form, use "Add supplementary file" to provide links to software, data, or other supplementary material.

Review

After an initial editor screening, your submission is published on the ing.grid preprint server. Peer review is conducted openly: authors and reviewers exchange comments in public, moderated by the editors.

As an author, you:

• Must respond to invited reviewer comments when requested by the editors. This may occur after a decision is taken.
• Are encouraged (but not obliged) to respond to community comments.

Outcomes

The editor informs you of the decision via comment. There are three possible outcomes:

• Revise — Upload a revised version of your manuscript/descriptor, or update the linked software/dataset. You may send a private rebuttal letter to the editor if you prefer not to address specific review points publicly.
• Accept — Provide your final LaTeX source as a single ZIP folder, uploaded as a new preprint version. The editors then move your submission to copyediting and typesetting before publication.
• Reject — You may leave your submission on the preprint server or ask the editors to unpublish it.

Submission Types at a Glance

Every submission includes a written document. For software and dataset submissions, this document is called a descriptor.

	MANUSCRIPT	SOFTWARE	DATASET
Mandatory	Manuscript	Descriptor, Link to Software	Descriptor, Link to Data
Optional	Link to Data, Link to Software	Link to Data	Link to Software

 

Requirements for all Submissions

Quality Guidelines

• 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.

Authorship

• The authorship must align with ing.grid's Publication Ethics.
• All authors may provide an ORCID upon submission (optional).
• Authors should clearly state their contributions, for example using the CRediT taxonomy.

Template & Length

• All manuscripts and descriptors must use the LaTeX template available on the Submissions page. Submissions that do not follow the template will not be considered.
• Ensure line numbering is activated upon submission.
• Recommended length including references: 15–20 pages. Maximum: 25 pages.
• Do not override the fonts and styling defined by the template.

Figures, Images & Tables

Format and submission

• Provide graphs and images in vector format (SVG) or high-resolution pixel format (300 dpi or better, JPEG or PNG).
• Use the LaTeX template mechanism for numbering and captioning.
• Submit all graphs and images in a ZIP archive at the time of submission.
• Submit tables as editable text, following the template styling.
• Ensure copyright clearance for all visual items before submission. All content will be published under the chosen CC-BY licence. Contact the editors before submission if this is not possible.

Accesibility

• Use a high-contrast or colorblind-friendly palette in all figures (e.g. seaborn colorblind palette for Python, Matlab color-blind friendly palette for Matlab).
• Captions are mandatory for all figures, tables, and images. Authors are encouraged to write captions that describe content well enough for readers who cannot see them (see guidelines of the ACM Special Interest Group on Accessible Computing)

Language & Units

• Use a consistent English variation (e.g. British or American) throughout. ing.grid does not offer grammar or spelling checks.
• Use inclusive language in text and communication.
• Follow the international system of units (SI). If non-SI units are necessary, include the SI equivalent.
• Define non-standard abbreviations by footnotes.

Math Equations

• Submit math equations as editable text. Use the LaTeX template for expanded/display equations.
• Use a numeric referencing style (e.g. IEEE) and the template's reference mechanism.
• Data and preprint references are accepted.

Manuscript Submissions

Scope

ing.grid welcomes manuscripts on topics including but not limited to:

• 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  

Required sections

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 

Supplementary material

• Authors are strongly encouraged to provide supplementary software and data. If a full version is available, provide links or DOIs to the repository where it is deposited.
• Where applicable, include minimal examples of research software and sample datasets or course material as supplementary material. License this material to allow viewing and reuse with attribution.
• When providing supplementary material, follow the relevant points in the Software and Dataset Submission Guidelines below. Separate descriptors for supplementary material are not required.

Software Submissions

Scope

A software submission consists of a software descriptor and the software itself, with an optional dataset as supplementary material. The descriptor is the document you submit through the form; it must contain a link to the software repository.

ing.grid publishes descriptors about research data management software — tools that support scientists in good RDM practice or general research software that addresses specific RDM issues. This includes 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

Software requirements

Software published in inggrid must follow the FAIR Principles for Research Software. The minimal criteria are: 

• 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)

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 

All software descriptors must 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

Scope

A dataset submission consists of a data descriptor and the dataset itself, with an optional software repository as supplementary material. The descriptor is the document you submit through the form; it 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 RDM practice. Examples include:

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

Dataset requirements

Data must follow the FAIR Principles. The minimal criteria are: 

• 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

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.