Multiple labels per board list

Description

• Multiple labels per board list.
• As shown in the mockups, each list would support multiple labels.
• When adding a list, the UI changes. In the existing implementation, you check and uncheck labels in the dropdown to add lists.
• In the new UI, you click the Add list button. Then you select multiple labels. And then you complete the action by clicking the Add button in the dropdown.
• Note the updated text copy for EES and CE.
• For EES, you can select multiple labels. So the selection is like a checkbox-like selection (can select multiple at a time.)
• For CE, you can only select one label. So the selection is like a radio-like selection (only one at a time).
• This should be implemented for both project boards and group boards.

EES

CE

Original description

Use case and problem

• Team wants to plan for an iteration with GitLab issues. (Assume they use GitLab milestones).
• Team wants to track progress of issues in that issue, in an Agile/Scrum-style methodology. Move an issue through different stages, such as "In Dev", to "In QA", to "In Prod", etc.
• Team can use an issue board with lists that reflect those stages.
• Team can use an issue board and use the saved milestone feature to always see one common issue board that is scoped to that milestone.
• But there are many other issues that are not relevant to that's team's work. For example, if the team only cares about Discussion issues with that label, they don't care about Platform issues. Right now, there's no way to use a board to keep track of that.

How to solve?

• If we use the save filter design (https://gitlab.com/gitlab-org/gitlab-ee/issues/1154), we can filter on Discussion issues, and associate that filter with the board itself. So whoever loads the board, will see the right milestone and issues filtered accordingly.

  • The downside of this is that it mixes metaphors of "filtering". Filtering should mean temporary, and personal. So this design could be confusing. Already, it is confusing to users that we can associate a milestone with a board, but that persistent milestone stays in the filter bar.

• Introduce boolean operations on lists. A first iteration is allowing lists to have multiple labels. So an issue only appears in a list if it contains all the labels that defines that list. In particular, to solve the problem above, the first list would be "In Dev + Discussion", second list would be "In QA + Discussion", etc.

  • The negative of this design is that it can get complicated very quickly, UI-wise. There is a lot to configure. It is do-able, but the UI would have to be really good and hide complexity.
  • Another consideration is how you would re-define issues moving between lists? Right now, if you move an issue from one list to another, then that issue loses the previous label and gains the new label. What would happen in this case? Would it lose all the labels and gain all the new labels? This is not really a negative. But something to be considered and designed for explicitly.

mentioned in issue #1154 (closed)

changed milestone to %Next 2-3 months

cc @dimitrieh @tauriedavis

added EE Starter label

added UX label

@smcgivern @sarrahvesselov @jschatz1 : There might be better alternatives to saving filters for the issue board. See ideas here.

Yay, thanks for capturing my comments from https://gitlab.com/gitlab-org/gitlab-ee/issues/1154 in the second option listed in this issue!

I am all for adding boolean operations to lists rather than saving filters. It makes more sense from an experience perspective, since you aren't saving something that is suppose to be temporary/personal. The UX could take some work to make simple/intuitive, but I don't see that as a negative. I imagine moving issues from board to board would have the same behavior as it does today [loses previous label(s) and gains new label(s)].

Thanks @tauriedavis .

@cperessini : Let's consider this for 9.6 at the earliest. Many teams at GitLab I think would welcome this feature and certainly can help us with dogfooding.

I'll let UX work on this whenever according to our labels/milestones. And I'll ping here again if/when it becomes higher priority.

Filtering should mean temporary, and personal

I'm not sure I understand why this is implied, necessarily.

In particular, to solve the problem above, the first list would be "In Dev + Discussion", second list would be "In QA + Discussion", etc.

This seems like you have to add the Discussion label to every list, whereas saving a filter would just let you add it once. When would you want to have disjoint sets of labels as the list labels?

The reason I am advocating for not saving filters as a way of creating a board is because it then splits the use of filters into two functions:

1. Setting entire scope
2. Narrowing down content within scope

If you are using filters to set the entire scope, it becomes a strange interaction when you begin narrowing down the scope also using filters. To me, these actions are separate and combining them is confusing.

I also think that keeping them separate would allow us to persist filters for individual users. I often want to filter boards by the ~ux label. This doesn't mean that every board should be scoped to UX. By adding boolean operations, we can set the scope for boards and allow users to keep the filters that are most useful to them.

@tauriedavis thanks, those are fair points. I use Fieldbook for some things and the way that works is that you can save filters, and add temporary filters, but they are all in one place, and if you click Save, whatever temporary filters you've added are saved along with it.

However, I appreciate that I'm not the only person who will use a feature! I think we could consider starting with multiple labels per list and see how that goes

Multiple labels per board is something that users have been requesting, so we can start with that implementation and solve this problem and fulfill their requests in one move.

The proposal in this issue seems to refer to lists defined by joining labels with an 'AND' operator (UX AND Discussion). Would we want to allow other operators like 'OR' or 'NOT' in the future? Knowing if that will be added in the future or not will be informative for the design of the first iteration.

---

About the persistent filters, I can see the complexity @tauriedavis is referring to. We could have up to three different types of filtering on boards:

• Dynamic filters that you apply on the fly
• Personal 'favorite' or saved filters that you can quickly apply to any board
• Static filters that are part of the configuration of the board

I think each type of filtering brings its own value, though, and we should at least try and see if we can make them work all together.

There should be a simple way to separate persistent filters from the rest, for example by changing their background color, adding a pin icon, moving them to a separate section or grouping them under a 'Persistent filters' token.

This proposal still mixes temporary and persistent filters, but there may be a way to convey their differences clearly and make this work.

changed milestone to %10.0

mentioned in issue #3043

marked this issue as related to #3043

changed the description

changed title from Use issue board as a team workflow tool to Multiple labels per board list