Reorder issue in issue board list
Resources
PM @victorwu | UX @cperessini | BE @vsizov | FE @iamphill
Part of
#25698 (moved) Issue board as a workflow tool
Description
- Typically, teams use the presented order in a board list (sometimes called column) to imply prioritization.
- Order may also imply the time order of developing or shipping a set of features.
- Provide a mechanism to reorder a single issue with respect to other items in that same list.
- The order should be saved so that it persists across page refreshes.
- If you reorder an issue on one board, it may affect the issue's relative order in another board. That is okay.
Out of scope
- There may be a need to reorder multiply issues at a time or even some type of sorting. That is not in scope.
- What happens when issues are moved across lists? That is not defined for this feature.
- What happens if labels are changed for an issue? That is out of scope. The focus of this issue solves the scenario only when in the board view.
Activity
Added ~579196 feature proposal labels
mentioned in issue #17907 (closed)
I think it makes sense. @JobV can you add your input on this feature proposal please?
mentioned in issue #21365 (closed)
@rspeicher
can't we use the milestone-order field for this? Or is that too specific?...on second thought, that's probably a bad idea and we should just build whatever works best.
Edited by 🚄 Job van der Voort 🚀Milestone changed to %Backlog
Mentioned in issue #21365 (closed)
Edited by username-removed-242788Mentioned in issue #22961 (closed)
Mentioned in issue #21314 (closed)
Mentioned in issue #17907 (closed)
By the way, @JobV, is there any plans to add this feature to the issue boards? I mean any milestone here?
@blackst0ne depends a bit on how far we get this milestone :)
@JobV
Milestone changed to %8.14
Subtle, quick animation might be something to consider with this work. When rearranging items, motion can really help build confidence and clarity that the right thing is happening in each move. I think the resulting experience also feels more polished.
I shamelessly forked a codepen and quickly styled it like our lists to get the feel: http://codepen.io/awhildy/full/ALyKPE/
cc @jschatz1
Mentioned in issue #21934 (closed)
Mentioned in issue #22689 (closed)
@yunti we just put all the issues in a 'backlog' milestone and reorder them in there. Hard to use but will keep us going until this lands.
@mattyclarkson thanks for the suggesting. Had a go a that, it's pretty painful and the ordering in the milestone (backlog) isn't reflected in the backlog list in the boards unfortunately. Interesting to see the animation for drag and drop is already in the milestone (mini board).
Mentioned in issue #23610 (closed)
Milestone changed to %Backlog
Milestone changed to %8.14
@JobV I'm moving this to the backlog now, as Douwe didn't have time for it this release. If we schedule it, we need to think carefully beforehand.
Milestone changed to %Backlog
@yunti I'm sorry about that, but the fact is that we didn't get to it this release, so moving it to 8.15 would provide only a false impression of where we are with this. I'd rather be up-front that we aren't working on this (totally awesome) feature right now, than imply that we are when really we aren't. That's still not a great situation, but I hope it's at least clearer what the current status is.
Before we do it, we need to make sure we've really thought about how to implement it, and we just haven't had time to do that work yet.
@smcgivern Thanks for your reply, much appreciated. I obviously don't know enough about your stack to know what needs to be changed to have it incorporated but just wanted to express that there is obviously a desire to have it included. Thanks for clarifying the status.
A workaround for now that may help others (although not ideal).
We really need an easy way to sort a backlog of priority (weight just isn't granular enough or quick enough to use if you have tens, hundreds of items on the backlog).
Create a sorted backlog list next to your backlog. And sort the top (say 10) items on that. You can't resort on that list (ie bring an item from lower down to the top) but you can easily move the items of sorted backlog onto backlog and then bring them back on in the order you need. This is reasonably usable.
@smcgivern the problem is that the thinking was part of the issue; Anyway, we have @victorwu now, who can spend some time thinking about how to resolve this.
I've summarized all the comments and updated the issue description. Key points:
- I renamed the issue to "re-ordering". Sorting usually refers to some type of global change that affects many items in a list. In this feature, we are talking about moving a single issue around a list. So I think "re-ordering" or maybe "re-arranging" is more descriptive.
- With labels determining lists, there is some complexity in the data model of ordering, and may also cause some user confusion if we don't consider all the edge cases. I've offered a definition in the description that should work well with all the weird edge cases. (E.g. changing labels/lists of issues.) Let's discuss if there's anything weird here.
- Developers should tell us how feasible the stretch goal is.
- I specified that dynamic refreshing on the page should be a separate issue.
Reordering issues on the board is the #1 (closed) feature request for me as well.
With that fixed GitLab will be the 1-stop shop for all my private needs at least - not fully featured for enterprise use yet, but I like the direction of GitLab development.
Mentioned in issue #24831 (closed)
Added Deliverable and removed ~307491 labels
Added to schedule and removed Deliverable labels
Re-ordering (and sorting) are crucial to my company as well. We have hundreds of bugs in the backlog and need a way to triage them so devs know which ones to pick. It's a PITA with the current Board.
I might use weight if I could sort by it, but I really only care about PRI0 / PRI1 / PRI2 / PR3. It's also very painful to have to click down into Issues to select, then edit, then save just to update the weight. Would like to edit / sort from the top-level Board view.
Mentioned in issue #21022 (moved)
Mentioned in issue #24686 (closed)
Removed to schedule label
Before we do it, we need to make sure we've really thought about how to implement it, and we just haven't had time to do that work yet.
I must be misunderstanding, because all we're asking for here is the same drag-and-drop re-ordering that is present in the other lists on the board. The metaphor is already in place for all other lists. This seems more like a bug than a feature request if you ask me.
Thanks for a great tool that continues to improve all the time.
First I want to thank you as I'm sure you & the GitLab team are doing the very best you can on this issue.
With that being said, would it be possible to get some sense of timeline for this issue? With https://gitlab.com/gitlab-org/gitlab-ce/issues/24686 being thrown into the mix I'm beginning to feel a bit mislead about an actual delivery goal/timeframe and it would be helpful to to have some expectation management. We strongly desire to use GitLab as our one-stop-solution in our shop, but we're in desperate need of a truly functional KanBan system, and right now we're faking it a bit (as we can't prioritize effectively).
Thank you again!
Edited by username-removed-189949Thank you @jspizziri for your feedback. It's extremely helpful.
It is not our intention to mislead you on release times for particular features. We plan month to month, and priorities constantly change. When an issue is scheduled to be worked on in the coming release, that's a reflection of the priorities at that time. But that might even change before the actual release for the feature to not be included in favor of something else.
That being said, we do have general direction for GitLab, which you can monitor it from time to time (https://about.gitlab.com/direction/).
As for further details regarding issue boards, this page (https://gitlab.com/gitlab-org/gitlab-ce/issues/24688) and all the content linked from there are constantly updated, and always capture the highest priority items. Issue boards is a major area of focus, and you can review and participate in the relevant issues for those latest updates.
@victorwu, thank you! Those additional resources are helpful.
I went to show off this issue board feature internally as part of a review of gitlab's offerings. I must say I was very disappointed to have run into this issue, it makes the issue board feature entirely unusable in the eyes of our users. They are used to using list order as a pseudo priority, is there another way groups use to identify priority?
Edited by username-removed-886320@caruskyle : GitLab does support priority labels (https://docs.gitlab.com/ce/user/project/labels.html#prioritize-labels). It may be a workaround in the interim.
However, we definitely do recognize that re-ordering issues in an issue board is a basic feature, and a major pain point for many that we plan to address. When we have further details on our vision of issue boards, we definitely will share them. This page always contains links to updated information on our plans: #24688 (closed).
Thank you for your feedback. It is definitely helpful as we continuously improve GitLab.
Sorting the issues manually à la Trello would be a nice thing to have.
That said, having a filter to automatically sort out the issues based on the due dates (EDIT: in a column of the board obviously since it already exists in the "Issues" tab) would be awesome to me - and probably easier and faster to implement than the manual sorting. Automatic sorting means less work.
Some people will want to sort out the issues based on their feelings, others based on a planning. I think we need the two behaviors.Edited by username-removed-385783mentioned in issue #25698 (moved)
added to schedule label
I just migrated a lot of cards from trello, just to find that re-ordering does not work :-(. To me this was such a basic feature I did not even bother to check if it was possible. This issue is related but probably misplaced: https://gitlab.com/gitlab-com/support-forum/issues/1205.
8.14 was released more than a month ago without this feature.
8.15 was released about two weeks ago without this feature.
8.16 planned to be release in about two weeks and looks like this feature is not planned to be included in it.
Looks like dev/products doesn't care about it.
Even though it 6th most popular issue in the tracker.
Even though it was open 4 month ago.
Even though, it looks more like a major bug, than a feature proposal.Edited by username-removed-233072
@SlavikCA That is disappointing. I am sure there is a lot going on behind the scenes that the team is concerned with although an issue tracker without ordering is nearly useless, even with how fully featured Gitlab is.
I agree that this should be a high priority feature. We've started using boards for a very simple project, but once we have more than 5 things in To Do this is going to become a problem.
Boards here are a nice-to-have, so we don't have to use a separate tool, but I expect most people would not be able to use the boards here without this feature.
Makes me think GitLab is not dogfooding this by using it for product management. Telling a Product Owner he/she can track stories but not priorities would be a sure way to get this to the top of their list. ;)
Thank you all for the feedback.
Issue boards is a priority for GitLab, and in particular for the general area of Discussion, which you can learn more about here: https://gitlab.com/gitlab-org/gitlab-ce/issues/24688. As always, we can't promise strict deadlines for particular issues as we plan month to month and balance many initiatives in developing GitLab. But I can at least say within the smaller realm of Discussion, this is a high priority.
As for this particular issue, re-ordering is definitely important. There are some fundamental impacts to how we architect issue boards with re-ordering. So we want to make sure to get it right. In particular, here are our high-priority features for issue boards. https://gitlab.com/gitlab-org/gitlab-ce/issues/25698
-
@victorwu Thanks for the info. I like how open your dev process is.
I can see how the few issues above this one are high priority as well.
Keep the feedback coming @espnnewberry. GitLab values our community, and is crucial to how we develop the product. In fact it is part of our strategy, where we believe everyone can contribute. And that includes everything from code contributions to thumbs-upping/downing issues to critical and thoughtful feedback on features. Transparency is one of our values and again makes us stronger overall.
mentioned in issue #26796 (closed)
I'd like to help clarify this ticket. The core issue is that the description is incorrectly written and the ticket is incorrectly labeled.
Typically, teams use the presented order in a board list (sometimes called column) to imply prioritization.
This statement should be rewritten to be true:
Teams use the presented order in a board list (sometimes called column) to set prioritization.
Kanban board lists don't imply prioritization, they ARE prioritized top to bottom. That's how every implementation of Kanban that is available on the web works (Trello, Sprint.ly, Atlassian, etc.) because that is how Kanban works. It mimics the real world where you have cards on a physical wall. That's what this board is supposed to be: A digital version of a real-world, tangible thing you can touch.
That the board doesn't work this way is a bug, not a feature proposal or an enhancement. The current board is pretending to be something it's not and it's broken because of it. When you refresh the page and the tickets change order is a bug.
@gitlab Engineers: I want you to think about this when you're deciding how to prioritize things.
Imagine you had a Kanban board in your conference room that you relied on for setting priorities for the week.
Now imagine that every time you walked out of the room, somebody went in and rearranged all the cards.
You go grab a coffee and come back and everything's been moved. You go to lunch and come back and everything's been moved. You go to the bathroom and come back and everything's been moved.
I want you to really imagine that. Close your eyes and think about that happening in the real world.
Now imagine you find out that it's some employee who thinks that it's funny to mess with you and your whole team by doing that.
Imagine that you asked him to stop it but he didn't stop it because he didn't think it was that big of a deal.
Imagine that you told your boss, the only person who could help you, and he said "Yeah, I think it's important to have him stop and I'll be sure to talk to him about it soon."
Imagine that weeks go by and your boss still hasn't talked to him. And every day this guy goes into the conference room and moves your cards around and there's nothing you can do about it.
That is EXACTLY what is going on right now by this not being fixed for six months.
How long would you stay at that company?
Edited by username-removed-896769@stevensacks nice write-up. I concur completely; this is completely mislabeled as a feature proposal. It's a bug report and isn't receiving proper attention or prioritization.
To me this was such a basic feature I did not even bother to check if it was possible.
Please change the behavior. It's unusable for Scrum and Kanban.
Exactly.
Stop calling it a "feature proposal" because that implies that it isn't broken and thus you can deprioritize it.
It is a bug. It is broken. In essence, you are misrepresenting your feature set at best, and lying to your customers at worst.
I'm going to tell you a short story and I'll bet you that it is not unique.
We chose to move to Gitlab because we were seeking to reduce the number of tools we were using. We saw that you had a Kanban board feature that was fully integrated with the issue system which was integrated with the repository. So, we made the switch from Github+Pivotal to Gitlab and migrated all our tickets over by hand one at a time (since there isn't a migration tool for importing them).
Imagine our unhappy surprise when we found out after all that time consuming work setting things up that your kanban board was not only broken but you don't believe it's broken and thus aren't prioritizing fixing it.
Yeah, that's where we're at. So don't insult us any further by saying it's a feature enhancement and it will be worked on "someday". You are scamming people. Stop it.
Maybe you don't like that I'm being so blunt. I don't like that you're not taking this seriously. Do you expect me to recommend your product to other people when you're clearly misrepresenting your product? How about the flip side of that - do you expect me to not tell other people not to use your product because you have lied about a core feature and for six months you haven't done anything about it?
Take the first step towards showing us that you're taking this seriously and label this ticket as a bug. Then take the second step and prioritize fixing it.
Edited by username-removed-896769This post written by your VP of product is from last August: https://about.gitlab.com/2016/08/22/gitlab-8-11-released/
Issue Board GitLab Issues are very flexible. You can crosslink them, prioritize them, and rank them by popularity.
This is a quote from an interview with your VP of product right after 8.11: http://www.softwareadvice.com/resources/new-gitlab-project-management-feature/
“People typically use Trello or Asana for this. And [users] have been asking us to integrate this with GitLab so they can work in the same kind of way as they are used to with these other types of platforms.”
Well, we can't work in the same way because your board doesn't do the most basic thing a kanban board does which is prioritize from top to bottom. That's the core feature of kanban. That's the core feature of those other products which your VP said we could replace with yours.
It's been 6 months since you released this feature and made promises to your customers about how this feature works and it still doesn't work that way.
So either this isn't a bug because the board was not intended to work like Trello or Asana, and thus Job Van Der Voort is a liar, or this is a bug and you're not marking it as such and thus Victor Wu (or whoever is in charge of labeling issues at Gitlab) is a liar.
I'm taking a stern tone with you because you are literally costing companies (including ours) time and money by scamming them and it's not ok.
Edited by username-removed-896769From the discussions here and on some related issues it seems like there are some architectural decisions to make about how this should work (IIRC (it's been a while since I dug into it) at least partly around how the swimlanes are implemented with labels).
Given that I wouldn't want to try to pick up this issue on the CE repo because any work I might do would be just as likely to be thrown out as to be merged.
We built Issue boards as a workflow tool, giving you a more visual way of working with issues. We never intend to replace other software one on one from the outset, rather we build tools that we think make sense in an iterative way, adding features over time. We always shy away from adding unnecessary complexity both in how things work user-facing and in code.
For issue boards, these constraints lead us to implement a very simple way of showing and viewing issues. This has many advantages, such as a quick introduction, no need for manual adding of issues and easy filtering. The downside was that features such as reordering were not available from the outset and would require additional iterations. It's clear that people are interested in reordering, and it has always been our plan to add this, but the required changes to issue boards cost time to build.
The required changes for us to be able to work on reordering are planned for 8.17, meaning shortly after we'll be working on reordering (the list in this issue is prioritized), which should then ship in one of the subsequent releases, possibly as early as March 22nd with GitLab 9.0.
We want to make building, deploying software really easy, which means we have to cover a wide space of tools within GitLab and spread our attention carefully. I'm happy to see people excited with the potential to even frustrated with a lack of a particular feature. If you're interested in seeing a particular feature expedited, you're always welcome to contribute to GitLab. Leave a comment in the relevant issue and we'll have engineers work together with you.
@stevensacks It's unfortunate to hear the lack of functionality put you and your colleagues in a tricky situation. I hope the above inspires some more confidence. I'm happy to discuss this further.
mentioned in issue #27506 (closed)
@smcgivern : This is high priority, and we want to schedule it very soon.
I understand that sorting per board would be rather involved technically. How about just maintaining a sort order that's universal given any two issues? Given issue X and issue Y, there's only three possibilities:
-
X and Y have no relative order.
-
X comes before Y
-
Y comes before X
In any board in GitLab, if these two issues occur in the same list in that board, that order is maintained. So if one person makes a change in one board, and the same two issues occur in a list in another board, that other board's list view will also automatically be updated.
This doesn't cover all use cases. But if this is the simplest technical solution, it will definitely cover many use cases already. Feasible?
Edited by Victor Wu-
POC based on https://gitlab.com/gitlab-org/gitlab-ce/issues/21264#note_22464646 is in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8916. It basically just needs tests. I invite anyone to pick it up and finish it, because I likely won't have time to do so for 8.17 or 9.0 :)
added Deliverable frontend and removed to schedule labels
changed milestone to %9.0
mentioned in merge request !8916 (merged)
-
@victorwu : This is a brilliant solution in my opinion. We need to think about how to handle this situation though (which will happen very often): if X comes before Y, and I now have an new issue K which comes before Y but after X, what happens? How do we address this case?
@cluxter : We already have a WIP merge request for this. Feel free to take a look and provide any feedback! I think it should answer your question.
assigned to @vsizov
While looking into a support ticket (https://gitlab.zendesk.com/agent/tickets/65075), I noticed that the custom issue ordering within a list is not persisted and resets on refresh.
/cc @kushalpandya
Thanks for the feedback @athar . This feature is under development, and we are planning to release it for 9.0. So it is not yet available.
mentioned in issue #18576 (closed)
closed via merge request !8916 (merged)
@DouweM do I get it right that it will be possible to reorder issues on /project/issues and on project/boards ?
@mrgrauel Only in issue boards
@jspengeman it will be released in 9.0
mentioned in issue #29416 (closed)
mentioned in merge request !9939 (merged)
mentioned in issue #29862 (closed)
mentioned in issue #30110 (moved)
-
@ben_unearthed I've just tested sorting. Everything is working properly.
If you still face a bug, could you open a new issue with a problem description and steps of how to reproduce the problem, please?
It's here on gitlab.com but I don't want to make a video of our board public. Not sure if there are private support tickets for enterprise edition starter users or whether someone wants to message me directly and I can send them a private video.
I'm not doing anything more than, dragging to re-order a few issues in the backlog column of a board, refreshing the page and they're all scrambled. The issues do have weights assigned but i'm not expecting that to impact the order.
@ben_unearthed if you are a GitLab customer, you can create a support ticket by following the steps at https://about.gitlab.com/support/.
Alternatively, please do as @blackst0ne suggests and open a new issue, but make it confidential.
I'm experiencing that currently on gitlab.com, the issues in a milestone board are not draggable, and the issues are sorted by issue number. I recall reordering by dragging was possible a few weeks ago. Was there a regression in one of the recent releases?
Details:
- URL of the form
https://gitlab.com/curran/my-project/milestones/3(same page as with burndown chart) - free plan
- Chrome
Edited by username-removed-219974- URL of the form
mentioned in issue #30713 (moved)
mentioned in issue gitlab#7447
mentioned in issue gitlab#8985
