Definition of done
We have a clear definition of what we consider to be done. These are the exit-criteria to determine if an implementation is complete. The actual coding part is only part of what actual done is. The definition of done is used actively when pull requests are reviewed.
This is our definition:
Core to everything coming through a pull request; it must be functional software. This means it should have been tested by the developer or confirmed tested by a tester, or automated tests / specifications.
Adhering to our values and principles
Following our expected structure
Has automated specifications (tests)
We do not look at code coverage as a metric, but we look at the logical coverage. We expect our code to have automated specifications (tests) around it on a unit level. We look for behavioral specifications.
Has API documentation (XML, JsDoc, etc..)
All public APIs should have documentation around them, which is language specific and can be automatically extracted and generated API documentation for our documentation site
Has general documentation
Documentation is important to have and to maintain on changes. It is expected that any minor version bump contains the documentation for whatever is new and a major to contain the documentation for what has changed. Read more on how to contribute to documentation here.
Schemas for public formats
If exposing formats like JSON files that should be made available, create or remember to update the schema for it for it to be published. E.g. Schema Store
Ready to be deployed
Code should be ready to be deployed. Pull requests should never be made unless the code is ready to be deployed. The definition of what deployment is, is defined by each repository. For some it means deploying a package that can be consumed publicly. Which means it needs to be production ready. For other repositories, it could mean it needs to be ready to deployed to a staging environment - typically for applications being used by users.