GitLab tools: labels, kanban board, milestones

It would be nice to clarify and improve our use of GitLab. Considerations:

  • Label consistency across repos
  • Use of the new “priority” labels (and can make our own that are “prioritized”)
  • Use of milestones for planning
  • Use of the kanban boards

I’m not sure the best ways to start. Presumably there’s some documentation on these features from GitLab. I do want us to work on things iteratively as needed and not try to think it all through perfectly at once.

I’d like to hear from others about their thoughts on these tools, ideally from anyone who has experience using GitLab specifically (although similar tools are relevant) for other projects.

Relevant issue:

meta notes

wolftune edited this issue to adjust the markup

Also, in Discourse, I can “share a link to this post”, but I can’t make a “reaction” that’s just a link, as opposed to a full-blown reply.

We’re making progress here. Today @smichel17 and I groomed tasks around announcing this very forum. Although labels are useful, the milestone function was most significant.

The EE version of GitLab has further organizing tools; but with the core stuff, Milestones seem best when treated as more immediate short-term goals. We should think of our journey as thousands of miles long with some sections of the path more difficult than others. So, milestones aren’t major marks along the whole journey, it’s each little mile.

Here’s what I’m working on over the next week in order to then promote this forum and build from there: https://git.snowdrift.coop/groups/sd/-/milestones/discourse-announce?title=Discourse+Announce

I think it’s fine to have both larger and smaller milestones, and agree that smaller is nicer.

1 Like

So, I am now thinking of milestones as what GTD calls “projects”, i.e. any large thing that requires multiple issues to track the work, but where in the end it does get completed and checked off. Contrast with labels which live forever.

We ought to use Milestones more and to not make massive unrelated sets of tasks in a Milestone. Instead, we should just use them for any multi-issue project that all goes together and gets checked off. Indeed, that could vary quite a lot in size.

Point is: milestones aren’t just some notable spot in a journey (as the metaphor implies) but are really just multi-issue projects to check off.

And we should capture this idea in the grooming guide in progress https://git.snowdrift.coop/sd/governance/issues/38 by @alignwaivers

1 Like

Isn’t that the use case for Epics? Granted, I’m not sure if they are available on the gitlab free tier.

In the past I have found it useful to use milestones as a notable point, namely a release/deploy. That doesn’t mean they have to be large or few (small, frequent releases are usually better anyway). I’m not sure how well that holds up in a website model though, compared to an app where there are more discrete releases.

1 Like

Yes indeed, and I was going toward saying that we ought to use Milestones as Epics really. I think Epics are probably more important than Milestones for organizing work.

Okay, I finally figured out what is going on. GitLab.com offers all public projects the Gold tier of their proprietary features. We can get all features including Epics by applying as an OS project. Much as I hate this whole proprietary restricted aspect of this, and it goes against our own values and goals for Snowdrift.coop, I’m open to doing that application so can simply use the tools. :unamused:

We actually seem to have all the Silver features for any public project already. Epics are the only valuable tool we don’t have access to. If we just used Milestones more as Epics, that might just work enough.

1 Like

What happens if you simply create issues called “Epic: Blablabla” and put a list of issue references in the description? That way you automatically have a place to discuss the epic. I think issues display “related issues” or sth like that directly below the description?

3 Likes

I’m going to parachute into this discussion in order to describe the first, and only, system I have found that has survived more than a day of actual use. (It’s going on two months now, and has gotten rave reviews at my work place.) It’s not my idea, and I’ll link to my source at the end, but here’s the formula.

  1. List epics (user stories) in a spreadsheet.
  2. Give the user stories a priority order (in the spreadsheet).
  3. Create a priority-label in GitLab corresponding to each user story, in the proper order.
  4. For each task/issue/bug, assign it to as many user story labels as it affects.

Boom, you have a list of tasks in priority order, helping you focus on getting one user story done at a time. You can even re-order stories in the backlog without dropping tasks, since you can assign a task to multiple stories.

GitLab is not 100% suited to this usage, but it’s pretty foolproof. Some things I find myself wishing I had:

  • Automatically assigning issues to a milestone based on labels
  • Well, really that’s about it.

