Basically it’s my own little URI naming scheme. So anything can (and in theory should) have a relation to a tree of “projects”. A project can be very broadly defined as a temporary or permanent subsystem (a system here is very generally thought of as a structured whole and a subsystem therefore would be a self-contained system within that whole. The whole here is the tree of my projects. It is strongly related to my life and is a structured articulation of my world).
Alright. With that said the goal of the tree structure is to relate, in a context appropriate way, all the things back to this tree structure:
- in taskwarrior, the project field is an obvious choice for codifying a place in my tree
- in my notes app of choice, TiddlyWiki, the tags field makes the most sense
- in the file system naming the folders according to the scheme is the way to go
- and so on…
So how does the scheme look? Here are two fictional examples:
07-work.2-chatbot.1-research.1-machine-learning
07-work.2-chatbot.1-research.2-react-hooks
- projects and subprojects are divided by a dot (or an appropriate substitution within the context, e.g. in the file system it would be folders and subfolders so in the terminal it’d be a slash)
- root-projects start with a two digit number followed by a hyphen and a short descriptor of the project
- subprojects follow the rules of the root-projects, but add two digit numbers only when needed
The growth of the tree according to this scheme is governed by a small list of rules:
- branch out deep rather than wide
- if a new subproject could branch out from two equally plausible points, branch out from the stronger one
- branching out temporarily/in a bad way is better than not connecting things to the tree
This ever growing tree is documented inside my notes app, accompanied by a description of the naming scheme, the aforementioned rules and a changelog.
Projects (or rather their identifiers) are created as soon as a thing is understood to be related to a project not yet named (and therefore not yet connected to the tree).
Finally: A thing might in practice be related to more than just one project. That’s fine. The tree is not meant to track every possible relationship between the things it’s connecting and itself. I strive for “the best” relationship at present and in context. By utilizing cross-references (e.g. a text file in the folder structure in the file system, a note in my notes system…) a migration to a different place in the tree is possible.
I looked into it after you mentioned it! It reminds me a lot of OmniFocus actually which also allows for (in theory) unlimited branchability, a property that is mandatory for any software that’s supposed to be more than an intermediary.