Issue Boards

I love it @JobV! When do we start?

Added ~19492 label

Milestone changed to %8.10

8.10 for UX / UI work

Changed title: GitLab Boards → Issue Boards

@JobV consider renaming to scrum board

The word "scrum" has so many connotations and expectations that it could be dangerous. People will want sprint tracking, burn-down charts, etc.

@markpundsack we're likely to add burn-down charts at some point. What is spring tracking?

@markpundsack I feel like as long as it is a scrum board we are ok. But maybe it's better if it's a kanban board.

@JobV Awesome proposal! I love it not only because it's a great feature, but the clean and elegant re-use of existing features is brilliant!

For the future "multiple boards per project", I envision that as being able to save filtered views. e.g. Filter by the "CI" label and save that (or just bookmark it) as the CI board.

One thing I don't see is the ability to re-prioritize items by dragging-and-dropping within a list, which is one of the key strengths of Trello. The MVP can be fine without it, but I'm curious if you have any ideas how to handle that in the future? We already have weights, which could be re-used for that purpose. It gets even more complicated when you consider re-prioritizing a filtered view, without negatively impacting a differently-filtered view.

I love the idea!

When you are saying Order issues by priority - what is priority? Is it new field of the issue? Because it doesn't exists yet. Right?

P.S. majority of the functionality already implemented in this open-source project: https://gitlab.com/leanlabsio/kanban. Not sure, if that can be of any use to you...

@jschatz1 Good point. Maybe I'm against the name because I don't actually like to practice scrum completely. :) But I still want this board.

One of the huge values of Trello is that it can be used for any kind of process. But one of the downsides of Trello is that it doesn't go deep enough for any specific process. :) Because we already have a backlog and a definition of "done" (closed), we already have some opinions involved.

@sytses my understanding of sprint tracking is that it's a process for tracking weekly sprints used by some "agile" methodologies, see Google Ventures' Design Sprint page for more information.

@markpundsack I agree. I am not a big fan of the strict methodology myself.

You are right in opening this up to any type of person, whether they like it or not.

I think the only point I'd make is that I believe that the die hard scrum people (which is huge, or is it dying, I don't know it's been a while) would only use this as a scrum tool if it was labeled as such. Or maybe we relay the message that this is a scrum tool somehow but we just don't call it that directly.

Anyway I've done our sprint tracking on a kanban board before, so maybe it's not that hard to make sure this one can do that. Or are we too late to the game?

I think we should make it as generic as possible so we don't have to constantly update it to fit Kanban, Sprints, Scrum, and whatever the Methodology of the Month is.

Very solid job @JobV. This will definitely be a great product.

mentioned in issue #17942 (moved)

How many columns can be shown without horizontal scrollbar?
If it would be just a few, how can it be usable, it you're talking about a column per label way?

@blackst0ne I think you only add as many lists as you want (the button in the top right of the first image opens the modal in the last image), let's say you want to contribute to the frontend, you may add lists for UX, Frontend and feature proposal totalling 5 lists. Either way, you raise a valid point, how will the interface comfortably support a large number of lists? I'm sure there is contributors that need to track a crazy number of labels and it would be great if this feature could support them too.

@LukeeeeBennett, 5 lists are just fine, I agree. But, I think, if there are more than 5 lists, it will bring a huge problem to interface usability.

@sytses I'm against using the word scrum for anything in GitLab. It doesn't represent what it is, nor do we want to offer a vertical solution for what scrum represents. We just want to build cool things that help people ship. Board is the most simple, atomic name we could use.

@blackst0ne @LukeeeeBennett we'll just use horizontal scrolling. See Trello for an excellent example.

Is it uncomfortable with a lot of lists? Yes. You can prevent that by not having a lot of lists. I think 10 is a reasonable limit, as it prevents you from having a crazy amount, but doesn't stop you from making complex workflows.

@SlavikCA @markpundsack for now, we'll use priorities by leveraging priority labels (due 8.9).

I agree that reordering to change priority might be convenient, but it'll be hard to combine that effectively with priority labels. I have some ideas on how to fix this, but I think it's best saved for a second iteration, after we have tried this for a while. One way would be to just have that separately, i.e. store the position in the list separately.

And thanks for the feedback! :D

I think too much information gets thrown into labels, - now it will includes priority... That can make things over complicated and UI cumbersome.

I'm voting for priority to be separate field, so issue just can be dragged up or down, like in Trello, JIRA, Huboard and most other boards. I think weight should not be used for priorities, as it will make board EE-only feature.

@JobV Small detail, but I think swimlanes often refers to horizontal rows. To avoid confusion, you might not want to use that word for vertical columns.

This looks very cool!

Perhaps you can add a checkbox "Only allow one swimlane-label per issue"? This way users can simulate a scrum flow without actually naming it scrum.

Looks promising. being able to create a kanban-like board, with different swimlanes, such as Todo, Doing, Done can be helpful in teams to organize work.

@markpundsack I don't want to use that word anyway. Double win!

mentioned in issue #18003 (moved)

mentioned in issue #17186 (closed)

Reassigned to @fatihacet

Reassigned to @jschatz1

mentioned in issue #18166 (closed)

This will be great :-)

Swimlanes is not a good word for the columns, though. See for example this: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/configuring-a-board/configuring-swimlanes.

mentioned in issue #18229 (closed)

mentioned in issue #18492 (moved)

mentioned in issue #18323 (moved)

mentioned in issue #18576 (closed)

@elygre we'll call them lists, thanks.

@hazelyang can work on UI for this issue

Added ~307491 label

This would be great. We are currently using AgileZen, but we would switch to this solution, if it worked reasonably well.

We don't even need some of the proposed functionality (swimlanes, milestones, weight, etc.) - what is important is:

seeing all the open issues
can drag&drop them through 3+ columns
have an easy access to the already implemented functionality from there (comments, attachments, assigned person)
can set a color for each issue

Please let me know if you have any feedback.

Issue boards (Default)

Issue boards with 3 columns

Issue boards with 3+ columns

Create a new list

@hazelyang I love it.

Graphically, it's great.

As of functionality, I am very worried that you made an assumption that column = label (it seems like that based on some parts of the graphics proposal). That's not how it works for us (or other companies, I believe). For example in AgileZen we are using five columns:

Backlog
Specification
(In) Development
Testing
Done

And a card (issue) can be a bug for example, but it will be in any of these columns, depending on its lifecycle. In other words, there should be no "Bug" column.

@hazelyang This looks awesome. My excitement level for this feature just doubled!

Maybe we could hide the bottom horizontal scrollbar as the cropped edge of the next list card prompts the user to scroll horizontally to the next list. Then functionally, if we take full control of that horizontal scroll for the lists, we can have a really smooth issue-dragging UX. A bit like how you can move an app from one screen to the next on an iOS devices home screen. You drag it to the side and rather than a native scroll gradually scrolling over, you get a programmatically defined scroll that takes you perfectly to the next screen (in this case, list).

@illich I believe the original proposal is that 1 column = 1 label. Apart from the Backlog and Done lists which are required lists. You could then build your preferred workflow using labels. You would have to create a label for each step of your workflow and drag it to the next step of the workflow that is on the issues board. In your example, create a label for Specification, (In) Development and Testing. You can then make lists from these labels and continue using your prefered workflow. It's too cool.

@JobV Going back to issues that have multiple labels. When dragging an issue to done, it closes the issue. If the issue still has other labels that exist as lists, it should not close and instead only remove the label of the list it came from and only closing the issue when all the labels are removed. But then this could add some annoyance as some unimportant labels that will never be used as a list will hold issues from being closed on an issued. Maybe when dragging to done the user can specify whether to close or just remove the label?abel?

@hazelyang That's awesome! I'm so excited for this feature!

One thing, can we drop label tags for labels used in the columns themselves? e.g. drop qa, bug, etc. since those are used as columns. It's redundant. I like that you re-used the label color to give the column a splash of color. Nice touch.

@lukebabb When moving to done, why not remove all labels that are column-labels, but leave any other labels alone? And also mark done. In that case, I'm not sure I'd have a column named Bug at a all. It doesn't really work with this flow. I think the intention is more about having columns with transitory labels. e.g. Backlog -> Planning -> Specification -> Development -> QA -> Beta Testing -> Done.

@hazelyang When do you need the "scroll down to see more" prompt? Isn't the sidebar in the column enough?