The talk has a bunch of other amazing info (like “What is a user story?”, and the importance of estimating the size of tasks (don’t bother: it’s mathematically irrelevant)), and I recommend watching the whole thing.

https://www.usenix.org/conference/srecon18europe/presentation/pennarun

5 Likes

We’ve come this far, unless the discussion happens and the values/goals shift, then let’s continue to stay the course, it is one of the things that is frequently praised by those who have been following the project for some time.

3 Likes

7 posts were split to a new topic: Optimizing issue Labels in GitLab

Reminds me a bit of how I use Task Coach personally

(side-note: lacking Snowdrift.coop support, that project has been stagnant and now slowly falling behind in keeping up with library versions etc :frowning: ). Task Coach allows any integer range of priorities (yes negative numbers too) separately from labels. It also has the ability to reorder tasks manually and switch between sortings. Anyway, point is: flexibility on priority ordering without having to separately change labels is indeed very useful. Using a fixed set of 4 priority labels offers much less flexibility. It lacks the key idea of list-sorting since all “high priority” items will just be bundled in arbitrary order together.

My draft reinterpretating/applying of your suggestion:

  1. identify epics (however works best, separate tooling)
  2. make labels for each epic
  3. apply labels to issues to identify which epics they relate to (could be multiple!)
  4. mark the labels as “priority” in GitLab’s project-level Label setting (priority sorting isn’t available at a group level unfortunately)
  5. as helpful, go to the project label list to (re-)sort the epics

This seems a fine proposal, and even without the prioritizing, simply using labels to mark epics is doable. I’m okay with basically adopting this approach. Do I understand it correctly?

How does this workaround for epics relate to a whole epic getting checked off? I’m concerned about growth of deprecated labels of finished epics (although I suppose there are ways to do some clean up / garbage collection)

2 Likes

Yep, that’s the gist of it.

I don’t have experience “checking off” too many epics yet, but here are my current thoughts:

  1. Story-labels all get the same color and the same S: prefix. That way they stand out and sort together. (The prefix is an ad hoc label hierarchy.)
  2. Finished stories have the word “FINISHED” prepended to their description, and get removed from the set of prioritized labels.
  3. Only stories that are part of the current milestone should be prioritized.
  4. Active stories can be tracked in kanban boards (e.g. one column per story of the current milestone). This further helps them stand out, in an actionable way, from the sets of past and future stories.
3 Likes

Obviously, scoped labels is the ideal approach to the this, but it’s an EE-only feature. Anyway, we have it currently if we want to use it.

Other Board views?

Do you otherwise ever use the “to-do” (or do-next) and “doing” tags in the Kanban (a la GitLab’s default Board)?

Sorting options

On sorting, I otherwise just realized GitLab has some (odd) sorting options:

  • “Label Priority” vs “Priority” explained here: https://gitlab.com/help/user/project/labels.md#label-priority
  • Manual sort (drag individual issues up and down) available in the issue-list view
    • the Board views have this too now, but there’s no sort selection dropdown, it’s just manual by default

Anyway, filtering to “is not” != functions, but not with wildcard syntax unfortunately.

1 Like

Yeah, unfortunately. I don’t know if it’s a bug. For example, trying to search for “label != design*” sometimes it returns a 500 error and other times it just returns the full issues list. The search syntax page doesn’t mention wildcards are inapplicable to labels or the “not” operator.

Not sure if you’re already aware, it seems smichel17’s tip about scoping a group level board by project_id no longer works without an additional filter (e.g. by label) (edit: nope, it no longer works). For that you still have to go to the project level board. Example: this link (originally showed code repo issues), compared to this one (used to show only code repo issues by “ui/ux” label).

With the way GitLab’s features work, there’s probably a better signal-to-noise ratio for teams to do their own initial setup at the project level board. That is, if they decide to use it, with the group level ones as a starting point (since they’re not templates that can be inherited like group level labels) and autonomy to supplement their own labels.

Edit: sorry, this was supposed to be in nested reply to @wolftune’s post, it got accidentally posted up a level.

3 Likes