Process workflow for ticketing systems like Pivotal and Jira

Ticketing workflow.md

1. Create a ticket;
   1. add a title, description, labels, discrete tasks
   2. assign the owner as the person who should complete it
   3. assign points, if known and points are supported
2. Decide the type of task;
   1. New features or significant functionality should be features
   2. corrections to existing behavior should be bugs
   3. tasks (like communication) outside of the codebase should be chores
3. Decide the scope of a task;
   1. If the ticket is a post-launch or “parking lot” request, keep it in the icebox
   2. If the ticket is immediately eligible for work, keep it in backlog
4. Decide the points of a task, if points are used in this build,
   1. 1 point is less than an hour
   2. 3 points is a day
   3. 8 points is about a week of work
5. The owner should review the ticket, ask for clarification, and improve it as needed;
6. When the owner has begun a task, it should be statused as started. This could just be creating a feature branch or to acknowledge acceptance of the ticket.
7. If the ticket is invalidated, unverified, or unnecessary,
   1. add comments explaining such
   2. set status to deleted
8. If the ticket is delayed and will be continued later
   1. add comments explaining such
   2. set status to not yet started
   3. set scope as icebox
9. When work for the ticket is complete,
   1. set status to finished
   2. change the ticket owner to a person that should review and confirm the work;
   3. codebase changes should also have pull requests as defined in README.md
10. The reviewer should communicate any blocks to delivery, such as waiting for the outcome of an API call, and when confirmation is possible
11. After the reviewer confirms the work of the ticket is correct, he or she sets status to delivered and accepted
12. When using Pivotal or Jira, progress in GitHub commits can be logged to the ticket by adding "[#999999]" to the commit message, where the numbers are the ticket ID
13. If the ticket’s task is simple, obvious, and absolutely does not need review (chores), the owner may set status to finished, delivered, and then accepted