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

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

Onboarding guides

• README and project website contain the installation guide
• Installation guide is clear and ideally can be performed by just copy-pasting the installation steps
• README presents a minimum viable feature that hooks the user
• Project is stable enough to offer this minimum viable feature without any bug or performance and security issue
• README and project website contain the quick start guide
• README explains the quick start in a few lines
• Project website features a more detailed quick start guide
• Quick start code should work without any bugs or performance issues
• An example project containing the quick start code should exist
• README has a link to contributor guidelines
• Project website features a quick start guide for new contributors
• Project website features a detailed contributor guidelines
• README underlines at least one undebatable and objective strength of the project
• Minimum viable feature confirms the presented strengths of the project

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

Communication channels

• Project features communication channels exclusively for new users and contributors

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.)
• Repository includes a complete developer documentation
• Requirements for development can be fulfilled on Linux
• Requirements for development can be fulfilled on Mac OS
• Requirements for development can be fulfilled on Windows
• Anyone can fulfil the prerequisites for development within a reasonable amount of time; ideally, less than an hour of manual work (not including the building time, downloading dependencies 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

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

Documentation

• Documentation is available online
• Documentation has a home page
• Documentation has links to the project's repository and the blindnet website
• Documentation includes a complete yet straightforward tutorial
• (if applicable) Project as en embedded documentation (e.g. --help option for a CLI)
• Documentation covers common use cases
• Documentation contains usage guides
• Documentation contains full API description and reference
• Documentation contains project's glossary
• Documentation contains information of inner workings of the library (i.e. explanation of an encryption protocol)
• Documentation is searchable
• All users and community members can easily find the documentation (i.e. a link exist and stand out in the README and website)
• Documentation doesn't present any bug on any tool used to consult it (e.g. a documentation website can be read with any evergreen browser)
• Anyone can easily report a documentation related issue
• Anyone can easily contribute to the documentation
• Documentation contains release notes
• Community members are encouraged to propose improvements to the documentation
• Documentation makes as few infringements to plain language guidelines as possible
• Documentation appears complete
• Documentation is stylistically consistent
• Project features documentation specifically aimed at new users
• Project has thoroughly documented installation processes
• Project has thoroughly documented process of compiling source code
• Project creates and maintains documentation via automated processes

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