Guidelines for Article Preparation for Submission
Preparing a Software Tool Article
This page provides information about writing a Software Tool Article for F1000Research, including the key sections that must be present in the article. Please also refer to F1000Research’s editorial policies.
A template for Software Tool Articles is available here.
Criteria
Software Tool Articles describe new software tools, including the rationale for the development of the tool and details of the code used for its construction. The article should provide examples of suitable input data sets and include an example of the output that can be expected from the tool and how this output should be interpreted. Software Tool Articles submitted to F1000Research should be written in open-access programming languages.
Language
All articles must be written in good English. Both UK English and US English are accepted but this must be consistent throughout the manuscript. Please note that the article will not undergo editing by F1000Research before publication and a manuscript could be rejected during the initial checking process if it is deemed unintelligible and unsuitable for peer review.
For authors whose first language is not English, it may be beneficial to have the manuscript read by a native English speaker with scientific expertise. There are many commercial editing services that can provide this service at a cost to the authors.
Main Sections
- Authors
- Title
- Abstract
- Keywords
- Main Body
- Data and Software Availability
- Author Contributions
- Competing Interests
- Grant Information
- Acknowledgments
- Supplementary Material
- References and footnotes
- Figures and Tables
- Units, Symbols and Mathematical Scripts
- Authors’ Role in the Peer Review Process
Authors
All authors should have made a significant contribution to the work and agree to be accountable for the parts of the work they have done. All authors should approve the final version for publication (see the ICMJE’s Uniform Requirements for Manuscripts Submitted to Biomedical Journals for more details). Being an author implies full responsibility for the article’s content and that the work conforms to our editorial policies. For large, multi-centre collaborations, the individuals who accept direct responsibility for the manuscript must be listed as authors.
Details of each author’s contribution must be listed in the Author contributions section.
Anyone who has contributed but does not meet the criteria for authorship should be listed in the Acknowledgments section. The involvement of any professional medical writer assistance must be declared.
Title
Please provide a concise and specific title that clearly reflects the content of the article.
Abstract
Abstracts should be up to 300 words long and provide a succinct summary of the article. Although the abstract should explain why the article might be interesting, the importance of the work should not be over-emphasized. Citations should not be used in the abstract. Abbreviations, if needed, should be spelled out. Abstracts are structured into Background, Methods, Results, and Conclusions.
Keywords
Authors should supply up to eight relevant keywords that describe the subject of their article. These will improve the visibility of your article.
Main Body
Software Tool Articles typically contain the following sections:
- Introduction
- Methods
- Results
- Use Cases
- Conclusions/Discussion
Introduction
Provide context as to why the software tool was developed and what need it addresses. It is good scholarly practice to mention previously developed tools that address similar needs, and why the current tool is needed.
Methods
Include a subsection on Implementation describing how the tool works and any relevant technical details required for implementation; and a subsection on Operation, which should include the minimal system requirements needed to run the software and an overview of the workflow.
Results (optional)
This section is only required if the paper includes novel data or analyses and should be written as a traditional results section.
Use Cases (optional)
Please include a section on Use Cases if the paper does not include novel data or analyses. Examples of input and output files should be provided with some explanatory context. Any novel or complex variable parameters should be explained in sufficient detail to enable users to understand and use the tool’s functionality.
Conclusions/Discussion
This section should include a discussion of the results (e.g. if the paper includes novel data or analyses) or conclusions should include a brief discussion of allowances made (if any) for controlling bias or unwanted sources of variability, and the limitations of any novel datasets.
Data and Software Availability
Underlying data
All articles must include a Data Availability Statement, even where there is no data associated with the article - see our data guidelines and policies for more information.
The Data Availability Statement should provide full details of how, where, and under what conditions the data underlying the results can be accessed; for practical guidance please see our data guidelines page; and our list of approved data repositories.
Your data availability statement should follow the following format:
[Name of data repository]. [Title of dataset]. [Persistent identifier].
This project contains the following underlying data:
- Title of file. (Description of data in file).
- Title of file. (Description of data in file).
Data is available under the terms of the [Name of license].
For example:
OSF: Ethics issues identified by applicants and ethics experts in Horizon 2020 grant proposals. https://doi.org/10.17605/OSF.IO/T765V (Buljan et al., 2021).
This project contains the following underlying data:
- Data file 1. Datasets.xlsx
Data are available under the terms of the Creative Commons Zero “No rights reserved” data waiver (CC0 1.0 Public domain dedication).
Example taken from: Buljan I, Pina DG and Marušić A. Ethics issues identified by applicants and ethics experts in Horizon 2020 grant proposals [version 2; peer review: 2 approved]. F1000Research 2021, 10:471 (https://doi.org/10.12688/f1000research.52965.2).
If you have deposited your dataset in a structured, subject-specific repository, for example an INSDC member repository, you may receive an accession code as a persistent identifier and a Creative Commons license will not be applicable.
In this case, your data availability statement should follow the following format:
NCBI Gene: Ihe1 intestinal helminth expulsion 1 [Mus musculus (house mouse)]. Accession number 107537.
Restricted data
Some data may be restricted for legitimate reasons including data protection, copyright or reasons related to ethics or privacy. In these cases, the Data Availability statement should provide full details of the restrictions on the data, and how, where, and under what conditions the data underlying the results can be accessed. Please provide the required information listed under the relevant exception in our data policy.
Extended data
There are no figure or table limits for articles in F1000Research. Additional materials that support the key claims in the paper but are not absolutely required to follow the study design and analysis of the results, e.g., questionnaires, supporting images or tables, can be included as extended data; descriptions of the materials and methods should be in the main article. Extended data should be in a format that supports reuse under a CC0 or Public Domain Dedication or CC-BY 4.0 Attribution-Only license. Care should be taken to ensure that the publication of extended data in this instance does not preclude primary publication elsewhere. If you intend to publish additional research articles based on the extended data with another journal, you should ensure that publishing your extended data in this way will not be considered ‘prior publication’ by your chosen journal.
If you have any extended data, please deposit these materials in an approved repository and include the title, the name of the repository, the DOI or accession number, and license in the manuscript under the subheading ‘Extended data’ using the format below. Extended data should be cited where relevant in the main text.
[Name of data repository]. [Title of dataset]. [Persistent identifier].
This project contains the following extended data:
- Title of file. (Description of data in file.)
- Title of file. (Description of data in file.)
Data is available under the terms of the [Name of license].
For practical guidance please see our data guidelines page; and our list of approved data repositories.
Please note, information which can be used to directly identify participants should not be included in underlying and extended datasets, unless they have provided explicit permission to share their details. Please see our data guidelines for further information.
Software and Code
All articles should include details of any software and code that is required to view the datasets described or to replicate the analysis. Please see our data guidelines and policies for more information.
Where software is used to process, store or analyse data, please include the version number of the software used.
Where proprietary software is used, please also include an open-access alternative that can perform the same function. We recognise that there may be cases where this may not be feasible. Please see our software availability policy for more information or contact the editorial team if this is the case.
If you are describing new software, please make the source code available on a Version Control System (VCS) such as GitHub, BitBucket or SourceForge, and provide details of the repository and the license under which the software can be used in the article. Please also deposit an archived copy of the software at the time of submission to a recognised repository. You should include a statement in the manuscript as follows:
- Software available from: URL for the website where software can be downloaded from, if applicable.
- Source code available from: URL for versioning control system (for example GitHub).
- Archived source code at time of publication: DOI and citation for project in Zenodo (please select the appropriate DOI for the version which underlies your article).
- License: Must be an open license and preferably an OSI-approved license.
Author Contributions
We are using the CRediT Taxonomy to capture author contributions as we believe that having more detail of who did what brings transparency, enables recognition for researchers, and provides greater accountability for all involved. For more information click here.
You do not need to include an Author Contributions section in your manuscript: on submission, you will be asked for the contributions made by each author, to be selected from the list below. Anyone who has contributed but does not meet the criteria for authorship should be listed in the Acknowledgments section.
| Contributor Role | Role Definition |
| Conceptualization | Ideas; formulation or evolution of overarching research goals and aims. |
| Data Curation | Management activities to annotate (produce metadata), scrub data and maintain research data (including software code, where it is necessary for interpreting the data itself) for initial use and later reuse. |
| Formal Analysis | Application of statistical, mathematical, computational, or other formal techniques to analyze or synthesize study data. |
| Funding Acquisition | Acquisition of the financial support for the project leading to this publication. |
| Investigation | Conducting a research and investigation process, specifically performing the experiments, or data/evidence collection. |
| Methodology | Development or design of methodology; creation of models. |
| Project Administration | Management and coordination responsibility for the research activity planning and execution. |
| Resources | Provision of study materials, reagents, materials, patients, laboratory samples, animals, instrumentation, computing resources, or other analysis tools. |
| Software | Programming, software development; designing computer programs; implementation of the computer code and supporting algorithms; testing of existing code components. |
| Supervision | Oversight and leadership responsibility for the research activity planning and execution, including mentorship external to the core team. |
| Validation | Verification, whether as a part of the activity or separate, of the overall replication/reproducibility of results/experiments and other research outputs. |
| Visualization | Preparation, creation and/or presentation of the published work, specifically visualization/data presentation. |
| Writing – Original Draft Preparation | Creation and/or presentation of the published work, specifically writing the initial draft (including substantive translation). |
| Writing – Review & Editing | Preparation, creation and/or presentation of the published work by those from the original research group, specifically critical review, commentary or revision – including pre- or post-publication stages. |
Competing Interests
Articles published in F1000Research must not contain content that could be perceived as ‘advertising’ and must include a Competing Interests section. Any financial, personal, or professional competing interests for any of the authors that could be construed to unduly influence the content of the article must be disclosed and will be displayed alongside the article. More information on what might be construed as a competing interest is available in our editorial policies.
If you do not have any competing interests, add the text ‘No competing interests were disclosed’.
Grant Information
Please state who funded the work, whether it is your employer, a grant funder etc. Please do not list funding that you have that is not relevant to this specific piece of research. For each funder, please state the funder’s name, the grant number where applicable, and the individual to whom the grant was assigned.
If your work was not funded by any grants, please include the section entitled “Grant information” and state: ‘The author(s) declared that no grants were involved in supporting this work’.
Acknowledgments
This section should acknowledge anyone who contributed to the research or the writing of the article but who does not qualify as an author; please clearly state how they contributed. Authors should obtain permission to include the name and affiliation, from all those mentioned in the Acknowledgments section. Please note that grant funding should not be listed here.
Supplementary Material
To ensure all materials associated with a manuscript are visible, FAIR, and subject to peer review, F1000Research does not accept submission of supplementary materials. For more information, please see the extended data section in Data and Software Availability.
References and footnotes
References and footnotes can be listed in any standard style if it is consistent within a given article. We allow both references and footnotes within an article (a full reference list within text citations, and explanatory footnotes).
Our basic requirements include:
- Abbreviations and journal names should align with discipline specific standards.
- Preprints can be cited and listed in the reference list.
- Unpublished abstracts, papers that have been submitted to a journal but not yet accepted, and personal communications should instead be included in the text; they should be referred to as ‘personal communications’ or ‘unpublished work’ and the researchers involved should be named. Authors are responsible for getting permission to quote any personal communications from the cited individuals.
- Web links should be included as hyperlinks within the main body of the article, and not as references.
- Datasets published or deposited elsewhere (for example, in a general repository) should be listed in the “References” section and the citation to the dataset should follow one of these examples.
Figures and Tables
All figures and tables should be cited and discussed in the article text. There is no limit to the number of figures and tables you can have. Figure legends and tables should be added at the end of the manuscript. Tables should be formatted using the ‘Insert Table’ function in Word or provided as an Excel file. For larger tables or spreadsheets of data, please see our data guidelines for further information. Files for figures are usually best uploaded as separate files through the submission system (see below for information on formats).
Any photographs must be accompanied by written consent to publish from the individuals involved. Any distinguishing features, including medical record numbers or codes in the case of clinical images that could be used to identify the patient or participant concerned must be removed from the images.
Titles and legends: Each figure or table should have a concise title of no more than 15 words. A legend for each figure and table should also be provided that briefly describes the key points and explains any symbols and abbreviations used. The legend should be sufficiently detailed so that the figure or table can stand alone from the main text.
Permissions: If reusing a figure or table from a previous publication, the authors are responsible for obtaining permission from the copyright holder and for the payment of any fees (if applicable). Please include a note in the legend to state that: ‘This figure/table has been reproduced with permission from [include original publication citation]’.
Figure formats: For all figures, the colour mode should be RGB or grayscale.
Line art: Examples of line art include graphs, diagrams, flow charts and phylogenetic trees. Please make sure that text is at least 8pt, the lines are thick enough to be clearly seen at the size the image will likely be displayed (between 75-150 mm width, which converts to one or two columns width, respectively), and that the font size and type is consistent between images. Figures should be created using a white background to ensure that they display correctly online.
If you submit a graph, please export the graph as an EPS file using the program you used to create the graph (e.g., SPSS). If this is not possible, please send us the original file in which the graph was created (e.g., if you created the graph in Excel, send us the Excel file with the embedded graph).
If you submit other forms of line art such as flow charts, diagrams or text to be displayed as an image, please export the image as an EPS file (e.g., if creating phylogenetic trees with specialized programs), or send us the original file that was used to create the image (e.g., EPS or AI files if Adobe Illustrator was used, or a DOC, DOCX, PPT, PPTX or equivalent file if Word or PowerPoint was used).
If none of the above options is possible then we also accept uncompressed TIFFs with a resolution of at least 600dpi at the size they are likely to be displayed at (see above).
Photographs and microscopy images: Photographs and microscopy images should be submitted as uncompressed TIFFs with a resolution of at least 300dpi at the size they are likely to be displayed (see above).
Mixed images: Images that are a mix of half-tone images and line art (e.g., annotated gels or images with scale bars) should be submitted as TIFF files at a resolution of 500dpi or vector files (e.g. EPS or Adobe Illustrator files). Please ensure that the text size is at least 8pt and lines are thick enough to be clearly visible at the size the image will be displayed.
Images to be used as data: If you are submitting photographic images as part of your raw dataset, please submit them as uncompressed TIFF files.
Electronic manipulation of images: The clarity of figures may be improved using image-editing software, but this must be done transparently and without misrepresenting the data (and the original, unaltered source data must be provided with the article). Brightness, contrasts or colour balance may be used to enhance electronic images, but such changes must be applied to the whole image; any non-linear adjustments must be made explicit in the figure legend. Specific features within an image must not be added or changed (e.g., amplified, removed or obscured); and if figures are composed from images that have come from different sources, such as different gels, or from different parts of the same source, this must be made clear on the figure (e.g., by adding dividing lines). Authors are required to include details of all modifications made to images published as figures or uploaded as data in the Methods section of an article, including the name of the software (with version number) used to make these modifications. Please see our Policies on Image Manipulation for more information.
Units, Symbols and Mathematical Scripts
There are no strict rules on the format of mathematical scripts however, here is some useful advice:
- Special care should be taken with mathematical scripts, especially subscripts and superscripts and differentiation between the letter “ell” and the figure one, and the letter “oh” and the figure zero.
- It is important to differentiate between mathematical symbols and letters to ensure that these are consistent throughout. Regardless of which symbol you use to represent which constant or unknown (e.g. K could be Kelvin, Kinetic energy, spring constant or a number of others), please make sure the formatting, such as roman or italic, and capitalization of the symbol is consistent throughout and only used to represent ONE constant or unknown for example: C (heat capacity) and c (speed of light); K and k; X, x and × (multiplication) etc.
- In both displayed equations and in text, scalar variables must be in italics, with non-variable matter in upright type.
- For simple fractions in the text, the solidus “/” should be used instead of a horizontal line, care being taken to insert parentheses where necessary to avoid ambiguity. Exceptions are the proper fractions available (e.g., ¼, ½, ¾).
- The solidus is not generally used for units (e.g. m s⁻¹ not m/s). But note can be where convention stipulates electrons/s, counts/channel, etc.
- Displayed equations referred to in the text should be numbered serially ((1), (2), etc.) on the right-hand side. Short expressions not referred to by any number will usually be incorporated into the text.
- The following styles are preferred: roman bold sans serif r for tensors, bold serif italic r for vectors, roman bold serif r for matrices, and medium-weight italic serif r for scalar variables. In mathematical expressions, the use of “d” for differential should be made clear, and coded in roman, not italic. i.e. use the equation function in Word.
- Braces, brackets, and parentheses are used in the order {[( )] }, except where mathematical convention dictates otherwise (e.g., square brackets for commutators and anticommutators; braces for the exponent in exponentials).
- For units and symbols, the SI system should be used. Where measurements are given in other systems, please insert conversions.
- The key with mathematical symbols and expressions is to ensure consistency above all else throughout the document.
If your article contains special characters, accents, or diacritics and you are preparing your manuscript in Microsoft Word, we recommend the following procedure:
For European accents, Greek, Hebrew, or Cyrillic letters, or phonetic symbols: choose Times New Roman font from the dropdown menu in the “Insert Symbol” window and insert the character you require. For Asian languages such as Sanskrit, Korean, Chinese, or Japanese: choose Arial Unicode font from the dropdown menu in the “Insert Symbol” window and insert the character you require.
We can accept specific fonts but only those that are Unicode; this font should be submitted with the article. Please also see the Unicode character code chart.
For transliterated Arabic: you may choose either Times New Roman or Arial. For ayns and hamzas choose Arial Unicode font from the dropdown menu in the “Insert Symbol” window and then type the Unicode hexes directly into the “Character Code” box. Use 02BF for ayn, and 02BE for hamza.
Authors’ Role in the Peer Review Process
F1000Research has a post-publication peer-review model, where the peer-review process takes place after the article has been published. As the peer-review process is author-led, we ask our authors to provide at least 5 reviewer suggestions which are suitable according to our Reviewer Criteria before the article can be published (please see our Finding Article Reviewers page for an explanation of our Reviewer Criteria and tips for finding reviewers).
Once the article is published, authors are expected to continue providing reviewer suggestions until the article receives two peer review reports – our editorial team will contact the authors when more reviewers are required and as soon as a peer-review report is published.
After two reports have been published, we strongly encourage our authors to revise their article according to the reviewers’ comments – this is particularly important if the article hasn’t passed the peer-review process after the first two reports are published, as reviewers can only re-review an article to provide an updated report (possibly with an updated Approval Status) after a revised article version has been published.
Once the revised article version is published, we will notify the original reviewers to ask them to re-review the article as soon as possible. Authors are also welcome to continue providing reviewer suggestions while waiting for any re-reviews from the original reviewers.