QA (public) » openQA Project (public) » openQA Tests (public) » Containers and images

QE-C backlog for Non-PublicCloud tasks (Containers and Images). The PublicCloud backlog is at https://progress.opensuse.org/projects/public_cloud/.

The keywords `must`, `must not`, `should`, `should not` and `may` follow [RFC2119](https://www.rfc-editor.org/rfc/rfc2119).

# Containers and Images backlog

The overall scope can be defined by the following domains and their associated tags:

|Name|Description|Domain tag|

|--|--|--|

|Container|Tickets that affect testing of the container engines (`podman`, `docker`, ...) and container images (BCI, SAC, Base images, RMT, ...) | `container` |

|MinimalVM images|MinimalVM (former JeOS) testing|`MinimalVM`|

|SLE-Micro images|Testing of SLE-Micro images. This should not include container engines on SLE-Micro.|`slem`|

|WSL images|Testing of Windows Subsystem for Linux|`wsl`|

Every ticket must contain exactly one of those domain tags. If not applicable the tag `to-be-refined` must be used.

## Housekeeping

We follow the rules of https://progress.opensuse.org/projects/openqav3/wiki/Wiki#ticket-workflow. In addition, the following rules are specific for this backlog. Lower number rules have precedence.

1. Squad members should take the highest priority tickets marked as *Workable* first. 

2. Tickets regarding fixing test issues should always have high priority.

3. Only the PO can tickets from New to Workable. Squad member should not set tickets from New to Workable.

4. Tickets for fixing test issues must be set immediately to *Workable* and the priority to *high*.

5. New tickets must be set to *New* and must contain the domain tags above or `to-be-refined` if unknown.

6. If tickets are unclear, they must be tagged `to-be-refined` and set then to *New* . Every squad member is allowed to set ticket from *Workable* to *New*.

7. Tickets should always be the smallest actionable item. If a task can be split into two tickets, it should be. Larger topics should be organized via epics/sagas.

Good tickets should provide sufficient context, i.e. a description of why this is required or at least links to relevant sources. If you believe a ticket is incomplete, follow rule 6 and ping the owner of the ticket.

Tickets should always be the smallest actionable item. If a task can be split into two tickets, it should be. Larger topics should be organized via epics/sagas.