Current Project Management tools do neither adequately represent the complexities of modern development cycles nor leverage the power of modern processors and paradigms to empower humans for effectiveness.
This is why I want to outline a new Wholesome Application Lifecycle Management approach where all data is captured in a single source of truth and can be viewed and edited from the preferred perspective of each user.
Recently we have heard horror stories of businesses investing millions to integrate renowned software solutions yet achieving nothing but frustration. It is time to liberate our minds. We need the Power of Atlassian with the Flexibility of Notion and the Freedom of Open Source.
I see two basic approaches shaping up, which may be integrated: Tasks as communication, and tasks as notes.
The former is often inadequately attempted in chat tools people already use - team chat such as Zulip or Slack, or instant messengers - where action items quickly get lost. A more thought-out appraoch is Valueflows, implemented in software solutions such as Bonfire based on ActivityPub as communication.
The latter can be seen in “One Big Text File” (OBTF), the idea of tracking everything relevant to oneself at the current time such as todos and notes in a single plain text file, often combined with powerful editors and command-line tools. There are also more user-friendly tools, Notion and Org-Mode being prime examples: Both allow outlining of hierarchies which contain notes and tasks interchangeably.
I want to focus on the latter approach, but rethink it from the ground up. For that, I deem a typical linux filesystem a useful metaphor:
- Under the hood, files and directories are both the same - extensions of the basic “inode”.
- There is a single root to all files accessible on the system (“/”).
- Externally shared files, be it from network shares or physical devices, can be mounted into any path of the system.
- A file can be made accessible from multiple locations through either a link or a bind mount.
Let me elaborate how each of these points applies to Task and Project Management:
Humans have come up with all kinds of classifications and categorizations and structures for tasks: Namespaces, lists, projects, epics, stories and so on.
While these might be useful in a specific context, project, or maybe just to a specific person, a good tool should be agnostic to these, accepting the imprint of the user.
Just like a good knive can be sharpened to the delight of its user. Just like an axe is not specialized on the type of tree it may cut.
So what is the basic building block in project management? For a long time, I assumed it was the task, distinguishing between completable and non-completable tasks, the latter forming something akin to namespaces and lists. But recently I have come to realize that tasks do not become irrelevant at completion - quite the opposite, fruitful work produces valuable task discussions and descriptions which deserve to be preserved as a kind of wiki or FAQ, a knowledge base.
To achieve this, we need to lift our focus off of the structure we have learned tasks have: Title, state, description, tags, further attributes and potentially discussions. If instead knowledge is the basic building block, Everything is a node: The title, the description, the discussion thread. A node is merely a string, potentially with attributes, unveiling its potential only when linked to others.
Let us look at an example: In our Project “Save the World” we want to “Make a Plan” and then “Execute the Plan”. Each of these three points is in itself a node, with the latter two subnodes of the first. These should also have a state attribute which can be modified along the way, unlike the project, which, contrary to our hopes, is not something that is ever complete, so there is no point in tracking completion (more mundane examples would be “Personal Development” or “Practice Music”, nodes that represent areas of life rather than concrete actions).
For the first action item, we can create a subnode, which at first might be a simple outline and then change into a full-fledged plan. As this is textual content that changes with time, it should be version-controlled and available for real-time collaboration. Now when viewing the parent node, the interface might display the root node atop, below it our project, then centrally the task we are viewing with its attributes and below that the content of its immediate children or whatever number of layers is deemed sensible.
In the execution, it is likely that queries and discussions come up. Each of these should be created as a completable subnode naming the topic, with further subnodes for the actual discussion. This way arguments can be dissected in an organized fashion
and results preserved with their decision process.
With nodes and their relations as foundation, especially parent-child, we need to consider how to make these accessible. Simply put, all nodes that do not have another parent will be parented by the root node, which is your user profile. Now that’s interesting, huh? I am also a node? Exactly!
Thinking of the structure, we will want to store these nodes in a graph database. Now, sharing a node to another user under the hood just means connecting it to their user profile.
Then this user can decide whether to move the node into a different position within their tree, just like a shared folder in common cloud file storage solutions.
Since we have already established the graph database, we can leverage its full power to do something unconventional: Give a task multiple parents.
Of course we already kinda do this when we share a task to another user, but here I am referring to your own hierarchy. Quite often hierarchies are not so clear, something we painfully experienced in our business use of Zulip, which requires you to decide the receipients of a message by posting it into a stream.
Plantuml wireframes
Application Lifecycle Management (ALM)
Labels as Properties -> dynamic interface
Kanban config options:
- group by: assignee, property (label group, status, …), date, parent task
- display levels: 1-X (range), only leaves
- display text levels: 1(self)-X
- ordering direction/sorting
See also https://kolaente.dev/vikunja/frontend/issues/537#issuecomment-39747
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…