Author Guidelines

The Author Guidelines are structured as follows: 

  • General Author Guidelines contain guidelines that hold for all submission types. 
  • Author Guidelines for Manuscript Submission hold if the submission type is a manuscript submission. 
  • Author Guidelines for Software Submission hold if the submission type is software submission. 
  • Author Guidelines for Dataset Submission hold if the submission type is dataset submission. 

General Author Guidelines

Ing.grid recognizes three submission types: 

  • Manuscript submission 
  • Software submission 
  • Dataset submission

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 also contains supplementary material, as shown in the diagram below. 

Submission TypeManuscriptSoftwareData
To SubmitManuscript


Link to Software


Link to Data

Supplementary Material

Link to Data

Link to Software

Link to DataLink to Software


  • 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.
  • Authors should state their contributions, for example using the CRediT taxonomy.



  • 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 and be as short as possible. 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. While formatting the manuscript for submission in the preferred LaTeX-compatible writing environment, authors should ensure 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.  

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 to the LaTeX template.   


  • 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 be organised and styled automatically.  
  • Data and preprint references are also accepted when submitting to ing.grid.  

FAIR Principles

The submission must align with the FAIR principles. It should meet domain-relevant community standards. 


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

Open Review

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

  • Authors are obliged to respond to invited review comments when requested by the editors. This may occur after a decision is taken regarding the submission.
  • Authors are 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.

Manuscript Submission Guidelines

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.  


All manuscripts must contain: 

  • Title 
  • Author list (including ORCIDs)
  • 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 
  • 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.
  • 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.
  • 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. 

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.

Software Submission Guidelines

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 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 Guidelines

  • Authors must deposit the software code to a repository. The authors must ensure the code is open to be accessed, viewed, browsed and cloned anonymously.
  • 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. 
  • 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.
  • Software submissions must not depend on proprietary software.
  • 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.
  • The software should be described by metadata using a formal, accessible, shared, and broadly applicable language for knowledge representation.
  • 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.
  • 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.
  • The repository should use version control.
  • The repository should allow issue tracking and allow submission of issues. 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.
  • 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.

Software Descriptor 

All software descriptors should contain:

  • Title
  • Author list (including ORCIDs)
  • 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:

  • The software descriptor must contain a link to the repository where the software is deposited and a version ID.
  • The creatorship of the software should be consistent with the authorship of the submitted software descriptor. If there are differences, authors must clarify these.
  • 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.
  • Software architecture and usage should be sufficiently described.
  • 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.

Ensuring FAIRness 

For guidance regarding software and description aligning with the FAIR principles, authors should refer to "Table 1" of the FAIR principles for research software outline by the RDA Working Group FAIR4RS. While all scientists writing research software should aim to follow these principles, ing.grid accepts the following minimal requirements for ensuring FAIRness.

F Software, and its associated metadata, is easy for both humans and machines to find
  • Software is assigned a unique resource identifier (URI), e.g. a URL to the repository
    • One URI per software repository is sufficient
    • Different versions of the software are assigned distinct version IDs
  • Software is described with metadata (cf. Software Guidelines Point 6)
  • Metadata clearly and explicitly include the identifier of the software they describe
A Software, and its metadata, is retrievable via standardized protocols
  • The software can be retrieved under its URI via download, cloning or similar
    • Retrieval must be possible without using a proprietary protocol (e.g. download wizard)
I Software interoperates with other software by exchanging data and/or metadata, and/or through interaction via application programming interfaces (APIs), described through standards
  • Software reads, writes and exchanges data in a way that meets domain-relevant community standards
  • Software includes a dependency list
R Software is both usable (can be executed) and reusable (can be understood, modified, built upon, or incorporated into other software)
  • Software should be accurately described by metadata, documentation, license and version control
    • The repository must contain a plain text licensing file for an open source license
    • The software repository uses version control for provenance tracking
  • Software includes a dependency list
  • Software meets domain-relevant community standards

Data Submission Guidelines

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 contain: experimental data (images, laboratory measurements,…), simulation data, materials data, geospatial data, field data, survey results, or similar.

Data Guidelines

  • 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.
  • The repository should, if possible, contain a README file or similar documentation explaining purpose, scope and usage. 
  • The dataset must be available in open access, with an option for reviewers to access it anonymously.
  • 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. 
  • The dataset should use a format that is commonly used in the respective community and is non-proprietary.
  • The content of the dataset must comply with formal standards and conventions for example regarding data structure and uncertainty quantification.
  • The dataset should be described by metadata using a formal, accessible, shared, and broadly applicable language for knowledge representation.

Data Descriptor 

All dataset descriptors must contain:

  • Title 
  • Author list (including ORCIDs)
  • 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:

  • The dataset must be referenced in the data descriptor using the DOI. 
  • The creatorship of the data should be consistent with the authorship of the submitted software 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. 
  • 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.
  • Authors must describe the utility of the data set to the community. Readers should be able to recognise the relevance of the data set 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.
  • If possible, authors should provide 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.
  • 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.

Ensuring FAIRness

For guidance regarding data and description, authors should refer to the FAIR principles for scientific data management. While all scientists generating or reusing data should aim to follow these principles, ing.grid accepts the following minimal requirements for ensuring FAIRness: 

F Data, and its associated metadata, is easy for both humans and machines to find
  • Datsets are assigned a DOI
  • Data are described with relevant metadata
  • Metadata contains the DOI of the dataset
  • Datasets are deposited in a searchable data repository (e.g., institutional repository, Zenodo)
A Data, and its metadata, is retrievable via standardised protocols
  • The DOI references a page, from which the dataset can be downloaded
I The data need to interoperate with applications or workflows for analysis, storage, and processing
  • The dataset should be described by metadata using a formal, accessible, shared, and broadly applicable language for knowledge representation
  • If possible, (meta)data should use standardised vocabularies
R Data is both usable and reusable
  • Datasets should be accurately described by metadata, documentation, license and version
    • The dataset is released with a clear and accessible data usage license
    • The metadata indicates a version number of the dataset and where possible provides provenance information
  • The datasets meet domain-relevant community standards of formal quality