The definition of done is exactly what you think: a list of criteria that has to be met before any work can be considered done. Failure to meet any one of these conditions means the work is not complete.
At dwyl, we consider the definition of done to be one of the most important parts of a project if not the most important.
Having this means that everyone who works with dwyl knows what to aim for in terms of code quality which facilitates the integration with the rest of our codebase and saves everyone time, which is of course our stated aim!
We will keep adding detail and examples to this as we gain understanding of any ambiguities that come up.
For clarity, a task/pull request will not be considered to be complete until all these items can be checked off.
- Task has its own GitHub issue (something it is solving)
- Estimate of expected time required to complete task was agreed with all present and recorded before starting the task
- Issue number is included in the commit messages for traceability
- Record actual time taken for the task in the PR
- Update the README.md with any changes/additions made
- Your code follows the dwyl style guide
- 100% test coverage
- All tests pass
- Descriptive pull request text, answering:
- What problem/issue are you fixing?
- What does this PR implement and how?
Example Pull Request: indexzero/ps-tree#12
-
Assign your PR to someone for a code review
- This person will be contacted first if a bug is introduced into
master
- This person will be contacted first if a bug is introduced into
For brownie points:
- User testing of front-end features with notes!
- Video walkthrough of using the feature/functionality created [example needs to be created]