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
