Swimlane concept in burndown reflects statuses and not swimlanes

Makes sense. That would be a huge change in terms of code diff. I think this would be a major version thing.

I'd love to see Burndown have a standard swimlane definition, but at the least it seems like the current concept should be renamed to "Status" or something.

If I understand correctly, this request is to align with a practice is already widespread among "users of project management" (thanks to jira), so consider adopting it...

Conceptually, "swimlanes" can be arranged horizontal or vertical. So, I wonder if this could be solved by a simple "string override" (https://www.drupal.org/project/stringoverrides), instead?

If needed, both me and the Ubertus.org team would be happy to contribute testing and documentation for this new/updated Swimlines feature. Any volunteer for a patch?

For those not familiar with the consensus about Kanban Swimlines, this animation shows 3 Swimlines. Which can be expended or collapsed to see the Swimline(s) of interest.

Swimlines are horizontal lanes on your Kanban board.

For larger teams organization, Swimlines are often needed to manage, on one Kanban board, several simultaneous products, projects, or cross-team dependencies. As well as distinguish tasks of different, teams, groups, people, categories, such as workstreams, users, application areas, or anything else to your liking.

For smaller teams organization, Swimlines are often used for one row per person. This facilitates instant visibility into various team members' present workload.

More screenshots and attribution at https://kanbantool.com/support/kanban-board/what-are-swimlanes or at https://archive.ph/SGPMR

Same here. When I started learning about Swimlines, at first, I believe that they were vertical lines/columns. Then someone educated me that the consensus on Swimlines is that they are actully horizontal lines/rows.

For those interested to discuss or contribute a patch for this Swimlines feature, this Jira configuration documentation might be of interest at https://support.atlassian.com/jira-software-cloud/docs/configure-swimlanes/ or at https://archive.ph/ySgzG

Video Taiga Swimlines

During the last years, I tried various products which have a Swimlines feature. The easiest to use, most flexible, the best visual design, and also the most powerful that I know of is this https://www.taiga.io Swimlines. Which Pablo demonstrates in this video starting at 30 minutes at https://youtu.be/2st6u7F6S3E?t=1803

Like both Burndown and Drupal, Taiga code is Libre Source (Open Source). Maybe some of its code could be recycled for Burndown? A significant part of Taiga code and libraries are written in JavaScript, HTML, and Python:

• https://github.com/kaleidos-ventures/taiga-back
• https://github.com/kaleidos-ventures/taiga-front-next
• https://github.com/kaleidos-ventures/taiga-front

Try Taiga Swimlines for free at https://tree.taiga.io/register

Here's roughly what would need doing:

* At a data structure level, I had anticipated extending the "swimlanes" to cover both horizontal and vertical rows/columns. The swimlane entity would need to be expanded to work like a 2 dimensional matrix. That includes the settings forms to manage them.

* There'd need to be an additional field (at least) on the task to track where it is at. We'd need to figure out business logic for what to do if the underlying swimlanes are modified (i.e. where do the tasks get moved to) etc.

* Then there's going to need to be fairly large code changes to the various APIs that make things work. Some of that functionality is complex.

* We need to work out how the logic of items moving between swimlanes would work. Probably settings for whether items can skip between them when dragging at the UI, or whether we want other business logic to track that.

* Lastly, some complex js work on the front end. The built in js library for drag and drop doesn't do a good job of handling restrictions on where things can be dragged to, so there will need to be a bunch of custom handlers, and my experience is that that gets messy quickly.

I'm not up to this at the moment: I suspect it's going to be a month or so of full time work for somebody to implement (it took 2 months full time during lockdown to write the module in the first place). Happy to provide emotional support if somebody else wants to tackle it.

This is a fair amount of work with even more if we wanted to maintain backward compatibility. @jeremylichtman, what are your thoughts on changing the friendly name from "Swimlane" to "Column" while leaving the underlying machine name as it is. I am not usually in favor of quick and dirty shortcuts that keep a confusing underlying infrastructure, but it could make the project more usable, even though it makes it more confusing to maintain.

I'm okay with a public name change / dirty fix in this case, if it is bothering people. Sadly, it's probably going to be a horrible job.

I really messed up with this one!

I really messed up with this one!

@jeremylichtman Don't beat yourself up. We all make the best decisions we can at the time we make them. You have a very robust module here that solves a lot of very tricky problems.

This is updated and confirmed to work.

I moved the larger lift to this issue #3606736: Add true swimlane functionality

Merged, and released on tag 1.0.62.