Issue board as a workflow tool
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 (closed) 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.