I think issue boards are going to be more important than the label and milestone views. Should it be the second item in the sub-tabs? It shouldn't really be plural, should it? There's just one board (with multiple filters). The repetition of "Issues" then "Issue Board" might be weird.

Would "Issues, Board, Labels, Milestone"work?

Thanks for the feedback.

I did some changes in the mockup:

Hid the scrollbar in the bottom.
Changed "Issue Boards" to "Board" and let it be the second item in the sub-tab.
Dropped label tags for labels used in the columns themselve.

@lbennett I like the idea let people drag issue with programmatically defined scroll.

@markpundsack Right, the scrollbar in the column is enough to let the people know they can scroll down. Removed it in the mockup.

" I believe the original proposal is that 1 column = 1 label."

You guys should look at the competition first:

Trello
AgileZen
Jira
Taiga.io

All of them have labels and columns as different concepts. Label is a type of issue (e.g. Bug, Feature, Performance, Documentation). Column is a phase (from specification, through development to testing and deployment)

@hazelyang this looks amazing, love it. Great work.

@markpundsack thanks for the help. Much needed and appreciated.

@lbennett @markpundsack I think the behavior should be very predictable, so having a different behavior when moving to Done vs. the other lists would be confusing, although you make some good points.

@illich the example has 'bug', which is not a very good use case for this, but the using of labels for this makes sense.

You can easily create similar workflows as in the software that you've listed there. The advantage of having labels means that you'll have the metadata (in which lists does issue X appear) available throughout GitLab. Not only that, this also allows you to use all the sorting and filtering tools that we already have.

The downsides are that 1. it's different and therefore potentially confusing at first; 2. you can create 'bad' workflows quite easily. I think the flexibility outweighs these downsides, but I'm happy to listen to counter arguments. I also urge you to read the issue description well.

Agreed: Labels should be orthogonal to phase (the column). If internally it's using labels would it not also cause issues if people assign multiple levels to a ticket?

Boards should stay as unopinionated as possible: display the issues with the label and change label if you drag from one column to another etc. Other than basic stuff, leave anything workflow related to the user. If the user wants to assign the same issue to three columns, just let them.

This will make it easier to have multiple boards in the future where you can have a board for:

your agile-like dev flow for your dev team (backlog, planned, in-dev, needs-review, merged, done)
inter-departmental management where an issue might be in four columns (needs-design, needs-dev, needs-content, needs-client-feedback)
one that sorts issues by type (bugs, features, experiments, etc)

Being able to display the same issues in multiple ways to track needs differently for different user-types through different work flows would be hugely valuable.

For my company, it's a problem we have managing different departments where account managers have one workflow, dev's have theirs, and designer's theirs, so no one tool works for all three right now. Tools are either too code-orientated, or not code-orientated enough, so we end up using different tools for different departments and work gets duplicated.

Multiple boards that we can use to manage workflows our way would make gitlab EE valuable for our entire company not just devs. Our number of licenses would easily double or triple very quickly.

I understand that multiple boards is a future thing, but laying the groundwork now is important.

Thanks for the feedback @AaronHarun. Just to confirm, the current proposal would match your requirements (minus maybe backlog/done)?

A lot of my requirements would fall under the title of feature requests. But, I would suggest thinking of Boards as a tool to organize and manage issues first. And this organization tool can also be used to manage workflow. It will keep the initial feature far more flexible.

And, since feature requests are fun:

Configurable per board 1 issue = 1 column vs free-for-all (I would expect even on free-for-all dragging an issue from one column to another would remove the source label and add the destination label)
ability to X an issue to remove it from that specific column/label
a column of all issues and/or all issues not already in another column (this would function kind of like a backlog for boards with issues in multiple column)
columns with X, Y, or Z label or the inverse columns without A, B, or C labels

@cperessini when it comes time will you handle any UX changes that need to be done here?

@jschatz1 I'll be happy to participate in this cool feature

We're moving this feature to 8.11, after resolving MR in the UI. Maybe we can utilize the same team.

Milestone changed to %8.11

@JobV What are the issue numbers for "resolving MR in the UI" that are blocking this issue?

My team was extremely excited to see Issue Boards coming to GitLab in 8.10 and are ramping up to participate in the development of this feature and add on features - multiple boards per project, group level boards & personal boards.

We recently migrated all our internal projects from GitHub and our tasks from JIRA to GitLab leveraging GitLab's Issue functionality. Since the move we've lost our visibility of issues that we had with https://waffle.io/ & JIRA Kanban boards. Its a bummer Waffle.io doesn't support GitLab as they've done a great job implementing issue boards with great flexibility. We started playing with Leanlabsio/kanban (http://kanban.leanlabs.io/) but its lacking the multiple boards per project & group level boards that my team has come to rely upon. We talked about contributing to the Leanlabs Kanban project but agreed that we'd rather see the functionality added directly into GitLab.

As we started to write some sample code that leveraged the GitLab API for group level boards, we noticed that the API was missing the API call for group level issues and recently contributed Add an API call for all group issues: /api/v3/groups/XXX/issues #17818 (closed) & !4520 (merged).

Pushing Issue Boards to 8.11 (Aug 22) pushes adding in the add on features out even farther. My team would need to write something in the interim to keep us on track with all of our projects. I'd rather see that development effort put towards the final solution instead of an interim throwaway.

We'd be open to contributing to the "resolving MR in the UI" that are blocking Issue Boards and also to contributing to Issue Boards. If the tasks can be broken down into separate items, we could start working on them where possible.

I love this feature but I really dont like the "When moving to Done, remove the label of the list it came from and close the issue.", would just closing the issue be enough?

The reason i'm saying this is because we sometimes need to go back to past closed issues and it is useful to be able to see what labels they had. For example finding out how many "bug" issues were fixed in this milestone or how many new features were added, etc.

The solution I propose is the following:

When moving an issue to closed

If it is in 1 column: Just cose the issue.
If it is in 2+ columns: Show a message with options (Close issue, remove label, cancel).

In most cases an issue will not be on multiple columns so the message will not be common, but the main advantage is that the behaviour will be predictable and easy to understand.

@JobV instead of calling them lists I think we should call them lanes since that is more specific.

I like the idea very much! Let's replace GitLan KanBan from leanlabs, with a better one build-in .

@hazelyang Could we also group by 'user' or/and 'prio's' instead of only the current swim-lanes I see now (is it based on milestones now..)?? Moreover, the new GitLab CE 8.9 supports priorities on issues, why not use that instead of 'weight' (which is only in EE).

How many columns can be shown without horizontal scrollbar? If it would be just a few, how can it be usable, it you're talking about a column per label way

You guys should look at the competition first [...] All of them have labels and columns as different concepts. Label is a type of issue (e.g. Bug, Feature, Performance, Documentation). Column is a phase (from specification, through development to testing and deployment)

@blackst0ne @illich You are confusing "a column per label " with "a label per column". Don't add columns for labels you don't want. The default board only has two lists ("backlog" and "done"). You add lists for those labels that signify a column (or workflow stage / phase), and leave the others as pure labels like before.

I love this feature but I really dont like the "When moving to Done, remove the label of the list it came from and close the issue.", would just closing the issue be enough? The reason i'm saying this is because we sometimes need to go back to past closed issues and it is useful to be able to see what labels they had. For example finding out how many "bug" issues were fixed in this milestone or how many new features were added, etc.

@gabriellanata Why would you have a column for "bug" or "features"? It only removes the label for the column you moved it from. Move it from a state/stage/phase column, not a type column. And the log inside the issue will tell you which labels it had earlier.

instead of calling them lists I think we should call them lanes since that is more specific

@sytses The convention in other products indicates that lanes are horisontal, not vertical. Mixing this up will confuse people.

Right now, a single project will have a single board

Unfortunately, my team (and I can't believe we're that special) work across multiple repositories and can't use this until it is available on group level. :(

my team (and I can't believe we're that special) work across multiple repositories

Same. We work across multiple repos and multiple groups. (Example, our open source libs used across multiple projects are in a separate group than the repos for an individual project.)

my team (and I can't believe we're that special) work across multiple repositories

We also work across multiple repos and multiple groups (client, server, libs, etc) which require cross group coordination.

While we're on the topic of terminology, the newly launced "Planner" app in office 365 (https://blogs.office.com/2015/09/22/introducing-office-365-planner/) uses the term "Bucket".

Then so rename this issue/ the link name in GitLab from issue board to Kanban board...

mentioned in issue #17403 (closed)

Then so rename this issue/ the link name in GitLab from issue board to Kanban board

