Issue labe improvements

[Daniel P. Berrangé]

On Wed, Dec 08, 2021 at 04:34:27PM +0100, 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.
> 
> 
> 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.
> 
> 3) Convert host-* labels into a scoped label. Hosts are usually mutually
> exclusive

This is not desirable, we can easily hauve issues that
affect both FreBSD and macOS at the same time.

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

Again, this is not desirable, as I consider those labels to
mean that it /affects/ users of that driver, rather than it
being in code only related to that driver.  IOW, if there is
a cgroups bug it is relevant to want to put a label of qemu,
lxc and ch.

> 5) Remove the following unused or ambiguous labels:
> 
>   - critical

I think this is useful as a way to mark an issue as very
important.

>   - incident

This feels redundant since we're not providing production
support for some service.

>   - Doing



>   - To Do

'To do' is really just anothuer work for 'enhancement'

>   - gsoc::20* (all seem to be unused)

The intent of gsoc labels is that we'll use those to track
gsoc ideas instead of the wiki. When someone starts working
on a particular project, it'll get tagged with the year.
I was intending to copy over historical content from the
wiki prior to deleting the wiki

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|