Add nodal.org

README.md

@@ -16,15 +16,22 @@ For that, a task management system needs to enable these three actions:
 - planning & reviewing
 - retrieving tasks that should be done and can be done in the current context
 
+My problem is that I don't trust any of the systems I am currently using:
+- head: I forget things, short-term memory limited
+- paper: many slips flying around, can get lost easily
+- CLIs: too verbose to use, didn't get me the information I needed in time
+- web: too many clicks, too slow, not available offline, often unflexible
+
 # Design
 
 The most important rule: Everything is a task. There is nothing else.
 
 Projects, Areas, Epics - they can all be mapped onto tasks, and doing so will allow you to leverage the same toolset on everything.
 A project or epic is a completable task with subtasks - it can itself be a subtask.  
-If you want to divide your task list into areas, these can simply be uncompletable tasks at the root level.
+To divide your task list into areas, simply put everything under uncompletable (see task type activity) root tasks.
 
-With everything being a task, areas and projects can also have all kinds of tags and attributes. And then subtasks may inherit these attributes (particularly tags).
+With everything being a task, areas and projects can also have all kinds of tags and attributes.
+And then subtasks may inherit these attributes (particularly tags).
 
 More fundamentals:
 - UNIX philosophy: use plain text is possible, separate into independent modules
@@ -82,5 +89,21 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
 # Links
 
 [taskwarrior]: https://taskwarrior.org/  
-https://tasklite.org/related.html  
+
-https://www.wired.com/2016/03/best-to-do-list-app/
+## Discussions
+- https://kolaente.dev/vikunja/api/issues/1198: 
+  Thoughts on Vikunja, my new hope.
+- https://github.com/lyz-code/pydo/issues/73: 
+  Short discussion on a beta-level tool with convenient short ids.
+- https://www.wired.com/2016/03/best-to-do-list-app/: 
+  Maybe Technology won't help, after all...
+
+## Projects
+- https://codeberg.org/equilibrium/equilibrium: 
+  A Haskell project I started to link task managers,
+  unfortunately abandoned by now.
+- https://tasklite.org/related.html: 
+  List of CLI-oriented productivity systems  
+  Should have a look at:
+  - org mode (agenda)
+  - taskell

concepts.md

@@ -0,0 +1,14 @@
+All task managers I have seen so far were quite opinionated. Since task management is a deeply personal matter, this likely yields many people to abandon these digital tools not long after embracing them.
+To build trust in the system, it needs to be your system.
+
+So the foundational principle of this task manager is to rely as little as possible on special mechanics, implementing all convenience behavior and specialized features in a generalized way, allowing to easily compose and customize them.
+
+One only really needs key-value properties and tags (valueless properties) which can be assigned to tasks,
+all other structures which humans might want can be derived from these in the frontend.
+
+Then one can define views/lists/filters using key-value and tag queries:
+```
+[view]
+	big=size:l
+	break=size:s -pc
+```

ids.md

@@ -0,0 +1,51 @@
+# User-Ids
+
+One important concept is to identify tasks effortlessly with recognizable, consistent alphabetical ids.
+To distinguish them clearly from the unique ids (uuid/ulid) and potential ids of the plumber, they will henceforth be called user-ids.
+
+These ids are always lowercase.
+Note that they only have to unique among open tasks. Closed tasks loose their userid and will have a new one generated should they be reactivated.
+
+1. Generate an index of the task description: An array of all uppercase letters and initials.
+2. If there is a parent task with a user-id, take its first letter as start of the id. Remove the first letter of the index if it is identical.
+3. Find consecutive letters (preferably among the uppercase letters) in the index that yield a unique id with a length of 2-3.
+4. Take up to 3 letters of the description and see if they create a unique id.
+5. Otherwise, find a random combination of 2-3 characters that isn't used yet.
+
+Example:
+
+    Configure my ArchLinux properly
+
+Index:
+
+    CmALp
+
+Generated ids, in order:
+
+    ca
+    al
+    cal
+    
+    cm
+    ma
+    lp
+    cma
+    mal
+    alp
+
+    co
+    con
+
+If there is a parent with the id `c`:
+
+    ca
+    cl
+    cal
+    
+    cm
+    cp
+
+    co
+    con
+
+Taskwarrior UDA: userid

nodal.org