@webmaster1989 Why? This board is in no way specific to the Kanban methodology.

Naming, my 5 cents:

Columns: Just call them "Columns". It's clear, simple and unambiguous.

Board: I'd call it Kanban. According to Wikipedia, it's "literally signboard or billboard in Japanese". But I'm ok with "Board", as well.

And for functionality:

we don't need one board for multiple repos
columns are not labels. I can understand the technical reasoning for implementing it that way, but from UX (and workflow) perspective it makes no sense to me.

@fuzzy the suggestion by @illich and @webmaster us technically correct. While a similar looking board can be used for scrum (basically scrum took the kanban board as a tool and re-moulded it) it is usually used somewhat differently. With the functionality described to date, this implementation is a kanban.

However, with a view to the fact that scrum practitioners could still easily enough use this implementation and that scrum functionality might make up future features I agree with @illich again, that "board" is probably the correct term to go with here.

we don't need one board for multiple repos

We do.

It's possible to add support for Epics? When it's planned to arrive? 8.10? Do we have some expected date?

cc: @hazelyang @jschatz1 @JobV @sytses

Any progress here?
I'd like to see an example of worflow based on this feature.

@thalesfsp Epics may be supported if it were a Scrum board for example, but I think the plan it to have a Kanban board is are in general more popular because they're simpler.

Will this also change the milestone view? if so issue https://gitlab.com/gitlab-org/gitlab-ce/issues/19114 is related ;) I see filtering is already incorporated into the mockups :) very excited to see this :)

edit: actually shouldn't the difference between board and milestone be that in board, you can define lists yourself, while in milestone the lists are automatically updated due to the lists being connected to labels such as: "open/unassigned", "open\assigned", closed

Thus making both these views made up of the same elements, but having the milestone view, be more of an automatic one

additionally being able to customise the milestone view with additional automatic label lists may be of value

responsive design idea @hazelyang in order to let the user know there are more columns than one can see, the column widths could have their widths dynamically change, so it always shows a part of the next column not currently fully visible.

@dhekimian we're working on merge conflict resolution here https://gitlab.com/gitlab-org/gitlab-ce/issues/3567 Feel free to contribute, but it's a complex issue so make sure to communicate with the parties involved. You're also welcome to contribute to this and any other issue as well, of course. The reason for moving this one down, is for capacity reasons.

@gabriellanata hm, I actually find your proposal more confusing. Providing several options could be interesting, but I don't like that the behavior is different when moving between lists. Happy to discuss further.

@sytses I disagree. I think it makes sense to call things the simplest description of what they are, rather than adopting a more specific term from other products. Also note @fuzzy76 comment that in some products these are horizontal.

@gsmethells @AaronHarun a future iteration to support multiple boards and cross-project boards makes total sense.

And to everyone: I'm pretty happy with the current naming. I think it's clear when you see this, Board refers to the entire things and a list refers to ..the lists. That is the goal of naming things: to make it clear what we're talking about. Our goal with this is not to support a particular vertical or methodology, rather it's to make a flexible tool that can be used for various workflows and tasks. As with anything in GitLab, we prefer convention over configuration, but lean towards light-weight, flexible implementations.

Assignee removed

@cperessini feel free to propose the UX early so we can hit the ground running in 8.11. Maybe earlier if we have time.

@JobV is that the correct issue mentioned in your comment? #3567 (closed)

@dimitrieh the link was correct, the comment not. I corrected it. This issue will only be worked on for 8.11 (August 22nd released).

mentioned in issue #18437 (closed)

Following the line of #18575 (closed) I've added the bars icon to indicate that you can drag an issue.

The major concern I have has to do with dragging issues between columns. Imagine having to drag multiple issues from the second column to the tenth. You'd be scrolling back and forth the whole time. To solve that issue we can show a list of the labels in the board at the top when the user starts dragging.

This method also solves the problem of what happens when you drag an item from a column to another. Some people thought it made more sense for the original label to be removed, and others thought that since an issue can have multiple labels the new one should just be added to it. With the list of labels if you drag an issue to a new label, it gets added. If you drag it to a label it already had, it gets removed.

cc @dzaporozhets @jschatz1 @JobV

Noone will use 10 columns. We use three. On one project, we used four (which was probably unnecessary). People nowadays have usually monitors 1920+ pixels wide, so the columns should fit on one screen without horizontal scrolling.

@cperessini good point.. although lists are not the same as labels isn't it? :)

As for the assigning cards to new lists, I think it's smart to take a cue from a popular service that has a solution to this already (trello), plus why have the lists be displayed twice on screen?

The solution I think will work best here is only available on the IOS app of Trello. Basically as soon as you drag issues/cards out of the list, it zooms out. This really old video kind of shows it off.

These images kind of show what it looks like.

optimisations could be the disappearing of the issues within the lists, to make the zoomed out lists really small.

Made a quick dirty mockup based on yours @cperessini ;)

TL:DR zoom out feature when dragging issues across lists

@cperessini Did you try putting the draggable bar icon on the left of each issue item?

That new bar is a really interesting way of solving the problem of having a large number of boards to drag through but we can enable this only when the user has > 5 lists (or something) other wise its essentially duplication.

I'm not sure about having to drag to both remove a label and then to move it to done. See the example below.

If an issue has 2 list-worthy labels (~Frontend and api) and therefore appears in the lists ~Frontend and api, when dragging the issue from the ~Frontend list to the Done list, it should just remove the ~Frontend label and remove it from the ~Frontend list. It does not however move to Done yet as it still appears in the api list. If then after that the same issue from the api list is dragged to the Done list, it will remove the api label and remove it from the api list and then because this issue no longer appears in the any other lists, it can be moved permanently to the Done list.

@illich I think you're right, boards will probably be kept quite small but I think this should be flexible if the implementation is simple enough.

@dimitrieh Although lists aren't the same as labels, you generate a list from a label that the project currently uses, therefore any issue with the same label as the list title will appear in that list.

I think this zoom-out UX works wonderfully for a native application but there could be some simpler patterns to gravitate towards.

@lbennett good thinking.

mmh is it confirmed that lists are generated from labels? If so, how would you consider the "done" list being created.. or "up for review" for example? Will you create additional color labels... perhaps transparent?

In my understanding this was what differentiated a board from milestone... although it makes sense to be able to move issues between lists be adding/removing labels (as it automates things a bit).

As for the zoom out feature, I think it's pretty simple as css transforms are pretty cheap/well supported nowadays not?

@lbennett There's not a lot of space right now on the left side, so we would have to give cells a bigger padding than the 16px standard or shift the content on hover, which I'm not sure we should do.

We could enable this view when there are more columns than fit the screen.

The way I saw it, dragging it over to Done removes every label at once, so you don't have to remove each individual label before. It's kind of the same as having the option to close individual tabs in your browser vs. closing the window that contains all of them.

@dimitrieh Yeah, all lists are labels except for Backlog and Done. Backlog is every open issue that doesn't have a label, and Done is every closed issue.

Zooming out is also a good approach. I also thought about laying out the lists in a zoomed out grid, but that would require them to fly around, which would probably be expensive and confusing.

@cperessini Yeah I understand how it was a challenge positioning that icon, not a problem. :)

I see what you mean now you put it like that, it could be nice to have this on the list itself? Maybe at the top/bottom of each list there is a dropzone which will simply remove that issue from that list.

What would you suggest for when you remove the issue from all of the lists but never moved it to Done, should it automatically go to Done? This could be hard as its risky to define something as done just because it doesn't appear on the issue lists. Should it go back to Backlog? This could be hard too as it may lead to actually done issues getting lost back in the backlog.

@dimitrieh From my experience no web standards are well supported but I would be more than happy to give it a go if the UX gurus like the concept.

@lbennett The header for the list could turn into a Remove this label area. That's a good idea

Yeah, that's a problem. What I thought was that you can't remove a label if it's the only one left (unless you explicitly drag it to Backlog). In that case the element would be greyed out, be it the - Label I proposed or the area at the top of the list we were talking about.

remove the issue from all of the lists but never moved it to Done

@lbennett I thought the logic was that done means closed? If done === closed then it doesn't matter if there are no labels or 100 labels.

The header for the list could turn into a Remove this label area.

Very much disagree. It's weird to drag an issue onto the header of the column to remove the label.

@AaronHarun I believe so yes, I suppose I was touching on a suggestion to change done === closed to done === readyForReview

