Definition of Done

This is a draft, to be a living document, first experimented with by Team Ruru

As a team, it's important we have an agreed understanding of what it means for a piece of work to be considered "done". It defines the level of quality we commit to, and what others can expect from our software once we say something is done.

To be discussed:

• Done = value delivered... and what this means in our context, where a deployment may be a long time after we release
• Issue management - how can we make issues best work for us, we want small manageable PRs, but to capture carry over well
• Testing
  • Unit testing of single-task logic methods (dependencies mocked)
  • Workflow tests (like the tests for our service methods, check that it all hangs together correctly) - should just be for key use cases?
  • Integration tests (...E2E 👀)
  • GraphQL API contract tests
• No bugs (workflow bugs)
• Documentation
  • External documentation drafted as part of the issue
    • This might look like having the steps drafted, leave screenshots until feature is complete
  • If any new flows, patterns etc. are added, internal documentation should be written
  • If you go looking for documentation for something...
    • If it exists, link to it from the places you looked first
    • If it doesn't exist, and you've had to do some learning, write it up!
• Practices
  • Where encountered/created, code duplication is removed
  • Frontend logic and display is separated, so logic can be tested
  • Feature flags until done - so release/deployment not blocked by incomplete feature 👀