@@ -0,0 +1,230 @@
+#+title: Nodal
+* Nodal - A new Paradigm for Project and Knowledge Management
+** Abstract
+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.
+# to do their best
+# This paper outlines
+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.
+** Paradigms
+*** Two Current Approaches
+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 [[id:valueflows][Valueflows]],
+implemented in software solutions such as [[id:bonfire][Bonfire]]
+based on [[id:fediverse][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.
+*** The Task Tree
+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:
+1. Under the hood, files and directories are both the same - extensions of the basic "inode".
+2. There is a single root to all files accessible on the system ("/").
+3. Externally shared files, be it from network shares or physical devices,
+   can be mounted into any path of the system.
+4. 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:
+**** 1. Everything is a Node
+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.
+# Missing good comparison which emphasizes general production with customization by 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.
+***** Saving the world
+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
+# can be held structured(ly?)
+and results preserved with their decision process.
+**** 2. I am (G)Root
+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!
+**** 3. Sharing and Mounting
+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.
+# Google Drive, Nextcloud
+**** 4. Polynomial Relationships
+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.
+** Ideas
+# Plantuml wireframes
+
+Labels as Properties
+-> dynamic interface
+
+https://kolaente.dev/vikunja/frontend/issues/537#issuecomment-39747
+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
+
+# Application Lifecycle Management (ALM)
+*** Copied Write-Ups
+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...

plans.md

@@ -33,7 +33,7 @@ Maybe prefix internal values (ulid and state) with underscore. Does no interpret
 
 ## The task manager - [porcelain][plumbing]
 
-Name ideas: Taskforc/Tofo
+Name ideas: Taskforc/Tafo
 
 Basically a parser & visualizer with a few quirks.
 
@@ -41,15 +41,15 @@ Unknown commands are passed on to the plumber with potential parameter modificat
 
 Reports & parameter configurations should support some kind of inheritance, i.e. allowing to create a new property/report that initially uses all values from its ancestor.
 
-Automatically generates short ids for new tasks based on description - first initials, then following letters in case of collisions (e.g. "al" for "Arch Linux setup"), length may depend on whether there is a parent (root tasks get single letter if possible) unless an id is explicitly set.
+Automatically generates short user-ids for new tasks based on description - first initials, then following letters in case of collisions (e.g. "al" for "Arch Linux setup"), length may depend on whether there is a parent (root tasks get single letter if possible) unless a user-id is explicitly set.
 
 ### Commands
 
 Most commands are specified in a default config file, and even most standard commands are aliases:
-- _delete_=modify status:delete
+- _delete_=modify status:deleted
 - _do_/_done_=modify status:done
 - _log_=add status:done
-- _addx_=add status:incompletable  
+- _addx_=add status:frozen
   name tbd; this is an important concept: such tasks cannot be completed, so they can denote categories (e.g. home, work) or activities (e.g. play piano, go outside) which can turn a task manager into a time manager
 
 This allows the user to define and redefine the commands without any programming. It provides insights into existing inner workings and makes sure that internals are accessible for power use.
@@ -67,21 +67,46 @@ These commands need to be hardcoded, they can't be specified as simple aliases:
 
 The parameters for commands are pre-parsed separately, which allows custom simplified syntax. A separate config file specifies the properties with allowed values and potential shorthands, e.g.
 ```
-scheduled.name=Scheduled
+[property]
-scheduled.label=Sched.
+	scheduled.name=Scheduled
-scheduled.type=date
+	scheduled.label=Sched.
-scheduled.shorthand=sch
+	scheduled.type=date
+	sched=scheduled
+
+	size.name=Size
+	size.values=-,s,m,l
+	s=size
+
+[tag]
+	big=size:l
 
-size.name=Size
-size.values=-,s,m,l
-size.shorthand=s
 ```
 
-- **name** is for display in detailed info
+- **name** is for display in detailed info (Default: property identifier with first letter uppercased)
 - **label** is used as column header for reports - default: _name_
 - **type** is used to potentially parse and translate the value - default: text (e.g. a date type will transform "5:00" to add the current date or even translate it to a timestamp - maybe even use the `date` command here?)
 - **values** can define allowed values
-- **shorthand** can specify an alternative way to specify this property on the commandline, e.g. when adding a new task
+
+### Recurrence
+
+State values: waiting, open, frozen, repeat, done, deleted (could partially be implemented with tags?)
+
+It is hard to get repeating tasks right. Every task manager I have seen so far implements it differently, and most task managers lack support for different use-cases.
+
+So instead of a rigorous system, I want it to be flexible. Every property with the date type will use recurrence, as long as the state of the task is set to `repeat` and the value of the property is set relatively (e.g. `2d` rather than `2020-08-24`). For that to work, the input needs to work a bit differently from the output: The date value that is displayed in reports and the like is always absolute, so it needs an internal, calculated value, while the original value has to be retained even if a task is not repeating, since it might later be set to repeat.  
+As in Todoist, appending a bang to the relative value will make the recur relative to the creation of the task, rather than the previous value of this property.
+
+The task managers I have seen so far assign some kind of common id to all instances of recurring tasks. I don't really see the point here - why not simply update the values of the current task rather than marking it done and creating a new one? The case where I want to modify a single occurrence in an incompatible way seems really rare.  
+Let's take the case of a weekly event that is moved by an hour once. It would be defined like this:
+
+	sched!moT18 due!moT18
+
+If `scheduled` and `due` are equal, the item is treated as an appointment. The `T` in between separates date and time. `state:repeat` is implied by the bangs inbetween, unless you explicitly instantiate it as frozen.  
+I can now modify this task once:
+
+	due:T19
+
+Which only updates the date of this occurrence. No need for multiple instances.
 
 ### Reports