Reorganize issue description list items with drag and drop

LOVE. I recently experienced the visual challenges of a long task list.

Maybe a method of 'completion sorting' that attempts to maintain the original order?

Excellent feature. Also, please do the same for Wiki pages. The task list functionality in Wiki will be very helpful.

It seems GH doesn't handle sub-tasks. I imagine it could be a performance challenge but also achievable. Do we want?

Haven't tried it with massive lists but doesn't seem as bad as I thought...

Would we want to mirror these changes in the markdown for persistence if the user has the permission to edit the markdown?

What about for users that do not have permission to edit, should there be a client-side/per-user persistence?

@lbennett The onboarding checklist might be a good real-world test case for a larger task list.

Excellent choice.

Works fine.

Vert nice. Would also be great if the checkboxes were larger. Currently, it's hard for us with less than perfect vision to click on those.

@lbennett

My respect for jQuery has really shot up the past year!

Would anyone like to suggest a different implementation? I'm sure @connorshea wants to talk about jQuery UI.

@lbennett depends on how much it adds, may not be much since we already have jQuery UI. Open an MR :D

We have parts of jQuery UI. Don't go nuts.

@demisxbar That's totally valid but probably not completely related to this issue. If you open a new issue and ping me on it I'll make sure it gets the gitlab-ce~2677490 label.

@rspeicher Done: gitlab-ce#18052

It seems we already use the sortable plugin. Great news for gitlab-ce#17907 too.

@lbennett Obviously awesome! Can you reference you new MR that this in and link to this issue? I want to see this gold you have created

@jschatz1 I will do that shortly. :) Ahaha the gold has to be awarded to jQuery for doing this in 1 line.

@connorshea How soon until you'll find a way to ditch most of jQuery UI? If its soon I'd much rather push this through with a light-weight sortable lib.

@lbennett not on my radar as of yet :)

@connorshea I'll sneak it in.

If Jquery-UI is too dependency heavy you can use http://rubaxa.github.io/Sortable/ ?

Any updates here?

So the GitLab/GitHub comparison page links to this issue. any update?

In order to get this request some attention, this issue has been marked as a potentially interesting proposal as it meets the following criteria:

Labelled as a feature proposal
More than 10 upvotes
Unscheduled (not associated with a milestone)

Thanks for your proposal!

/cc @markglenfletcher

It's been almost 3 years since opening this issue. As @systo pointed out, it's referenced on the comparison page here: https://about.gitlab.com/devops-tools/github-vs-gitlab.html "GitLab does not have this ability, but is considering implementing it."

I'd say that 1+ years without any real discussion on the issue brings it outside the realm of active consideration....

changed milestone to %Backlog

added [deprecated] Accepting merge requests label

added devopsplan label

added groupproject management label

changed milestone to %Backlog

changed the description

added sectiondev label

added severity3 label

@digitalmoksha moving the conversation from https://gitlab.com/gitlab-org/plan/-/issues/449#note_731325044 to here so we can find it later

I think ordering in the "task widget" is different from ordering a markdown list, that could contain both links to tasks, other issues, or simply a shopping list. Drag ordering of regular lists is still quite useful, particularly if you don't want the overhead of "Tasks"

Ok this makes sense. Then my next question would be how we handle dragging/reordering in these cases:

Case 1 - Mixed list type:

- [ ] Task
- Unordered list item
- [ ] Task

Case 2 - Non-task list types:

1. Ordered list 
1. Second item in ordered list
1. Third item

- Unordered list
- Second item
- Third item

There is some interesting conversation around task lists in markdown here -- https://github.com/github/feedback/discussions/4261#discussioncomment-1168423

@gweaver I don't think it makes any difference what "type" the list item is - it doesn't matter if it has a checkbox, or is a "task", or just a plain list item. Each one would show a drag handle when hovering over it, and the drag handle allows you to move the item up and down that specific list - you can't drag an item from one list to another, at least not initially.

There is some interesting conversation around task lists in markdown here -- https://github.com/github/feedback/discussions/4261#discussioncomment-1168423

That really is interesting, but I think it's more relevant to &7110 (closed).

mentioned in epic &7110 (closed)

added workflowdesign label

added Stretch label

@hollyreynolds can you please add a design for this? Thank you!

@donaldcook @jlear can you please put a weight on this? Thank you!

@gweaver I think we can accomplish this completely on the frontend. I would like to get input from the team though. Did you want this weighed for %14.6 or we okay with adding Next Up and having it weighed in the next cycle?

@donaldcook I'd like to get it weighed for this cycle if possible. If it's frontend only, how do we store the order of the tasks? Just update the description?

Just update the description?

@gweaver That's what I was thinking until we actually convert them to work item tasks.

I'm in favor of doing it this way.

Maybe also time to update https://about.gitlab.com/devops-tools/github-vs-gitlab/decision-kit/'s Drag and Drop Tasks reference to directly link here. It's currently still linked to gitlab-foss#18003 (moved) (with a hard to miss for new users "moved" link at the top)

Great to see this moving again as this feels like one of those QoL features gitlab is all about ;)

@gweaver Just to note it here as well, based on this conversation we've decided to hold off on pursuing this at this time in light of the impact it could have on the work groupproduct planning is doing.

@hollyreynolds I do not think it would impact any of the work they are doing given the order in the description is not at all connected to anything else -- anywhere in the product. I really wish we had this right now -- especially for managing my own weekly priorities issue (https://gitlab.com/gitlab-org/plan/-/issues/512), where I have to edit + copy/paste everything it shifts from one week to the next.

I'm in favor of moving forward with this.