Re: Gitlab Issue Tracker - Proposed Workflow

[John Snow]

On 5/4/21 2:52 PM, Daniel P. Berrangé wrote:
> On Tue, May 04, 2021 at 02:33:58PM -0400, John Snow wrote:
> > I'm seeking feedback on our Gitlab issue handling workflow.
> > (There's a TLDR at the bottom of the mail.)

> > - 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.
>
> If someone is actively working on it, they could just stick a comment
> on the issue, possibly with a mailing list posting.
>
> With a simple "in progress" flag you can end up marking things as if
> someone is working on it, but then they go off and do other things.
>
> If you just have a mailing list posting/comment, you can at least
> see how up2date that comment was and judge whether the person is
> still caring about the bug.

I can see this critique. OTOH, and as Peter has written, it's also a 
fine way to find a list of candidate bugs that we may have forgotten about.

Ideally people still post a link to the patch if they move it to "in 
progress" so we get the benefits of both methods. I usually try to link 
to a mailing list thread whenever I update a BZ/LP like this. I can keep 
that habit alive here.

It might be fine as simply an informational state that we just don't 
treat as authoritative/exhaustive.

> > - 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.
>
> Yeah, if we really wnat to record release info against bugs, then the
> milestones looks more useful, but....
>
> Generating a list of bugs in the release is only useful if that list
> is reasonably complete. That means we need someone who really cares
> about this because most people will never bother to set a milestone
> and so some janitor will have to cleanup for each release. I'm loathe
> to define a system that creates busy-work for someone unless they
> definitely want that work.
>
> IOW, in abence of a janitor volunteering, I'd just keep life simple
> and let bugs be marked closed as they get merged via the commit message.
>
> We can query bugs linked to commits in this way, and I feel we'll have
> more luck getting maintainers to reliably add bug links in commits
> than playing with milestones.

Yeah, I don't expect us to do all of our release planning in Gitlab. 
This is merely a convenient way to associate an issue with a release.

I'm personally willing to do SOME of the janitoring here; in that I can 
associate closed issues with a release milestone and -- when preparing 
for rc0 freeze -- punt off any bugs that aren't blockers/in-progress to 
the next milestone.

I don't expect it would become an *exhaustive* list of changes, just 
merely a way to associate the things that DID make it into the issue 
tracker with a release.

It may allow us to publish a nice list in the changelog with links to 
the gitlab issue tracker each release, which might be nice because issue 
tracker bugs are often ones that end-users filed, so it's a way to pay 
very visible attention to that feedback.

> > - Let's add "Workflow::Confirmed" to help distinguish lightly-triaged
> >    bugs from serious, actionable bugs.
>
> I wonder if instead of that we could just have some prioritization
> tags eg
>
>    - "Regression" - something that previously worked and we broke
>
>    - "Release blocker" - we decided we must have this fixed in the
>      next relaase - currently we paste such bugs into the planning
>      page wiki for a release
>
>    - "Important" - something that's high priority to address
>
>
> This confer more useful meaning that a "Confirmed" tag I think.

Definitely nothing stopping us from adding those labels outside of the 
Workflow scope.

"Regression" might be nice for highlighting issues for inclusion into 
the next stable release.

"Release blocker" could be just as well served by inclusion in the 
upcoming Milestone. (Granted: there would be no difference between stuff 
that's puntable or not-puntable, so there may indeed be some use to a 
"Blocker" label.)

"Important" might be best served by the "weight" fields, and might be a 
bit too subjective.

> Anything else without those tags can be considered a "normal" bug
> that may or may not be dealt.
>
>
> So I wonder if it just suffices to have standalone "workflow:triaged" and
> "workflow:needinfo" flags, possibly as prefixed labels, not scoped labels.

I think I am rather fond of having the scoped labels for the sake of 
making the "Board" view interesting to look at.

Open --> Triaged --> Confirmed --> In Progress --> Closed

In this view, each column suggests work that can be done to help move it 
along the pipeline. Tagging open bugs will be an important step in 
making this issue tracker useful to everyone.

We *could* move everything to individual labels, but I find a benefit to 
scoped labels is that you can't mis-use them by applying more than one, 
so there's less janitoring to do.

I also like that scoped labels suggest the full lifecycle of the issue, 
so you don't have to dig through the full list of labels.

(Also: if you don't know about ANY of the Workflow labels, the board 
view provides a canonical overview, so it's a fairly discoverable process.)

> Regards,
> Daniel

Thanks for the feedback today, on IRC and now on-list. :~)

--js