[High-level description, describing what exactly software does.]
[Why the software does things the way it does and why it was designed in the first place. What problems are solved by it. Links to publications and comparisons to similar software.]
[If the software does make high demand on particular resources, then this should be clearly advertised and explained.]
[This may be described in a separate INSTALL file, but the README must then clearly state this.]
[How the first task can be performed with the software, or, in the more extensive documentation, a link to the quick start. Outlines how to quickly get started with the software using a basic yet practical example]
[Website where the software is described and allows users to obtain it as well as its documentation.]
[Defines the set of rules and conditions for people who want to use the software.]
[It should be clear where to go for support, for example: alquicir@ccg.unam.mx.]
[This may describe the state of the code, providing the necessary guidance on which aspects could be improved]
Accessibility
- Unique DOI identifier (Please update identifier and link)
- Version control system
Documentation
- README file
Learnability
- Quick start
Buildability
- INSTALL file
Identity
- Website
Copyright & Licensing
- LICENSE file
Portability
- Multiple platforms
- Browsers
Supportability
- E-mail address
- Issue tracker
- Slack
- Gitter
Analysability
- Source code structured
- Sensible names
- Coding standards - style guides
Changeability
- CONTRIBUTING file
- Code of Conduct file
- Code changes, and their authorship, publicly visible
Reusability
- Source code set up in a modular fashion
Security & Privacy
- Passwords must never be stored in unhashed form