Issue labe improvements

[Ján Tomko]

s/labe/Elbe/ or s/labe/label/ depending on which one you meant

On a Wednesday in 2021, Peter Krempa wrote:
>Hi,
>
>from time to time when I try to go through upstream issues I always feel
>that the labels we have are suboptimal and don't always allow to track
>the current state of the issue.
>
>Recently I've had a look at the qemu issues and found what I was
>lacking.
>
>Specifically I'm lacking the 'workflow' class of labels they use.
>
>I propose we adopt the following changes:
>
>1) Convert the existing 'bug', 'enhancement', 'support', and
>'discussion' labels into a set of scoped labels (again inspiration taken
>from qemu):
>
> kind::bug
> kind::enhancement
> kind::support
> kind::discussion
> kind::documentation
>
>This is mostly as the above kinds are mutually exclusive.

Makes sense.

 From the group labels:
https://gitlab.com/groups/libvirt/-/labels
this leaves:

   bitesizedtask
     this refers to the scope/difficulty of the issue
     I think it's mutually exclusive with gsoc::ideas and gsod:ideas,
     so we could replace those with:
       scope::Bite Sized
       scope::Summer of Code
   ci
     refers to the area/subcomponent of the project
     Could be mutex with driver:
   critical
     I also don't think we need this.

>
>
>2) Introduce the workflow label similarly to what qemu uses:
>
> workflow::Confirmed/Triaged (<- confirmed for bugs, triaged for
>                               enhancements)
> workflow::Needs Info (replaces "needinfo")
> workflow::In progress (replaces "Doing")
>
>I'd also potentially like to have a 'Unconfirmed' state for when the
>bug has enough info, but it's unknown why it's happening.
>
>I want to specifically avoid the ambiguous "Triaged" when used on it's
>own.

QEMU's workflow::Triaged label is described as:
    Issue has been triaged and given a topic label.
This seems pointless - you should be able to find that out from there
being labels on the issue.

Confirmed makes sense for bugs that were reproduced. For enhancements,
I don't see a need to have a workflow label, unless the idea is that
every issue will have a workflow label.

>
>3) Convert host-* labels into a scoped label. Hosts are usually mutually
>exclusive
>

Agreed. And if we're moving away from lowercase labels, we can spell
them as Linux, FreeBSD and whatever the latest preferred spelling of
macOS is.

>4) Convert driver-* into scoped labels. Usually issues are not exceeding
>these boundaries
>

We also have:
   api
   cpumodel
   daemons
   security-apparmor
   security-selinux
   virsh
   xml

To some extent these are mutually exclusive with drivers (and also 'ci')
so we could scope them together. Something like:
   area::ci
   area::qemu
   area::selinux
   area::virsh

I'm not sure whether there is any value in having both 'qemu' and
'selinux' labels on a bug affecting QEMU driver's use of SELinux.
There's definitely no point in labeling a new API for QEMU driver with
'api' 'qemu' 'virsh' 'xml'.

The usage of the 'xml' label is also confusing - we have it on an issue
requesting more virsh completions as well as QEMU feature requests.

If we keep it I'd say it should be only for issues that are exclusively
in the formatter/parser.

>5) Remove the following unused or ambiguous labels:
>
>  - critical
>  - incident
>  - Doing
>  - To Do
>  - gsoc::20* (all seem to be unused)
>
>
>I'm willing to go ahead and re-triage open stuff if nobody objects to
>the above changes.
>

Let me know if I can help.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20211210/57ae8bbd/attachment-0001.sig>