Ticket Workflow¶

This document describes how we handle tickets in QE Yam.

General rules of thumb¶

• All tickets that require changes in the code base should be of type action.
• Every ticket should have a parent ticket with the type coordination. Coordination tickets are a sort of master plan for something that is too big for just one ticket.
• At the moment of writing the only target version that we can select for QE Yam is Current.
• Follow the Create ticket guidlines when creating a ticket.

Graphical overview¶

The default path (green)¶

• Tickets start with status New.
• When the ticket is clear enough to work on the status changes to Workable.
• Some team member picks that ticket from the top of the list of workable tickets and assigns himself to the ticket. The status of the ticket switches to In progress.
• The assigne works on the ticket, submits MRs/PRs and fulfills the acceptance criteria. In some cases you might also consider what is described below under "Possible deviations from the default path".
• After PRs or MRs were merged we wait that the changes also work in production and not only in our verifcation runs.
• Then the ticket status can change to Resolved.

The rejection path (red)¶

• Sometimes tickets can be rejected because they are already addressed in another ticket or other reasons. Then the ticket status changes to Rejected and the one that does this change should write a comment about the reason why this ticket is rejected.

Blocking tickets¶

• Sometimes while you work on a ticket you find out, that there are circumstances beyond this current ticket that block you in working on this ticket. In that case switch the status to blocked and comment on the reason for this block.
• If you have blocked tickets,then visit the list of blocked tickets from time to time to see if the reason for the block still exists, if not then switch the status back to In progress.

Closing tickets (blue)¶

• Sometimes you find out that the problem described in the ticket does no longer exist. Then you can switch the status to Closed.

Possible deviation from the default path¶

• If a ticket seems too big or too complex then a good choice is to split up the issue into some smaller and more manageable tickets.
• If you decide to split, then you have 2 possibilities:

Make the too big ticket a sub-project¶

• change the tracker type of this ticket to coordination.
• submit new tickets for the smaller actions steps that have this ticket as their parent ticket.

Just create smaller chunks of work¶

• Decrease complexity of the current ticket by editing the description
• submit new tickets for the remaining smaller steps and use the same parent ticket as the original ticket has. So we keep a simple structure with not too many layers of coordination tickets.

Whatever you chose, please set the status of the newly created tickets to Workable so that also colleauges can take over some of the action steps.