Ticket Workflow » History » Revision 4
Revision 3 (rainerkoenig, 2023-11-24 10:01) → Revision 4/5 (rainerkoenig, 2023-11-24 13:24)
# 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](https://progress.opensuse.org/projects/qe-yast/issues?query_id=869) **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](https://progress.opensuse.org/projects/qe-yast/issues?query_id=903) 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 steops 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 those new tickets to `Workable` so that also colleauges can take over some of the action steps.