Issue starts at Backlog
Issue moved to ~Frontend and api
Frontend work is complete, issue is removed from ~Frontend (now only exists in api list)
API work is complete, issue is removed from api
Is this issue now Done? Should this issue now be closed? What if there is something that needs to be done that isn't within the scope of any of the lists? But should this issue be in Backlog? I don't think so either. :(

Isn't this defined by the specification, which says that "Done" shows closed issues? Unless there is a list for the labels, it goes in the "Backlog" list.

There are three types of lists, of which two are default:

Backlog (default): shows all issues that do not fall in one of the other lists. Always appears on the very left
Done (default): shows all closed issues
Label list: a list based on a label. It shows all issues with that label

As this will probably replace milestones, I think a board needs to be set to represent a certain milestone by default. So that even when an issue is in the backlog, it still belongs to a certain milestone.. unless the viewer changes the view to all issues?

Or we still need the milestone view in order to show the current milestone specific issues be default.

just adding a few cents

"I think a board needs to be set to represent a certain milestone by default." No. For example, Kanban methodology doesn't use milestones at all. If this board should be attractive for wide array of users, it shouldn't force you to start using milestones.

@illich mmh but the milestone view is a very nice representation of what the team is working for this release (at least for gitlab ce itself)... maybe as said that's where the milestone view is still good for. It redirects to the issue board with the label "milestone-X.X" active on all issues.

@lbennett

API work is complete, issue is removed from api

Is this issue now Done? Should this issue now be closed? What if there is something that needs to be done that isn't within the scope of any of the lists? But should this issue be in Backlog? I don't think so either. :(

Firstly, why would it have the API label removed? Even closed the issue was still an issue that refers to the API.

Secondly if the issue has had the work it requires completed but hasn't been for code review then the issue is not done, it goes in the Review list not the Done list. An issue would only usually be moved to Done when it is actually done, thus it can be closed.

@dimitrieh I would agree with @illich, I use issues and kanban heavily but have never needed milestones. Milestones can be there no doubt, but having a board represent a certain milestone by default would not suit a lot of people I believe. Also it adds unnecessary complexity, how does one set what the milestone shown is to be? how owould that setting be set for multiple projects? For boards that handle multiple repos? It adds up.

"api" and "frontend" are probably bad labels for this example, since, as @lbennett notes, these are labels you want to keep. I would imagine that a list would use labels such as "Ready", "Doing", "Review", which matches more the typical workflow.

However, if the criteria for being in the "done" list remains "shows all closed issues", it is not necessary to remove any labels. Moving an issue from "api" to "done" could only close the issue, and leave the label as it was. Of course, this is not nearly as nice if the label was indeed "doing".

And for our use case: we don't want to see closed issues on the board (because there can be thousands of closed issues). So either do it as AgileZen - Done (closed) column is hidden (and only opened when necessary) and it shows only last 10 or so closed issues. Or just don't show closed issues on the board at all. Just provide a clickable link to the Closed issues page (which is already implemented in gitlab).

As for making the issues seem draggable... Instead of the horizontal bars

if we look at trello we see:

quick mockup (not taking border radiusses, colors etc to much into mind):

left to right: (gaps between issues) + hover, (gaps + no borders, only bottom border/shadow) + hover plus it has the sides of the issue lists a little broader.

I don't particularly say this is the right direction, but it certainly increases the feeling of draggability.

@dimitrieh that looks cool! To implie draggable further, the cards could be set in a with in a second darker background, such that they looked to be in a "tray" (without being too skeuomorphic). Or maybe that is too "busy"??

Or maybe add the hamburger icon that can be seen to give the same queue in a lot of other interfaces recently?

I think there are two issues being discussed, in more or less parallel. First, how are issue boards going to work? Second, how are they going to look?

I believe that the first issue (functionality) really needs to be decided and well documented. While the user interface can evolve over time, it is probably not acceptable that a new GitLab release (for example) suddenly removes lots of issues from a board, or changes the functionality such that the board starts behaving differently.

@cperessini You're over complicating it! :) Ship the small things that work and see if you really need this complication. Encourage and optimize around a small number of lists. Dragging between lists should generally happen one at a time (generally left to right). If you do need to drag further, then automatic horizontal scrolling makes this possible.

The whole add/remote individual labels at a time is overkill. Items should only show up in a single column at a time. Someone could potentially add multiple labels via the regular issue system, so we need to handle this gracefully, but we don't have to optimize for it or encourage it. A scrum/kanban/whatever/process/you/like board only makes sense when a card exists in a single column. Sure, I could see some other kind of board allow cards to exist in multiple places, but that's not what we're targeting in this release (or ever?).

IMHO, there are a few existing conventions that should be considered when implementing Issue Boards. Many implementations have been worked out previously and I think it would be wise to study them before re-inventing the wheel. Below I'm using certain terms to be descriptive and communicate clearly. The terms are not intended to change the GitLab implementation or push a certain methodology.

Premise:

Issue Boards are used to present Issues in a visual way to assist project users, developers and maintainers see where issues are in a workflow
Issue Boards allow for grouping Issues into Workflow Stages
Issue Boards allow for grouping Issues into Issue Types
Issue Boards are not a replacement for searching by Label

Workflow Stages vs Issue Types vs Priorities vs Milestone

Workflow Stages: Work typically flows from left to right using Stages. Issues should have only one stage at a time

Backlog, On-Deck, In-Progress, In-Review, Done
Note 1: Backlog & Done not always shown due to the large quantity of items
Note 2: Backlog shows all issues without a Workflow Stage & isOpen
Note 3: Done shows all issues with or without a Workflow Stage & isClosed

Issue Types: Issues are commonly labeled with one or more context labels

Issue Category - Bug, Enhancement, Readme, etc.
Functional Area - API, UX, Frontend, etc.

Priorities: Priorities provide a rank so higher priority issues bubble to the top of the list.
Milestone: Issues are grouped together in a milestone regardless of Workflow or Label.

Issue Board Display

Workflow Stages are typically left to right columns & Issue Types show all labels on the Issue.

Swimlanes: When the number of open issues grows, adding another sorting view becomes necessary and swimlanes are a common solution. Being able to group issues by Priority or Milestone or User and show them in their workflow stage is a very common practice when the number of issues flows off the screen.

Filtering: Being able to see the Workflow Stages sorted with Swimlanes may also be overwhelming when there are a large number of issues so being able to filter and only show items by Author(s)/ Assignee / Label(s) / Weight.

I love the distinction between showing Workflow Stages and Issue Types. As I understand it, we've only spec'd out the Workflow Stages part. Using issue boards to group issues into Issue Types may indeed be valuable, but feels like a different view than the one we're focusing on right now. Trying to support both in the same view may be counter-productive.

sorry for interrupting the functional flow with the looks.

@toby-mole nice thinking along! However the point why I made the example mockups was to get off the idea of needing the hamburger icon. It takes up unnecessary space on every card. IMO that is inferior design.

To illustrate this: There are going to be hundreds maybe even thousands of issues displayed at the same time. If you sum up all square pixel space these icons would take up... Not a pretty picture. No the design itself should make it clear its draggable.

As for the second darker background... A box within a box is unnecessary and just adds more clutter (the list itself is already a tray of some sort, i would rather go with the abstract than the skeuomorphic). However a little darker for the list background wouldn't hurt, if it stays in line with the rest of the gitlab design :)

alternatively and imo an inferior solution would be to show the hamburger icon on hover (although this is less than ideal on touch devices, as there is no real hover state)

btw I did the previous mockup without access to the antetype files/ original design files. I could iterate a little better if I had that @cperessini @hazelyang

I agree with @dhekimian completely.

And for our use case in his terminology:

we need: workflow stages (columns), issue types (labels; in some kanban tools represented as colors, which I like more)
we don't need: priorities, milestones, swimlanes (but I don't mind if they are there; we will just not use them)

Also one thing which we use on our current board (AgileZen) are "Size" of the issue (in points; this is common practice in Scrum).

@toby-mole

it goes in the Review list not the Done list

I completely agree. Review list is currently not a required list in the proposal.

Re: UI

I really like the issue items proposed by Hazel, I think the borer radius and padding looks nice, that's a given, but it feels a little too much, there is something really exciting about the more compact items that are similar to the already existing UI elements, plus it just looks awesome in its draggable state if its compact.

Keep it simple. Leverage what already exists. I think with those in mind, a nice design should emerge.

I like the idea but there are some problems that needs to be solved before it goes to development.

1 - Number of issues. For a small project it might work ok but if you think about gitlab with more than 4k issues boards would be a disaster to use. maybe for upcoming milestone it would be around 1k / 3 boards so around 333 per board.

2 - Boards would be never equal, so imagine 1 board have 300 issues and another have 100. How that would be possible to drag bottom issue from 1 board to the other board if you can see it on the screen.

3 - Sorting dropdowns how that suppose to work? what will be the view after someone will select marketing label?

4 - original proposal - modal - we are still don't have any modals aren't we? @hazelyang did a nice job with create a new list.

5 - What if issue have a due date?

All these things are not covered by proposal and UI either. Stills lots of work here

Number of issues. For a small project it might work ok but if you think about gitlab with more than 4k issues boards would be a disaster to use. maybe for upcoming milestone it would be around 1k / 3 boards so around 333 per board.

Adding the ability to search for issues within the backlog list could help this problem.

Boards would be never equal, so imagine 1 board have 300 issues and another have 100. How that would be possible to drag bottom issue from 1 board to the other board if you can see it on the screen.

It looks like the current UI that Hazel worked on made all the lists equal height and they scroll within that height so you should be able to see the lists while dragging.

original proposal - modal - we are still don't have any modals aren't we? @hazelyang did a nice job with create a new list.

I like @hazelyang 's proposal as it matches other UI. Currently the 'Create new list' menu has a search ability that is labeled "Filter labels" but I think this is actually meant to be "Search labels"

Re Issues in multiple lists

One aspect of this that I'm unclear on is how an issue gets added to multiple lists. If it has multiple labels, how is the issue being duplicated to appear in both lists after moving it from the backlog?

--

It would be easier to make/upload iterations to this if the antetype files were added to the design repo like @dimitrieh mentioned. cc @cperessini @hazelyang

One aspect of this that I'm unclear on is how an issue gets added to multiple lists. If it has multiple labels, how is the issue being duplicated to appear in both lists after moving it from the backlog?

Do we need to support this? If you drag it from the backlog, it must not have any matching labels yet, so we'd just add the one label for whatever column you dropped it into. Do we need to support dragging to multiple columns for this iteration? If the issue happens to have multiple matching labels already, we can just display it in both columns. The concern is when someone then drags the issue from one of those columns to another column or to the Done column. For this, we have (at least) 2 options:

remove the label from the column it came from, add the label for the new column
remove all column-labels, add the label for the new column

(1) works fine, but might be confusing when moving to Done since the issue won't actually close and won't show up in the Done column until all labels have been removed. (2) works better for done, but then explicitly doesn't support multiple column-labels per issue and kind of "fixes" it when moving.

@tauriedavis @cperessini @skyruler I just added the antetype file (GitLab_8.11_Hazel) to gitlab-design.

@markpundsack @tauriedavis

The only case in which issues should exist in multiple lists if you happened to add multiple labels to the issue. It should not be possible to do this on the board. The reason we'd show the issue in multiple lists is because otherwise we'd have to remove the labels on creating the lists, which seems very opaque.

I think the best solution is to remove all labels that have lists when moving to done.

When moving to other lists than done we can either:

remove all list-labels but the one you're moving to
show a popup, giving the user to option to remove them
have the normal behavior

Alternatively, and this might be the better solution, when creating lists we can show a warning when you add lists that cause you to have duplicate issues and make it so that the list-labels are all removed and the issue is just added to the backlog.

Regarding manual sorting: we can use the milestone sorting and reflect it here. So that if you scope your board to a milestone, you can still rearrange it.

"The only case in which issues should exist in multiple lists" is if the developers really insist on column=label approach and don't cover all the edge cases resulting from this poor decision.

Sorry, couldn't help myself.

Imagine how everything would be simpler (both UX-wise and tech-wise) if each open issue just has its column (as N:1 or not N:M as labels do).

An issue's "board column" should be orthogonal to its labels. I have to agree with @illich here. It would be better to separate the concerns of labeling an issue and workflowing the issue.

I also agree with @JobV that an issue should not appear in multiple lists/columns of the board, though that can be accomplished without "column == label". For instance, each issue could have a database field that defines what (singular) list/column of the workflow it is in.

EDIT: Any noun in a model that needs an adjective is a noun with growing imprecision in its meaning.

I'd like to agree with @gsmethells position that labels and columns be orthogonal, but then whenever boards are launched all currently existing issues will have to be placed in their relevant columns by hand. The main benefit as I saw it of having column == label is that existing issues will automatically be placed based on their previously assigned label.

I do have to say though that this is about the only benefit I can see of having column==label over column being distinct.

@toby-mole @gsmethells the additional point of having lists == labels is so that management can be easier without having to add more interface elements (sidebar, issue overview) and that we can add multiple boards in the future quite easily.

If you insist on the separation, you could make labels (from the boards view) like board: todo, board: in progress.

We could even consider adding special functionality to limit board:* labels to only one per issue.

Here is an updated UI with a search included for the backlog (to help with Andriy's point about a large number of backlog tickets). I also spaced out the issues to make them look more draggable re @dimitrieh's idea. Any feedback on spaced vs compact?

Thanks for explanation re: issues in multiple lists @markpundsack and @JobV. If a user drags an issue to Done when it is in multiple lists, how about we provide a prompt that tells them the issue is in multiple lists and asks them to choose whether they want to remove it from all lists or just the list they dragged it from. Other lists are disabled during this time until the user either a) selects an option or b) drags the issue back out of done.

