Wiki » History » Revision 6
Revision 5 (ph03nix, 2024-10-21 11:59) → Revision 6/18 (ph03nix, 2024-10-21 12:24)
# Wiki *This page is in preparation* QE-C backlog for Non-PublicCloud tasks (Containers and Images). The PublicCloud backlog is at https://progress.opensuse.org/projects/public_cloud/. The overall scope can be defined by the following domains and their associated tags: |Name|Description|Tag(s)| |--|--|--| |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`| ## 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. The keywords `must`, `must not`, `should`, `should not` and `may` follow [RFC2119](https://www.rfc-editor.org/rfc/rfc2119). 1. Squad members should must take the highest priority tickets first which are marked as *Workable* first. 2. Tickets regarding fixing test issues should always have high priority. 3. Only the PO can sets tickets from New to Workable. Squad member should not set tickets from New to Workable. Workable 4. 3. Tickets for fixing test issues must can be set immediately to *Workable* and the priority to *high*. . Fixing test issues tickets must always have high priority. 5. 4. New tickets must be set to *New* and must contain the domain tags above or `to-be-refined` if unknown. unknown 6. 5. If tickets are unclear, they must be tagged tag them with `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.