Issues in priority order
- 8.17 #26205 (closed) Add existing issues to issue board
- 8.17 #27872 (closed) Update docs with new way to add issues (and remove them) to issue boards
- 9.0 #21264 (closed) Reorder issue in issue board list
- 9.0 #24215 (closed) closed issue disappears from board
- 9.0 gitlab-ee#1587 (closed) Create and edit issue board with milestone
- #27531 Dragging and selecting issues versus navigating in issue boards
- #27095 (closed) New issue search and filter UI in issue boards
- gitlab-ee#928 Group level issue boards
- 9.0 gitlab-ee#1156 (closed) Reposition multiple issue board title/selector dropdown
- #27104 Use multiple labels per list
#27093 (closed) Style and format issue board cards
My team works on a subset of issues in a GitLab project. As a team member, I want to see those issues only when I'm in that team context.
Solve the Done column being an asymmetric column compared to the rest of the columns.
Solve the confusion of labels being overloaded as board stages.
My team works on issues that spans multiple GitLab projects. As a team member, I want to see those issues only when I'm in that team context.
This is a continuation of the #24686 (closed). We are now focused on issue board workflows (more below). This issue outlines the problems, identifies our areas of focus, and tracks the progress of this design.
Ways of using boards
- As a workflow tool
- Kanban and Scrum use lists like “To Do”, “Doing” and “Done”
- Lists need to represent stages
- Labels on issues represent categories like “UX” or “Frontend”
- As an organizational tool
- We want users to use GitLab as more than a code repository
- Projects that only have an issue tracker might use lists like “Bug”, “Feature request” and “User feedback”
Our initial focus is having boards being used as a workflow tool and solving the problems inherent. We will assume our columns have 30ish issues each, and maybe up to 200 at the extreme.
Lists as stages
- We are directing this feature towards agile teams and they need stages
- Keep the boards the way they are and trust users
- Add new entity “Stage” and replace labels as the base for lists
- Overload Labels even more with the ability to represent a stage (“Exclusive Label”)
- a new entity ‘Stage’
- Open questions:
- Should ‘stage’ map to I2P / Cycle Analytics?
- Is this just an option, default or mandatory?
- Do things ever automatically move?
- Agile boards don’t typically have a ‘review’ stage? Should we add that?
- Start with what is right for agile boards. We should feel like part of the same flow as I2P - but that doesn’t necessarily mean identical. The conversation will come up if we need to add the other stages
- Relationship between stages and milestones?
- What the scope that stages are going to exist in?
- Can an issue exist in multiple boards?
- Overlap of teams, horizontal vs. vertical
- Answer => Yes
- If an issue exists in multiple boards, and it is moved across a stage in one board, what happens? Are the stages the same across the multiple boards? Or can an issue have multiple stages based on board? Or do we have ‘parent issues’ that group multiple ‘sub issues’. Each sub issue only exists in one board.
- Assumptions about Stages:
- There is a clearly defined order
- Stages can be renamed
- Show up on individual issues (part of the issue meta data)
- An issue should only be able to exist in one stage
Boards for sprints
- Only show what the team is interested in at the moment
- We have Milestones, but filtering by Milestone is not persistent
- Possible solution:
- Configure each board when creating it and assigning a permanent Milestone filter (not part of the filters bar)
- Extension: Add any kind of filter in configuration. For example, a true UX board that only shows issues tagged “UX”
- First: add milestone filter
- Is it a problem that the backlog is limited by milestone?
- Open question: how does the PM create the backlog? What is that flow/experience?
- Focus on manual first - can patch automatic, but make sure everything is possible with a baseline manual solution
- Backlog shouldn’t be a column, use ‘add from all issues’ dialog. Kanban columns aren’t for organizing/managing issues. Our issue list is.
- Second: other filters, more complex configuration
Manually add issues to board
- ‘Add issues to board’ (not backlog)
- Issues added are always added to first stage of the board.
- (Minor detail, select all would be awesome after a search or filter)
- Having a setup screen would reinforce the idea that board structure should not be changed often
- If there are multiple boards, there should be a way for GitLab to remember which one you’re most interested in
- Manual ordering is essential for prioritization (no way to order issues with the same Priority Label)
- Multi-selecting issues would be great for organization
- Change background color of card based on label
- Hard to read issue titles with so much information
- Explore what the set up flow looks like
- Always load the last board you were looking at
- Multi-selecting issues is lower priority
- Editing multiple issues by selecting them and using the side bar - nice, but lower priority
- Definitely should simplify cards visually
- What information can move to exclusively sidebar or hover (?)
- Background color - interesting thing to explore down the road, low priority for now, but should there be a way to select which label is used, or somehow use priority labels only, etc.
@JobV : @cperessini has done some very good work on thinking deeply about issue boards, reviewing some of the existing requests, and iterating on the designs. With @awhildy , we just synced up. I dumped all the great ideas and our discussions here. Next steps are that Chris will get us some more wireframes / mockups of the create-a-board flow, which we identified as a pretty crucial aspect in our use cases. We'll then have a really good idea of how we can ship something really soon, hopefully something for at least 8.16.
changed title from Issue board workflows to Issue board as a workflow toolToggle commit list
My comments from the now closed issue at #25730 (closed)
I would like to have a pre-configured board that shows a subset of all the issues. The important improvement here is that the filtering should be part of the board configuration, so that the board always applies this filtering, and so that users of that particular board does not accidentally change it
The most important filtering would be based on milestone and/or release:
- Milestone-filtering would allow me to create a "current release"-board
- Label-filtering would allow me to create a "these are the meta-issues we have"
As for implementation, that's for the experts, but some thoughts:
- In the board menu, add a new menu item "Edit board filters" under the existing "Edit board name". Pop up a new filter bar, with stronger visual cues, a headline that says "Board filter" and the button "Close". It would work as the regular filter bar, but save it's values permanently.
- In the regular filter popups, show the preconfigured filters as selected-but-not-removable. Or, alternatively, when there are shared filters: Add a line above the filters bar, saying "Preconfigured filters: ", and then listing the filtered values
I think the key thing with boards is not to have something too prescriptive. Something that may fit a particular group isn't likely to work with others and people's workflow can change significantly over time.
Many requirements can be captured by having generic labels that are either exclusive or non-exclusive. Exclusive labels could be collected into label groups to simplify usage.
A few examples to clarify. There are many ways of organising boards:
Workflow: "To do", "doing" , "done" - these are exclusive labels - an issue can only be in one state at a time. So a label group could be created for the different stages of "workflow" and a board used to fit this label group. This fits with the typically agile view of a board
Type: Classic issue types, "feature request", "bug", etc.... Again these are generally an exclusive type
Area: (Team/Department). "front-end", "back-end" "ops" These are often exclusive when broken down sufficiently.
However any issue may be assigned multiple non-exclusive tags which are across "label groups": eg "In progress", "Front-end", "bug"
Generally boards are typically used as an overview of an exclusive label group - where typically an item fits one list or another. The key thing is a user should have sufficient freedom to design their lists and boards as they see fit.
Board Logic The second part of boards to keep their use generic is for the user to be able to specify a small piece of logic that is triggered when an issue state is changed - ie transferred from one list in a board to another.
eg Move an issue to "Done" in a workflow board closes the issue Move an issue to a different area may automatically assign it to a particular assignee. etc....
This would remove the need for a workflow board to always have "Backlog" , "Done" etc.... which doesn't seem to fit with many users.
Board Templates You may want to help users get started quickly using boards in a particular way, rather than just provide them with generic boards by providing a few templates. eg Kanban board - with a workflow label group, and with a done list that closes issues, and perhaps a constraint on the number of items in certain lists.
Thanks @victorwu! That is actually something @cperessini brought up when we were chatting earlier this week. I agree for now, let's keep going with calling it 'Stage'. Let's get ourselves feeling great about the design/perspective for this work, and then adjust as needed later. We may even end up not liking the term stage for this as we work on it. But good point to call out!
@victorwu awesome issue. My 2 cents:
- I am afraid we get into complexity trap by introducing stages while still supporting labels. Lets try to achieve more with labels only. We use labels for pretty much everything: stage, category, priority and I feel great about it. Comparing to other tools where you have separate field for every possible attribute.
- Board should have settings where you can specify milestone and label. This way you can isolate board to be a sprint or team-specific.
Thanks @dzaporozhets for the feedback.
After the holidays, Chris should have more detailed designs, incorporating and addressing all the feedback thus far. Let's definitely continue the discussion then when we have some tangible designs to chat through.
Thanks @GCSBOSS for the ideas. We definitely want to design for an issue progressing through multiple stages/columns of an issue board. But it's not absolutely clear currently that we want to introduce some restrictive mechanism to achieve that. And in fact, @JobV has mentioned the negative consequences of that in #17186 (comment 11696577). And @dzaporozhets agrees with #25698 (comment 20542943).
We have already achieved this through the label mechanism and the existing issue boards. But there are advantages to further restricting this by introducing states / stages as first class citizens (a new entity) or using what you described in #25914. For example, currently in GitLab, a label represents multiple things in GitLab, which can lead to confusion under different use cases. E.g. suppose a user creates a new issue and applies a label to it as usual. They may have unknowingly just added an issue to an issue board without intending to, which may be a terrible thing in some circumstances.
Currently, a GitLab label represents:
- A "label" in the traditional sense.
- Can be a priority label, that implies prioritization of issues, which is really just a mechanism of displaying order currently.
- Can represent a stage in an issue board.
So one big advantage of introducing states / stages is to reduce the potential confusion of users, and to create crisp, targeted, and obvious features for users in the context of issue boards. The disadvantages are mentioned above.
I'm constantly flip-flopping on the which design is better. There's pros and cons to both. But in any case, we may want to strategically focus on different areas of issue boards in the mean time, as they are still many areas to clean up. So we can delay making this hard decision, and just focus on iterating on other areas that are more obvious to design.
Not a strongly opinionated response. But wanted to further outline the breadth of complexities here for everyone to read.
With #26205 (closed), we want to retire the backlog column. That's good.
The done column is a remaining problem. It displays issues that are in closed state, while the other columns show open issues based on their labels. So it's an asymmetric/special column from the rest of the board. This design may lead to some problems later. No clear solution yet.
@victorwu I don't have a deep understanding of the architecture of GitLab and don't largely make use of the Boards either, but I think some of the enlisted problems could be solved by permissions. In a way that people who don't know the purpose of some labels would not have the rights to apply those. I mean, we already have permissions for adding any label at all; would it be difficult to add permissions to prioritized labels and or stage labels?
Though the way described in #25698 (comment 20231690) is pretty much the way my team uses labels. It would be really great if Boards could assist on that.!
Only to sum up, I would like to say that the reason I could not use Boards a lot is because of the lists' design.
- Mainly by the lists huge width in a way that 14" screens get scrolled really soon.
- Also by the apparently fixed Backlog and Done lists.
Also if you guys find it useful (I don't) to see closed issues on the Board, hiding the Done as @victorwu already stated would do it. If like me you find useful only the ability to close issues from the board, what about only showing a rectangle or something labeled "Close" when the user grabs a given issue? Thus if desired the user should only drag the issue there and it would be closed and removed from the former board.
Never mind my colors.
Any plans to add issues board to MR?
I agree with @Barclay that a small amount of logic would be useful. With just this change, I believe I could manage both development and external workflows using boards and matching branches. The default logic would be:
- when code is merged to master, close all referenced issues
I would use something like:
- when code is merged to UAT, remove the 'fixed' label and add a 'to be tested' label
- when code is merged to production, remove the 'accepted' label and close all referenced issues
to be fixed -> fixed -> [merge to staging -> to be tested] -> accepted -> [merge to production -> closed]
Where "to be fixed" and "fixed" are dev board labels and "to be tested" and "verified" are UAT board labels.