Another option is to only put the issue in the first list it has a label for. It would still have all labels, but only be in one list at a time. This probably needs some more thought but just throwing out the idea.

@tauriedavis I like the idea of having the popup. I'm guessing that it wouldn't happen too often to be annoying and this works around the fight of either being more intuitive than the other. Great work on the mockups, by the way.

The search option is awesome

Any feedback on spaced vs compact?

Hm I'm not sure. I really liked how clean the earlier designs looked, but in your latest, it definitely looks more like a board with cards. As my wife just said "it's more cardy", which I think is a good thing.

!!!

@JobV FYI I just saw http://www.bitbucketcards.com/

@JobV Personally, I'm kinda against the popup. It's a complication that seems unnecessary. Feels like it's going against the handbook. :)

We've just said that you're not supposed to have issues with multiple list-labels, so why not just commit to that? If someone moves it to done, assume they meant it, and the issue is now done, therefore remove all list-labels on it. Otherwise you're subtly encouraging people to use multiple labels.

@tauriedavis Could you remove the border on the cards? I think that will bring back some of the cleanness @JobV craves. The different background color should be enough to delineate.

@JobV You are speaking of UI for defining the board columns used by a project and UI for displaying the board state on the issue page?

I see that this very issue page already has "Todo [Mark Done]" on the sidebar. Seems like this UI element would be what would tie into the issue board, yes?

As for defining board columns, I suspect that would be on the board page that is being made here and appears to be "[+ Create List]" that I see in these screenshots.

Here is an updated UI

@tauriedavis looks great. Please remove plus icon from Create new list button. See https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/ui_guide.md#buttons

We've just said that you're not supposed to have issues with multiple list-labels, so why not just commit to that? If someone moves it to done, assume they meant it, and the issue is now done, therefore remove all list-labels on it. Otherwise you're subtly encouraging people to use multiple labels.

@JobV I think comment from @markpundsack makes sense here. If you have 2 lists that re-use same issues it would quite annoying to deal with any kind of confirmation. And since action is not destructive I think we can try it out first before introduce prompt.

Could you remove the border on the cards? I think that will bring back some of the cleanness @JobV craves. The different background color should be enough to delineate.

@JobV @markpundsack According to the look of cards I see different opinions here so I think we should leave it up to @tauriedavis and @hazelyang to decide. They have more expertise

@dzaporozhets @markpundsack agreed on all accounts. Go for it @hazelyang and @tauriedavis.

The http://www.bitbucketcards.com/ link that @sytses gave shows one very interesting small additional feature - that the columns themselves are also drag and drop. Could that be on the cards for this implementation also?

@toby-mole @tauriedavis yes, good point. I think the columns (lists) should be able to be dragged between each other.

@tauriedavis Nice! As for the draggable thing. Now that I had access to the design files I came up with this:

instead of the lines, we have an abstract sort of dropshadow that enhances the "draggable cards" look and I kept the spacing, but I think it looks a little better when the vertical spacing(3px or 4px with the shadow) is a little more than the horizontal one (2px).

plus slightly rounded corners for each issue, to make them seem an element on their own (like the issue list).

mentioned in issue #19793 (closed)

