This article provides a definition of ready to enable a development team to decide when a task is ready to be started with.
The target audience are developers contributing to one of my projects, be it open source or commercial. It can also be of interest for people who are looking for a basis for their own guidelines.
This document is distributed under the CC BY 4.0 license.
These guidelines only apply to issues once they enter the state "ready". During earlier states ("new", "backlog") issues only need a descriptive title. Everything else can be empty and added as more details emerge.
TODO: Guidelines for title
As (role) I want (feature) so that I can (have value).
Internal: All TODO#123 comments are resolved.
Optional: At the end of the "Goals" section the estimated effort is noted. For example:
Rationale: This can be used by Siisurit to compare it with the actual effort from time tracking.
When a feature issue went into production and turned out not to work as expected, create a bug issue.
- Steps to reproduce
- If the bug cannot be reproduced yet, mention this here.
- Actual result
- Expected result
When a pull request is ready to be reviewed:
The title references the original issue starting with the issue number.
Example: pygount#107 #106 Clean up source analysis from file
The text refers to the original issue, either as:
The pull request has no labels.
Rationale: Relevant labels are already set at the original issue. Setting the same labels here would be redundant and error-prone.