CHECKLIST.md

Level 1 Essentials

Minimal requirements, should always be done:

• Uses version control (e.g., github, gitlab, codeberg)
• Uses a public repository
• Has a license
  • Open source license (OSI Approved License)
  • Dependencies should be clearly specified.
  • Licenses of all the dependencies are compatible with chosen license 
• Archived in a scholarly repository (Zenodo, 4TU, Software Heritage)
• Has a persistent identifier (DOI, SWHID)
• Has descriptive metadata (CITATION.cff / CodeMeta)
• Explanation of purpose (e.g. in README.md)
• Basic usage & installation instructions (e.g. in README.md)
• Use of AI clearly specified (i.e., using the AI declaration format)

For NLeSC projects:

• Registered on the RSD as a project output

Level 2 Advanced

• Versioning:
  • Regular releases
  • uses versioning scheme (semantic or calendar versioning)
  • Versions have a distinct persistent identifier
  • A changelog is maintained
• Dependency management solution (e.g., npm, pypi, mvn)
  • dependency versions are explicit stated
  • dependencies on external APIs, services, special hardware, etc. clearly specified
• Testing
  • Uses static analysis (linting)
  • Automated tests with sufficient coverage
    • Unit Tests
    • Continuous Integration
    • End-to-end testing
• Security:
  • No known critical vulnerabilities
  • No leaked credentials (secrets, API tokens)
• Documentation
  • User documentation (docs site)
  • Developer docs
  • Code documentation
  • Tutorial / examples
  • Quick start
• Development practices:
  • Coding style
  • Issues
  • PRs
• Community:
  • Listed on an community registry (e.g., RSD, bio.tools, etc.)
  • Clear contribution instructions (e.g., CONTRIBUTION.md)
  • Clear code of conduct (e.g., CODE_OF_CONDUCT.md)

For NLeSC projects:

• Registered on the RSD with a full software page and linked to relevant project pages

Level 3 Professional

• Published in package manager and/or container registry
• Developer documentation:
  • architecture and design choices
  • API documentation (if applicable)
• Development practices:
  • Branch protection
  • Code reviews
  • Roadmap
  • Milestones
• Security:
  • Automated vulnerability checks
  • Security policy documented (e.g., SECURITY.md)
• Community:
  • Communication channel (e.g, Slack, Discourse)
  • Sufficiently high bus factor (both for leading developers and organisations)
• Governance:
  • Clear description of govenance model (e.g., GOVERNANCE.md)