Thanks for the feedback everyone. I've updated the UI based on the above comments.

@tauriedavis I love the card design, looks much more draggable now :)

How would you imagine deleting a list would work in this case?

Thanks for bringing that up @connorshea. The proposal has "Remove this list" under a list but I'm not really sure how that was intended to work so I've added a trash icon on non-default lists to match other UI we have on the site.

cc @dzaporozhets

I've added a trash icon on non-default lists to match other UI we have on the site.

@tauriedavis nice one.

I've updated the UI based on the above comments.

@tauriedavis looks great.

Great, I think this is ready to move to frontend.

Added frontend label

Removed ~19492 label

We haven't discussed a hover state for cards. I think if we keep them the way they look now we should show the "grab" cursor on hover.

We could also add a tint to the background of the card, but I don't think that'll help too much to convey the message.

Thoughts?

I think the cursor should be pointer on hover, grab on click/move. And a background color change on hover is a good idea :thumbsups: @cperessini

I'm thinking about onboarding. Do you think we should start new issue boards as basically blank, with just the Backlog and Done columns, or should we start add To Do and Doing to every one by default so people have a reasonable place to start?

I guess we could something similar to how we do labels, with "Create a label or generate a default set of labels." Maybe the default set of labels should include To Do and Doing?

mentioned in issue #19952 (closed)

This looks great!

Reassigned to @iamphill

mentioned in issue #20335 (closed)

mentioned in issue #20135 (moved)

@markpundsack I believe Gitlab-Kanban by Leanlabs.io has sane defaults for its kanban. Backlog, Development, Testing, Production, and Ready.

"Production" (i.e. Production-Ready) and "Ready" (i.e. ready to merge) are kind of vague; but keywords which must be learned are better than long descriptions. The big decision is if these are the right concepts.

The more I think about it, the more I like starting with a blank slate, but providing a single click to generate a default set. Companies are just going to have too many different ways of doing things, and it'll be annoying to have to fix them every time. On the other hand, I imagine for single-tenant installations, or at least EE installations, companies can set their own "default" set.

@markpundsack I think that's a good idea. I made a mockup using the lists that @john.r.moser mentioned. I'm not sure how we could automatically sort issues into these categories (or any others) since the labels are going to be brand new to most projects.

I like the look and idea of that

What's going on with the Author, Assignee, etc. at the top?

@john.r.moser If you use the filters, each column shows only the issues that have those attributes.

What about swimlanes?

Shouldn't there be support for multiple boards so that different groups working on the same project can organize their work separately? E.g. GitLab.com design team could have a separate board for all tasks that contain the Design label, performance team has their own Performance board etc. In this case, each board would have an optional label-based board filter additionally to lists.

(PS: that's how JIRA boards work and it's really convenient.)

mentioned in merge request !5548 (merged)

Horizontal swimlanes multiple boards per project are both great enhancements, but out of scope for this iteration. We'll likely track those in separate issues. For now, the most you could do is filter a board. We hope that will provide a lot of value as-is, but also let us learn from actual usage quickly so we can make more informed decisions in the next release.

@mrts Yes. There should, in the most-optimistic case, be Project Boards (part of the project and not modifiable except by admins) and User Boards (owned by a user, either private or exposed to the project members or whatnot, copyable). Making the distinction is complex in implementation.

It's at least feasible to have multiple Boards and let the team argue over who is allowed to muck about with them. In the context of #19624 (closed) it would be wholly-reasonable to have a different board for each root Deliverable (which can logically represent a different PMI Project or Scrum Epic), the board collecting all the Issues in the Deliverable tree; but that discussion can be left off until such a point that someone decides to implement that (possibly in support of #20135 (moved)).

By extension, you may want a different board for bugs than for development (e.g. for new features), although this is not strictly necessary (the workflow of fixing a bug is substantially-similar to implementing a feature or other deliverable).

As @markpundsack says, these are things for a later iteration. I believe swimlanes are a basic feature of this type of board, and the UX is trivial (the whole "board" is repeated vertically); the back-end code would require adding filtering and iteration, which may be more complex (i.e. you'd have to pull all the appropriate issues, group them by whatever you're swimlaning, then iterate through each group in sequence, thus encapsulating all of the logic of a basic Kanban Board in another set of logic that's just as complex).

Note about default lists

When default lists are created, they are empty because the labels associated to them did not exist up until that moment, which means the system has no way of populating them automatically. It'll be the users' job to add individual issues to them.

@cperessini
If the user already has labels of the same name as a suggested default board label, say Testing, then surely the user just clicks the green "Create new list" button and selects the Testing label?

Or alternatively they select the "Add default lists" button, the system should check a label of the same name does not already exist before creating it, if it does then use then skip creation and just add to board. Then if issues already exist with that label they get automatically added along with the lis, if they dont then it is the same as a normal label creation - create a label, add it to some issues.

@toby-mole That was a note about a conversation we had. Labels and lists are created at the same time when using this feature, which we'll be adding when development allows https://gitlab.com/gitlab-org/gitlab-ce/issues/17907#note_13390337

From the initial plan, it looks like we remove the labels when the issue makes it to done. Is that still true?

Do we think that people ever search closed issues? I personally do and would like to keep my labels on the issue even after it has been moved to closed. Just a question since my workflow may be different.

mentioned in merge request !5713 (merged)

mentioned in issue #20622 (moved)

Interesting feedback about Milestone views in #20622 (moved) that are relevant to issue boards. We already bold the issue titles in issue boards, but we might want to consider muting the label colors as suggested there as well.

mentioned in issue #19114 (closed)

@amara The idea is that you assign issues labels that are only used inside the Issue Board, like To do, Doing and Testing. When you move an issue to the Done column it only removes these labels that have a column, and not other ones like wiki , security or ~Backend . Does that solve the problem for you?

@markpundsack That's interesting. I think it's important to try and keep the colors looking as close to the original ones as possible because they provide a very instictive way to distinguish labels. Maybe if we set the opacity a little higher we can get the best of both options.

Does each milestone have its own board? Or is it per project? The screenshot seems to indicate the latter.

@cperessini Yeah, it doesn't have to be as muted as suggested on the other issue. But also, I'm hoping that by showing full colors on mouse hover, the connection will still be there. Will have to try it out to see how it feels though.

@gsmethells The latter: one board per project. Clearly we will want more advanced things later, but this iteration is about shipping the simplest feature.

@cperessini thank you for clarifying! That solves it!

@markpundsack got it. This is going for a Minimal Viable Pfeature. Will it be easy to pull in issues already cordoned off in a milestone? I would suspect that the issue board workflow should be focused on something. Perhaps the column title could be a milestone title and would pull in issues on the left-hand side for use in the workflow going toware the right-hand side?

EDIT: That does not allow for a separate board per milestone yet, but it would lay the ground work for how it could flow issues in any given milestone.

@gsmethells You can filter the entire board by milestone (and labels, author, etc.), and I guess you could bookmark and share that URL so you'd have milestone boards on-the-cheap. I imagine it's a short hop to saving/sharing pre-filtered boards in a formal way, if that's the direction we go.

mentioned in issue #12781 (moved)

What if the user wants to call it "TODO" or "Pending" instead of "Backlog" (e.g., "TODO to Done")? Is that an option?

EDIT: We already have a milestone called "Backlog" and I'd hate for there to be confusion. I understand that there is a "Todo" bell in the navbar already, too, hence "Pending" is what I'd probably do, if able.

mentioned in merge request !5554 (merged)

mentioned in issue #20800 (closed)

Good question! Let's track that in a separate issue, for after this iteration. Maybe nobody will mind. ;)

What happens in the case where there's already a Backlog or Done label? How's that gonna work?

I imagine you'd be able to create two Backlog columns if you wanted; one for issues with no labels, and one for issues with the Backlog label. Seems like a non-issue.

@markpundsack if that's the intended behavior then that's ok. The current implementation does not work that way so we'd have to communicate that to @dbalexandre as this is a backend issue I suppose. The current behavior is to not create an extra column, it just uses the existing Backlog and the label doesn't get removed if you move between lists.

@axil I'll check this. Thanks

mentioned in issue #20834 (moved)

@markpundsack ok that's now in #20834 (moved)

What happens if an MR says Closes #1 and closes the issue upon merge while issue #1 is on the board? Does issue #1 change columns? Is issue #1 still visible on the board even though it was closed by the MR merger?

EDIT: I'm picturing an issue in a column for a "Reviewable" label. The reviewer likes it and merges (and the MR has Closes #1). One would want it to move out of the "Reviewable column" automatically and to the next column along? Just trying to figure out how this fits into the existing mention feature.

@axil This is a frontend issue, the Create new list dropdown should only check for lists that have it's type set to label. @iamphill Can you take a look please?

As this features matures it seems more appropriate in EE or a separate product entirely given the competitive landscape. The litmus test for EE features is weather it's useful for teams of more than 100 and/or large complex projects. An Issue Board clearly meets that criteria.

I'm wondering why this is being proposed/implemented as a CE feature? This sort of functionality is of most use to large teams with more tasks in-progress. As such it would seem to fit in well with our "most relevant to teams of over 100" methodology of it being in EE only. Now, as to whether it is a feature or an option I'm not sure. There are companies whose business is based on just this functionality. Check out Trello and Waffle, for example -- and this would be more tightly integrated and therefore of even more value to customers.

I really don't get that CE/EE separation. How is this more useful for 100 than 50 developers? I am scrum master for a team of 4, and we would love this.

I don't understand why you guys think it's only good for large projects/teams?

This feature should be in the CE as planned and announced. Boards are becoming more and more popular and standard in daily workflow.
In my workplace many many people have even personal boards to track their daily (weekly/monthly/quarterly) task schedule. In here teams are all consist of 3 or 4 people at most not more than that. And we use boards heavily.

+1 to adding it to CE

I have 7 developers, 4 testers, and 1 tech writer. We use boards.

I don't see this becoming an EE only feature as we need it for the idea to production workflow. At least the basic functionality will be a CE feature afaik.

@markpundsack any thoughts on this?

What happens if an MR says Closes #1 (closed) and closes the issue upon merge while issue #1 (closed) is on the board? Does issue #1 (closed) change columns? Is issue #1 (closed) still visible on the board even though it was closed by the MR merger?

@gsmethells Same thing as when someone manually closes an issue while someone else is looking at the issue board. If we support realtime updates, which I'm not sure we will in the first iteration, then the issue will move to the Done column. Otherwise, it'll be closed, but won't be updated in the UI until you refresh.

I think a user should be able to rename the Backlog and Done columns. Because we would prefer a column Sandbox with all the unstated issues, and a column Backlog for issues that are important and needs to be addressed. Tools should adopt users workflow, not the other way around

~~But as a workaround we could adopt the ~up-for-grabs at our company~~

edit: My bad, didn't see #20834 (moved)

What about @illich comment about too many issues in done and backlog column??

At the moment gitlab-org/gitlab-ce has 4385 open issues, and 6963 closed issues. Showing them all in the Backlog and Done column would be needless, the lists will be too large to scroll and search for a issue manually and only burden the users webbrowser.

Proposal: use infinite scrolling, only load the first 20 or so, when user scrolls down, load the next 20, etc

Regarding the choice to bring this to CE

We envision GitLab to be able to bring you all the way from idea to production, read more here. We see issue boards as a vital feature in this, where you are able to plan and coordinate your team's efforts. Every step in the process of bringing your idea to production will be expanded and better integrated with the others with every release.

If we would only bring this step to EE, it would mean that we'd not offer the complete vision to CE users. More importantly, this means that once we start to add further integrations and features, we'd be diverging the CE and EE code significantly. We don't want to do that.

EE exclusive features should be additions and improvements upon CE so that both code bases stay maintainable and that we can have the same, extremely short development cycle for new features that we have now. We expect to expand issue boards significantly and there will be plenty of space to offer EE exclusive features within issue boards, but given that we make this one of the pillars of GitLab, it would be unwise to limit it to EE.

This is always a very tough choice with clear support for both sides, for every single feature. I welcome suggestions for enhancements restricted to EE, be it multiple boards, advanced filtering, better control of permissions or something else.

cc @xyzzy @ChadMalchow @regisF

@amara suggested to rename lists to columns. I have no clear preference.

Let me see a vote if you think we should change it:

lists
columns
I don't like either

another thought is calling it stages

The current implementation is to hide the labels from cards that correspond to the list they belong to. Is anyone else confused by this?

@cperessini 's answer was that's by design otherwise the same label would show in every card for that list and it'd create a lot of visual bloat.

I'd argue that while it might add a little bloat, you don't have a visual of the labels changing on the fly when dragging and dropping issues to lists. Thoughts?

The current implementation is to hide the labels from cards that correspond to the list they belong to. Is anyone else confused by this?

@axil I am! I prefer being able to see the label changing than to see it disappearing :)

