I have thought more about it, and I think the way to go will be to have no fixed Kanban view. Instead one should be able to create a kanban view grouped by a desired property, which might be the task status but could also be an assignee or the like, like in Notion.
Either way, there should be a way to add more task status options through which a task can be moved with one click as outlined above.
That whole document might hold some interesting points for you, but let me mention my current use-cases:
I add a tag to all tasks in a list. Rather than tasks, it might make more sense to have lists be tags, and the lists are simply predefined views. This allows for more flexibility when juggling many lists.
I am now creating a kanban board that essentially lists all lists and provides some details and status information about them. If lists were tasks, I could add them there directly, avoiding redundant descriptions and providing easier back and forth navigation.
In the end, I don't see why lists have to be a separate entity, just as checklists. It is adding complexity and creating artificial restrictions at the same time, for no gain.
And the UI can still stay mostly as it is, but rather than imposing, what it shows you are merely sane defaults to be changed at your mercy.
It is a simplification in the backend that brings great flexibility for the future.
To bring both points together: Namespaces could be tags, Lists could be Root Tasks and belong to multiple namespaces with tags.
Then one could even simplify sharing, because by adding a tag to a person (plus a RO/RW/Admin value) you can share them all tasks belonging to that tag, no need for different scopes like namespaces/lists.
Only public sharing links need to be extra, which can be created for any view of any task - you could create Kanban or Gantt views for subtasks (epics) of a root task (project) and share them, because every task can be turned into its own view.
Welcome to Productivity and Management Utopia.
Let me lay out my ideal structure and current workarounds,
illustrating the superiority of this approach:
With everyone in the core team of our company
I want to share an uncompletable root task (“namespace”).
This task has a subtask for each project (“list”),
which might be shared with additional collaborators.
These projects can themselves be displayed on a Kanban board
(currently we have a separate list for that, linking to each project)
showing the status of the project (e.g. Ideation, Planning, Active, Completed) and providing a grand overview.
For each project, subtasks might contain areas (e.g. UX, Backend, Frontend)
or epics (user login, …) or for small projects straight individual tasks.
If it represents an area, it might be shared with a dedicated team for that area
with its own views.
Just to clarify why I am so adamant about this:
We discovered Vikunja in our unhappiness with existing project and task management software, as we need a tool with a single source of truth but many views/facets - for planners, stakeholders, designers, scrum managers, controllers, developers, QA, leadership...
We look at Vikunja and see not just a nice task manager, but the possibility to disrupt the whole torpid market of modeling development processes digitally, displacing the annoying proprietary giants like Atlassian and narrow-minded tools like Wekan while also offering everything that is nice for personal use, like Todoist, and adding unprecedented integration with other tools such as Gitea, Wikis & co.
Once the resources are there we will implement this vision through open-source, and we would be happy for Vikunja to be its foundation and its developers part of the team :)
However, I have also thought about the architecture and we might actually need to redo the data models at that point, to use a graph database like ArangoDB - that way everything is not just a task but a node, which can be tagged through edges/connections. Anyways, I'll leave that for my soon-to-come blog entry...