Definition of done

At Delft Solutions we aim to have a shared understanding what it takes to release an incremental update to one of our projects. Having a shared understanding of what it means to call something **done** also means we don't have to ask "But is it _really_ done?" or "Hey you said it was done but I don't see it, where is it?".

Functional Requirements

These are the _business_ requirements that emerge through conversation about a particular issue or feature, as well as the requirements listed in the issue (acceptance criteria).

Quality

In order to keep the code maintainable and relatively bug-free, as well as broaden the amount of people that know about a certain feature's implementation, we expect PRs to be peer-reviewed and senior-reviewed (someone senior to the project, or, if not available, senior in the company).

Any automated analysis that runs on a project should also be without errors. When there are warnings, it should be explained _why_ the warning isn't resolved. Yes, some of this tooling sometimes gets it wrong, but overall they make the code more consistent in style, and it often prevents a lot of common issues.

The code must be tested. This can be a manual test or an automated test. If changes are made after the test has been performed, the test **must** be performed again.

Non-Functional Requirements

- No known defects - No build failures - No errors in coding standards (automated analysis) - Existing tests passed - Peer code review passed - Deployed (if applicable)