another thought is calling it stages

@ChadMalchow I think this might be confusing once we use stages for GitLab CI pipelines.

I see 8.11 RC is out for CE, but it seems not to have the boards tab. I see this issue is tagged for milestone 8.11; is that still the plan?

I prefer being able to see the label changing than to see it disappearing :)

@virtuacreative Why would you see it disappearing? The labels used for lists just wouldn't appear at all, so you wouldn't see them disappear. Unless you mean when viewing the issue outside of the issue board vs inside the issue board?

Personally, I really dislike showing the list-labels in the issue board because they repeat for every entry in the list, and are redundant. You have very visual feedback already of the labels changing by virtue of the item being in a new column.

Imagine a degenerate case where a company doesn't use labels at all, except for issue board list-labels. Then every issue would have a label for the list their in, and that's it. I think it would look silly to show those labels in the issue board columns.

I know it's a little confusing that the label list is different when viewed in the issue board vs in the issue list, but that's an acceptable difference. If it's really a problem, I'd imaging going the other way in a future iteration and hiding these list-labels from the issue list so everything is in sync. Or treating list-labels as different things and showing them differently in the issue list.

@markpundsack I mean I loved how it was here:

I mean, when you move the cards, you actually see the label changing. And if there is more than one label per card, you see all of them

@markpundsack Perhaps the column title could be displayed as a label, then it would be effectively present, but pulled to the top? I think that would at least be a bit more explicit which I think is the underlying issue @virtuacreative is getting at. It is not as explicit as the animation. I'd like to see it be at least somewhat less implicit because that is not as intuitive.

Sorry for the sidetrack question.. Is this still on track for %8.11 ?

That's the plan @halilozturk :)

mentioned in commit 35caa356

mentioned in commit 46dc0063

mentioned in commit a5b5061e

mentioned in commit 26d872e5

mentioned in issue #21071 (closed)

Nice to see this @ Gitlab.com on RC3

A few things I think are essential to make this useful:

At least Group level boards that aggregate all group project's issues
- I think this is a necessity because all of my projects (not gitlab projects/repos) are at the group level, and I require many code repositories.
The above should require that tag edits at the group board level are added and subtracted to all projects
- If you need an example of this, go look at codetree for Github, they do an excellent job
- Tags don't need to be synced actively only when adding or subtracting
- A project should be able to use a tag from another repo, which would count as a surreptitious add
- Subsequently a deletion of a tag at the group level would remove it from all repositories.
Track dependencies with issue comments like "needs name/repo#issue" "blocks" "requires"
Alternative to #1 (closed) is that we should be able to link multiple repos together within a board. This doesn't change much about #2 (closed) or #3 (closed) however.

@xenithorb label oriented points in (2) are covered by #19997 (closed) likely

Found myself very confused by . I couldn't figure out what these stages were supposed to mean. We should at least sort this list based on what we think the flow is. But perhaps we should start simpler. Like backlog, todo, doing, and done.

I absolutely agree with you @markpundsack -- I was wondering the same thing. But upon further inspection it seems one can create lists from existing labels. It's trivial to do. What I've not been able to figure out is how to get back to the default lists after initially deciding to do something else.

Production and Ready are confusing to me. Chris made a point that todo could be confused with our todo feature.

We already have backlog and done and so what if the optional default lists were:

Pending
In Progress
Review

These should work for different types of teams - development, marketing, sales, etc.

Really love those Issue Boards ! Great work! However there are a few inconsistencies that I would love to see fixed (either in this iteration or another one in the future). For reference, here's a screenshot of the current GitLab CE issue board:

The issue counts for lists are off (displaying 20). Instead of counting the actual number of issues in one list, it counts the number of loaded issues. This is not intuitive and I'd love to see the actual count, so I have a fair estimate of how everything progresses.
The Done list doesn't have a search field, but the Backlog list does. I would say it's also important to be able to quickly filter the issues that are done, so one can easily answer the question "Has feature x already been finished?".
The board itself doesn't take up as much screen space as it could. Though this is more an issue of the new tabbed navigation along with the second level of navigation, I find it kind of sad that more than a third of my screen is "wasted" on navigation stuff which kind of takes away the focus from the issue board itself. Lists are also harder to navigate as fewer issues can be shown in each list at one time. (Screenshot was made on a 15" laptop)

