| Software is archived in a scholarly repository |
The source code repository is archived in a scholarly repository (e.g Zenodo, HAL) to ensure that software can be found and accessed in a scholarly context |
|
| Software is archived in Software Heritage |
The source code repository is found in the universal source code archive, Software Heritage, to ensure long-term access to the full development history. |
|
| CodeMeta completeness |
This indicator checks that the codemeta file is sufficiently complete (according to community expectations). That is, the percentage of properties that are filled with metadata is above an acceptable threshold established by a target community. This indicator does not assess the quality of the metadata fields available. |
Software metadata
|
| Software has dependency management solution |
Reviews how external libraries and dependencies are managed to ensure compatibility and security. |
|
| Software has descriptive metadata |
This indicator aims to determine if a software component comes with descriptive metadata that provides information. This includes, but is not limited to: name, domain, programming language, date created, date of first publication, keywords, related links, etc.. |
Software metadata
|
| has a measure of functional correctness |
For analysis code specifically, is there a quantifiable measure of the functional correctness of the software output. This indicator focuses on computational/statistical correctness. For example, in an ML model software context, the indicator measures whether the repository reports metrics like Accuracy, F1-score, or ROC-AUC to prove the model performs as intended. However other performance metrics may also address the indicator. Evaluation metrics may be provided through documentation, tables or scripts available in the source code of the target tool. |
|
| Software has continuous integration tests |
This indicator aims to determine if the project runs tests before pull requests are merged. |
|
| Software has no linting issues |
The project addresses or resolves warnings identified by compilers, safe modes, or linters. |
Writing readable code
|
| Software is published as a downloadable package |
This indicator aims to determine if a software project is published as a downloadable package. |
Packaging software
|
| Software has releases |
To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. This indicator determines if a software project has releases. This can be achieved by looking for tags or using software that retrieves related data. |
|
| Software requires human code review. |
This indicator aims to determine if a software project requires human code review before pull requests. |
Performing a code review
|
| Software is listed in a registry |
The target source code repository is in a disciplinary or community registry (e.g ascl.net, bio.tools, swMath, RRID portal, RSD, WikiData, DataCite, etc.) to ensure that software can be found and accessed. |
|
| Software has up-to-date metadata |
Metadata information reflects the current description of a software project. This indicator ensures that the current project metadata provides up to date, accurate and relevant information about a software component. |
|
| No critical vulnerabilities |
Checks if reported critical vulnerabilities have been fixed |
|
| No leaked credentials |
Checks if hardcoded secrets like passwords, API keys, and tokens is stored in the public git repository |
|
| Software has persistent and unique identifier |
This indicator tries to determine if the software identifier is based on a suitable identifier scheme, and test it can be resolved. This is done by checking if the identifier uses an identifier scheme contained in a list of globally unique identifier schemes |
Software identifiers
|
| Software has ci/cd workflows in its repository |
This indicator tries aims determine if a software project makes use of workflows to automate processes like testing and deployment. |
|
| Software specifies requirements |
This indicator tries to determine if the project specifies what is required to use the software. |
Reproducible software environments
|
| Software uses citation |
This indicator aims to determine if the project uses a citation to reference contributors and authors (e.g., through a CFF file, in the README, etc). |
|
| Software has documentation |
This indicator aims to determine if a software project comes with many forms of documentation like readme or readthedocs |
Creating a good README
Documenting code
Documenting software project
Documenting software using 'Read The Docs'
Software documentation
|
| Software has license |
This check tries to determine if the project has published a license |
Licensing software
|
| Software provides tests. |
Evaluates the extent to which the software has been tested, including unit tests, integration tests, and system tests, to ensure reliability and correctness. |
Testing software
|
| Software has sufficient test coverage |
Indicates that the test suite covers most (or ideally all) the code branches, input fields, and functionality |
|
| Has static analysis for common vulnerabilities |
At least one static code analysis tool used includes rules or techniques to detect common vulnerabilities specific to the language or environment. |
|
| Software provides issue tracking |
The software project offers an accessible issue tracking system (e.g., GitHub/GitLab Issues or a helpdesk) that is used to report, document, and manage bugs, enhancement requests, and user-facing operational issues. |
|
| Software uses fuzzing |
This indicator checks that the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. |
|
| Software uses a tool for warnings or mistakes |
This indicator checks that the project enables one or more compiler warning flags, a "safe" language mode, or uses a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. |
|
| Software makes use of version control |
This indicator aims to determine if a software project uses version control. |
Using version control
|
| Software follows versioning standards |
This indicator aims to determine if the version (or versions) of a software tool follows an established community convention like semantic versioning (SemVer) or calendar versioning (CalVer). |
|