Software Checklist

The following checklist is to help to support collaborative development and reproducible software, and the points come by way of the Contributor Friendliness Assessment of the Contributor CI package. Check the points that apply, enter the name of your repository, and then click the generate button.

Score: %

Repository

• Repository: The source code is available at a public url.
• Versioning: The software has a method to support versioning.
• Contributing: The repository has a CONTRIBUTING.md or contributor guide.
• Issues: An issues board is available for a user to ask a question, or request support.
• Statement of Need: A clear purpose or statement of need is defined. A reader knows what the software does.
• Branding: The GitHub repository and/or documentation has logo, graphics, or other decoration

Quality

• Naming: Naming of variables, classes, and functions is easy to understand.
• Commenting: The code is robustly commented.
• Organization: Files and directories are organized meaningfully.

License

• License: The GitHub repository has a clear license
• OSI Approved: The license is an OSI-approved license [ref]

Examples

• Readme Examples: The README.md has one or more examples of usage.
• Documentation Examples: The documentation has an expanded set of examples (e.g., tutorials)
• Code Examples: Examples are included via scripts or documentation

Outreach

• Conference Presentations: The project has been presented at one or more conferences.
• Publication: The project has been published in a journal.
• Social Media: The project has a social media handle or account.

Documentation

• Availability: The project has a visible link to documentation
• Getting Started: There is a clear "Getting Started" guide with installation and simple usage.
• Interface: The documentation renders in a web interface for a more user-friendly exploration.
• Programmatic: Documentation renders from a readable, plain-text format
• Version Controlled: Different versions of documentation for various releases are available.
• Docstrings: If appropriate for the language, docstrings are rendered into code documents.
• Functionality: All functions, client interactions, and if appropriate, API endpoints, are documented.
• Living Documentation: A user can easily jump from any documentation page to ask for help, or contribute changes [ref]

Artifacts

• Containers: The repository provides one or more container recipes (Dockerfile, Singularity) or a pre-built container.
• Changelog: The project has a CHANGELOG and/or provides changes in release notes.
• Digital Object Identifier: The repository has an associated DOI for citation, or a CITATION.cff

Development

• Developer Guide: The documentation provides a developer guide for building and installing
• Established Framework: The project uses an established build framework or strategy
• Requirements: Requirements or dependencies are clearly stated.

Continuous Integration

• Automated Testing: Testing is done with any request for change to the main (typically main) branch.
• Testing Instructions: The documentation states how to run the tests.
• Continuous Integration: The tests are run with continuous integration.

Generate