Gitlab Issue Tracker - Proposed Workflow

[John Snow]

I'm seeking feedback on our Gitlab issue handling workflow.
(There's a TLDR at the bottom of the mail.)


# Background:

Last KVM Forum, I started experimenting with the Gitlab issue tracker:
https://gitlab.com/qemu-project/qemu/-/issues

At the time, I hastily added some labels to roughly approximate our 
Launchpad issue lifecycle.

Gitlab offers "Scoped" labels that allow us to set a 'category' of 
labels where only one label from that category at a time may be applied.

I created the "Workflow::" scope to create labels for our issue 
lifecycle. You can see how this looks like by visiting our issue board:
https://gitlab.com/qemu-project/qemu/-/boards

Workflow labels can be changed by manually setting or removing tags, OR 
by clicking and dragging issues from one column of the board to another.


# The Workflow:: states we have currently:

https://gitlab.com/qemu-project/qemu/-/labels?utf8=%E2%9C%93&subscribed=&search=workflow

- [Open] - For newly created issues. These show up in the far-left panel 
on the boards view and allow us to quickly see which bugs have not been 
assigned a Workflow:: label. The intent is to keep this list as empty as 
possible, aggressively moving things into "Needs Info" or "Triaged" lists.

- Needs Info: For issues that either cannot be triaged or cannot be 
verified because they lack information. The intent is to allow the CI 
Janitor to close such issues after 60 days of inactivity.

- Triaged: For issues that have been classified (Bug/Feature), and 
sorted into their appropriate topic label(s) -- e.g. Storage, Audio, 
accel: TCG, etc. The intent is that subsystem maintainers will subscribe 
to relevant topics and either re-triage, kick it back to Needs Info, 
assign someone, etc.

- In Progress: For issues that a developer is actively working on. The 
intent was to be able to mark bugs in such a way that contributors would 
not assume they are available to be hacked on. For instance, if a 
non-gitlab contributor submits patches for an issue, we might mark it as 
In Progress so that it does not appear to be going unaddressed.

- Merged: Intended for issues that have had code that is merged, but not 
yet released. This was done to mimic our Launchpad workflow.

- Released: Intended for issues that have had been fixed and packaged in 
a release. This was also added to mimic Launchpad.

- [Closed] - For issues that are resolved in one way or another.


# Some concerns on the above scheme:

- "In Progress" is not likely to be used faithfully and will fall out of 
sync often. It's not clear if there should be a difference between a bug 
having an assignee and a bug labeled "In Progress". I don't want to get 
in the business of managing people's time and forcing them to track 
their work.

At the same time, for bugs being actively fixed by a contributor on-list 
who is not [known to be] present on gitlab, it's still possibly a nice 
courtesy to mark a bug as not 'free for the taking'.

Meanwhile, there are several bugs I "own" but I am not actually actively 
working on. These are the sorts of things that I wouldn't mind someone 
taking from me if they wanted to, so the "In Progress" label provides 
some useful distinction there if someone wished to use it.

I think I am inclined to keep it for now, at least until gitlab adoption 
rate is higher and bugs can be assigned more faithfully.


- Gitlab will automatically close issues that reference the gitlab issue 
tracker from the commit message, but it won't apply the "Merged" label, 
so it's at risk of falling out of sync.

Closed issues retain their "Workflow::" labels, but won't show up in the 
issue search by default unless you ask to include closed issues as well.

I think we can likely just drop this label, and have bugs go directly 
from whatever state they're in to "Closed". The issue board will look 
cleaner and there's less custodial work for maintainers.


- Similarly to the above concern, "Released" is extra paperwork for us 
to maintain. I recommend instead we drop the label and begin using 
"Milestones" for each release, and attaching issues we have fixed or 
want to fix to specific Milestones. This will give us a way to track 
pending issues for release candidates as well as a convenient list, in 
the end, of which bugs were fixed in which specific release, which is 
far more useful than a "Released" tag anyway.


- "Triaged" is a very lightweight label that I created only to mean that 
the bug has been seen and tagged, which will hopefully deliver it to 
someone's queue that they are paying attention to. It does not 
necessarily mean "Tested and Confirmed". It's possible we may want a new 
label "Confirmed" to help us sort through reports in a way that's a 
little more meaningful than just "triaged".


# TLDR:

- Let's keep "Workflow::In Progress", but acknowledge it as informative
  instead of exhaustive.
- Let's drop "Workflow::Merged" and just rely on the auto-close feature.
- Let's drop "Workflow::Released" and use the Milestones feature to help
  us with our changelog auditing.
- Let's add "Workflow::Confirmed" to help distinguish lightly-triaged
  bugs from serious, actionable bugs.


If I don't hear back, I'll assume everyone agrees and start making the 
changes.
(Though, to manage milestones, I'll need the 'Developer' role.)

Thanks,
--js