QA » openQA Project » openQA Tests » qe-yam

# 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 

![Ticket workflow](twf.png)

## 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 tickets to `Workable` so that also colleauges can take over some of the action steps.