We want ScoresLabs projects to find developers and we want developers to be able to make successful contributions to the projects they select. Two main requirements need to be met.
Best practices in documentation need to be clear in the readme and also easy to emulate and extend in the code and organization.
Developers need to be able to test their work and rely on some form of public showcase that their efforts have been valuable and appreciated.
Before we declare a repo and/or project is open to contributions, the following criteria should be met, in any way possible:
- readme.md explains the goals of the project, the user/audience, success criteria, technical needs and reference material
- readme.md explains how to set up a development environment
- design and feature documentation descibe user- and technical-acceptance criteria that developers can understand and confidently build (and unit-test) for. In other words, a developer should be able to perform some level of testing, locally, to verify their solution is ready for review.
- Student and user (e.g. Coach) safety and privacy is effectively protected in the code and documentation as well as permission scheme and testing strategy. This is a primary concern to reviewing pull requests, going forward, but must start with a intelligently organized, and reviewed repo.
- Project and issues are enabled and reviewed. At least one issue should be present, as a reference standard to how we want issues and stories documented, including dependencies on issues in other repos, acceptance criteria, and milestones.
- Developer Pages are enabled, including a plan for showcase material, if it is not already integrated