OSS checklist

[filipblnt]

Set Up

Basics

• Code repositories and issue trackers are present (best options: GitHub or Gitlab)
• No special permission or specific institutional affiliation is required to access the repositories and issue trackers
• No special permission or specific institutional affiliation is required to clone, build and run the project
• Project has an associated website
• No special permission or specific institutional affiliation is required to access any page of the website
• Website features a project description of less than 100 words
• Project description is consistent across platforms
• Project has an associated demo web application (if web based)

Naming and Presentation

• Project has a cool name that people can easily remember or reflects the purpose of the project
• URL of the repository and title of the README contain the name of the project
• URL of the repository and title of the README are clear, concise, and do not include any dispensable word

User documentation

README

• Project has README.md file in its root directory
• README specifies the purpose of the project
• README content is clear, concise, and complete
• README content makes no infringements to the plain language guidelines
• README contains a link to the demo web application (if applicable)

Usage

• README contains installation instructions for every platform
• Installation can be done by downloading and executing a binary file or by copy-pasting the installation steps
• README contains a list of system requirements (if applicable)
• README contains a high level feature overview
• Usage manual can be accessed from the product (i.e. help page for web apps, help command for CLI)
• Usage workflows are documented (with associated media - images, gifs, videos...)

License

• Project use a valid license according to the Blindnet Open Source Program
• Project does not require a contributor licensing statement or agreement
• Project does not feature code with per-file licensing
• Repository contains a LICENSE file containing the whole text of the license
• README contains a link to the LICENSE file
• License is consistent across the whole project (website, documentation, configuration files, code, etc.)
• License is referred to in every packaged distribution of the project (e.g. npm - package.json)
• Project doesn't contain any obvious code or dependency that could constitute an infringement of the license

Development

Contributing Guidelines

• The project includes a CONTRIBUTING.md file in its root directory
• Project clearly identifies opportunities for contributions of different types (code, documentation, design, etc.)

Developer Documentation

• Repository includes a complete developer documentation
• Developer documentation includes all installation steps, including prerequisites (with link to the specific part in the tool documentation whenever needed)
• Anyone, on any operating system, can fulfill the prerequisites for development (dev and testing tools) within an hour
• Repository includes information on how to build the project locally
• Repository includes information of projects architecture and design choices
• Repository includes infromation of used depencies and motivation behind choosing each of them
• Documentation is stylistically consistent
• Anyone can easily report a documentation related issue
• Anyone can easily contribute to the documentation
• Project creates and maintains documentation via automated processes

Testing

• Repository includes testing tools
• Repository includes unit tests
• Repository includes a complete documentation of esting tools, methodes and conventions
• Anyone can install testing tools and run the tests by only refering to the documentation

Release management

• Release policies are documented in the repository and/or website
• Releases follows a consistent versionning conventions (semver is recommanded by default)
• Release process is automated and documented
• Release process include clear guidelines to document changes and intentions in every release
• All releases are well documented
• Project publish releases at consistent intervals
• Project has implemented a quality assurance process
• Project uses automated continuous integration and development tooling
• Project releases are available from consistent download location
• Project releases software in multiple formats

Activity

• Project has issued a release in the past 12 months
• Project releases software at consistent intervals

Organisation

Governance

• Project has clearly identified lead maintainers
• Project has identified means of contacting lead maintainers
• Project has identified various roles contributors can occupy
• README and CONTRIBUTING make mention of the Blindnet Openness Framework
• Project makes and records decisions publicly according to the Blindnet Openness Framework

Code of Conduct

• A Code of Conduct has been defined for the project
• Code of Conduct is presented in README and CONTRIBUTING
• Anyone can easily identify where and how to report an infraction to the Code of Conduct
• Anyone can report an infraction to the Code of Conduct without any other requirement than having access to a largely used tool (e.g. email client or web browser)
• Report of an infraction to the Code of Conduct can be treated in less than two working days