Other than that I really like the direction this is going and the user interface looks really awesome . Keep up the good work!

The board itself doesn't take up as much screen space as it could.

Agreed, we built a similar UI/product (though unrelated to dev) for internal use and a "fullscreen" button was hugely useful. It ended up getting displayed on the wall on its own touch screen for a real-time overview of what was happening with the 300 people working together.

@tauriedavis That helps, but pending might still be non-obvious. Honestly, I think the biggest problem with my screenshot was that the order of the lists wasn't represented properly, which made it hard to understand what they meant. For example, pending could mean pending work, pending review, or pending deploy to production. But if it's the left-most column, and at the top of the list of default lists, then its meaning would be made (more) obvious.

Kinda wish we had automatic labels for assigned and WIP so issues could automatically move when an issue is assigned to someone, and when an associated MR has WIP or not. Overkill for now, but would be powerful integration.

Thanks for the feedback @TR4Android!

The issue counts for lists are off (displaying 20). Instead of counting the actual number of issues in one list, it counts the number of loaded issues. This is not intuitive and I'd love to see the actual count, so I have a fair estimate of how everything progresses.

This will be fixed with the full release!

The Done list doesn't have a search field, but the Backlog list does. I would say it's also important to be able to quickly filter the issues that are done, so one can easily answer the question "Has feature x already been finished?".

I agree, we should add it.

The board itself doesn't take up as much screen space as it could. Though this is more an issue of the new tabbed navigation along with the second level of navigation, I find it kind of sad that more than a third of my screen is "wasted" on navigation stuff which kind of takes away the focus from the issue board itself. Lists are also harder to navigate as fewer issues can be shown in each list at one time. (Screenshot was made on a 15" laptop)

Yeah, this is tough. It's because of the navigation. I'm not sure what the next iteration of the navbar will bring cc @tauriedavis

+1 to a "fullscreen" button.

@tauriedavis @JobV @AshleyS are we changing the default labels before the launch? If so, this will affect both the landing page and the video. See https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/2895

Oh, and the docs too: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5713

mentioned in issue #21139 (closed)

mentioned in issue #21140 (closed)

@virtuacreative I'm not sure the change would get in by Monday. I've made a new issue for it here: https://gitlab.com/gitlab-org/gitlab-ce/issues/21137

I've also made a new issue for adding search to the done list. https://gitlab.com/gitlab-org/gitlab-ce/issues/21139

Lastly, I've created an issue to explore a fullscreen mode. https://gitlab.com/gitlab-org/gitlab-ce/issues/21140

@tauriedavis thank you! :) Okay, I think it's better if we don't change them today, because it would affect all the material we have prepared to launch it, which is pretty impossible to re-create at this point, until the launch time. We can accomplish that later. Please ping me and Axil in the MRs so we can update the things across the website and the docs. Thanks!

mentioned in commit a41cd65e

mentioned in issue #17390 (moved)

@JobV Thanks for answering! Looking forward to those improvements

There are growing issues about Issue Boards.
Maybe the time for adding issue boards label has already come? =)

mentioned in merge request gitlab-com/www-gitlab-com!2960 (merged)

Completely agree, the default should be simpler. Actually only "Doing" sounds good default. I think that what most Kanban offert by default, like Trello

Make sense

Browsing the GitLab-CE Issues Board is not so easy as it would be, since there are no searching input field in all boards except Backlog one.
So scrolling down board just to find an issue is not perfect UX, if I could just type some text in a search field.
Thoughts?

Maybe is enough to have one input that search on all boards.

@blackst0ne @singuerinc Thanks! We have a proposal for a search field that searches across all lists in https://gitlab.com/gitlab-org/gitlab-ce/issues/21139#note_14142749

I didn't want to make a new issue for this, but a way to order these lists would be huge. Being able to prioritize a list by ordering it is one of the basic functions of any sort of programming backlog. Without this, it's almost impossible to say what is more important to work on sooner and later.

Also, could we please move the Backlog and Done lists as well? For example I would love my 'Icebox' list to be to the LEFT of Backlog.

I didn't try the new issue board yet (we will install it in a few days), but I second what @NickBusey is saying:

order within the column is important
having a column before backlog (we call it icebox too) is essential too

All the other kanban tools (agilezen, trello and others) support that.

Along those lines, 'Done' should sort by date moved into the Done column. Recently finished items at the top. Right now it seems to be sorting somewhat randomly?

mentioned in commit 462a4b79

Milestone changed to %8.12

Ok, I see with the new docs committed by @axil that sorting is done with priority labels. This will work better than nothing for now, but I still think a drag and drop re-ordering tool without needing to make a ton of extra labels would be a great feature.

Also the docs re-iterate that 'Backlog' and 'Done' are immovable columns, but I think this is a bad call. There are use cases for lists to the right and left of both of these columns. Why impose your own constrains on what a user's workflow should look like?

@NickBusey, @illich,
#21264 Ability to sort issues separately in each board

I don't see why a column before "backlog" is required as one can create a new column right after like "Selected", "Ready", "Sprint"...

mentioned in issue #21360 (closed)

As we've shipped the first iteration, further suggestions and changes are welcome in a new issue for the next version: https://gitlab.com/gitlab-org/gitlab-ce/issues/21365

Status changed to closed

As a closing note, I've loved all the feedback and excitement from everyone here. Thank you all

mentioned in issue #21365 (closed)

mentioned in issue #21453 (closed)

Scope
Right now, a single project will have a single board.
In the future we can consider:
multiple boards per project
group level boards
personal boards

Is there already tickets for this that I can subscribe to?

@j-steinblock https://gitlab.com/gitlab-org/gitlab-ce/issues/21365

Guys, do we have plans for a issue board cross-repos?

Cheers!

@thalesfsp https://gitlab.com/gitlab-org/gitlab-ee/issues/928

Mentioned in commit pfjason/gitlab-ce@462a4b79

Please let me know if this feedback belongs somewhere else. Just wanted to share why we cannot use the boards as they are right now.

Besides unassigned, the backlog currently also shows assigned issues in the spring. We follow Agile/Scrum and to us a backlog is all open issues that are unassigned. Having assigned issues show up in 'Backlog' is confusing.
We'd like to be able to add "In Progress" board that groups all assigned issues that are not closed yet. Don't see a way to do this right now.

Pretty much here is the board flow we'd like to start with:

Backlog (open, unassigned) -> In Progress (open, assigned) -> Done (closed)

Thank you.

@demisxbar

It looks like the discussion was moved there.

Please let me know if this feedback belongs somewhere else

https://gitlab.com/gitlab-org/gitlab-ce/issues/17907#note_12940204
https://gitlab.com/gitlab-org/gitlab-ce/issues/21365#note_14800584

But I'm not sure...

Use also search by label "issue board" https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=issue+boards&scope=all&sort=priority&state=opened

Mentioned in issue #22424 (closed)

Would love to use the boards, but without some sort of manual ordering, that's impossible. Is this on the roadmap? Don't worry found it #21264 (closed)

Mentioned in commit nick.thomas/gitlab-ee@26d872e5

Mentioned in issue #24435 (closed)

mentioned in merge request !7684

mentioned in issue #27593 (moved)

mentioned in issue gitlab#4978

mentioned in issue gitlab#5110

Issue Boards

Description including problem, use cases, benefits, and/or goals

Proposal

Moving issues

Filtering issues

Adding a new list

Moving lists

Defaults

Scope

Links / references

Designs

Child items ...

Activity

Issue boards (Default)

Issue boards with 3 columns

Issue boards with 3+ columns

Create a new list

Premise:

Workflow Stages vs Issue Types vs Priorities vs Milestone

Issue Board Display

Re Issues in multiple lists

Regarding the choice to bring this to CE

Admin message

Admin message

Issue Boards

Description including problem, use cases, benefits, and/or goals

Proposal

Moving issues

Filtering issues

Adding a new list

Moving lists

Defaults

Scope

Links / references

Activity

Issue boards (Default)

Issue boards with 3 columns

Issue boards with 3+ columns

Create a new list

Premise:

Workflow Stages vs Issue Types vs Priorities vs Milestone

Issue Board Display

Re Issues in multiple lists

Regarding the choice to bring this to CE