Seems to work just fine on a large project (138 interdependent TODO items). So it's a starting point.
@publicvoit The thread is getting very interesting now that an Org Mode contributor chimed in.
I just learned that Org Mode is way more structured behind the scenes than I thought (my assumptions about Org Mode are probably outdated by 10 years at this point). And in particular, that org-element API is a bona-fide API that can be used to manipulate org buffers effectively, and not just for "batch" parsing and generating.
@temporal I get notified. Thank you!
I follow your updates and I'm curious how you implement your workflow. Please do consider a concise article once you've reached a satisfying status!
@publicvoit I will. Seeing your writing makes me want to properly collate my notes and publish them - the act of refining my workflow already involved creating a textual artifact documenting it, I just need to turn that into a blog post.
In the meantime, I simplified the code a bit (updated the Reddit comment as well), and wrapped it in a simple interactive function running org-map-entries on "nil" scope (i.e. "buffer, respecting restrictions"), + printing some stats to messages. Works like a charm.
@temporal I can't emphasize enough how much progress I make when writing a blog article about a new workflow or concept. The necessity of describing my requirements and concept for others in a meaningful way forces me to rethink some aspects. I have thrown away whole approaches during the write-up process because I had a better idea or I realized that it is not mature enough.
Another benefit is the documentation for my future self. This also results in very funny situations.
@publicvoit Did you reach a point in which you have trouble thinking clearly about complex problems when you can't type your thoughts?
I've been at that stage for a while now. Whether at work or privately, stream-of-though writing in an org mode buffer has become a critical part of my thinking process - I feel like my IQ is literally dropping by 10 points when I'm away from a text editor. It's a weird state of being.
My notes tend to be almost, but not quite, blog-quality, so I never publish them.
@temporal I do have moments (probably once a month or so) when I get tons of ideas after a spark of thought. Then I just need to grab a paper & write down a list of thoughts very quickly. This is mostly when I got to bed & started to think of things.
In all other cases, it's just boring sitting infront of Org/Emacs and brainstorming into list items that get turned into a concept and tasks later-on. Sometimes, I'm too bored to do so. However, when I start thinking about the project, I get hooked.
@publicvoit I have those moments of "idea overflow" too - a single thought, a thread pulled, suddenly produces so much ideas that the resulting dump is couple screens long.
But the thing I was talking about is different: that on a day-to-day basis, I find it increasingly hard to process complex ideas in my head. I need to have a writing implement at hand, to work with my thoughts. Preferably Emacs/Org Mode, but any text editor - or even analog tools - will do. But it's like my brain has no working memory.
@temporal Any complex project is planned via Org at my side. I need to break down the overall goal set to sub-projects and each project a list of tasks that consists of a verb and the task object/goal. That's the price of complexity.
@publicvoit I'm still failing to communicate what I mean.
I don't just mean complex project - I mean complex *tasks* and stressful tasks; typing and refactoring my "stream of thoughts" is what lets me explore the problem space effectively. Conversely, if I can't do that, attempts at more complex thinking make me feeling like my brain is spinning in circles.
That may be how I'm compensating for distraction that are other people. The one place where I can think clearly without writing tools is a shower.
@temporal Maybe I don't have that complex tasks. That might be the case.
Other than that: I've learned that any complex tasks needs to be split into a set of less complex sub-tasks which can be solved individually. For probably half of my long-running agenda tasks, splitting raises the chances of actually getting the thing done.
@publicvoit That's what I learned about myself too. If I can't seem to get started on a task, or feel repulsed by it, it means I need to break it down further.
Which leads to two challenges wrt. my current workflow:
1/ Splitting tasks in Org Mode is not ergonomic enough. Sure, I can make a list and then mark it, C-c * it into headings and assign TODO states, but that's already slower than I'd like - and then the real pain starts with encoding dependencies between those tasks.
@publicvoit I need to automate this, and am in process of observing myself on real project, to collect a "vocabulary of operations". Things like:
- "Spin this headline off as a project" -> create a pre-structured file with some scaffolding specific to my workflow.
- "Replace this task with these new tasks" -> this should not just replace a headline with more headlines, but also relink dependencies. Think of it as replacing a graph node with a subgraph, and linking it sensibly to larger graph.
@publicvoit Right now I'm doing such operations manually, but I hope to eventually automate them, so I can treat them as atomic, high-level operations.
2/ The other big problem: my projects now tend to have a lot of tasks in them, including lots of unblocked tasks. The worst one is at work, currently clocking 73 "NEXT" tasks (and 87 "BLOCKED"). While this correctly shows there are many real starting points, it's also overwhelming to pick a single task/area to start working. I need to filter it down.
@publicvoit The ultimate goal behind the workflow I'm developing is to separate "planning" and "execution" stages in a way that minimizes the amount of decision making needed during "execution" stage.
So, when I've scheduled myself a block of time for a particular project, I want to focus on executing tasks, while minimizing context switches - I don't want to agonize over where to start, because just considering all open tasks in the project flushes my current context down the toilet.
@publicvoit I have a bunch of ideas on how to tackle this one - how to automatically prioritize and filter tasks so, during "execution mode", I'm presented only with those that match my current generalized context - same area of thinking/mental models, same tools required, same "mental toughness"/"emotional load"/"fun factor".
But these are ideas in brewing stage, and I want to avoid making myself input too much metadata up front about tasks. I'm already spending too much time on meta-work already.
@publicvoit Addendum to the "vocabulary of operations":
I've just noticed a common operation I do: "prepend this task to this subgraph", or sometimes "prepend this whole subgraph to that subgraph".
Example from today: I broke down some work into a dozen tasks with dependency links. I then started working on first of those, only to discover there's something I haven't considered. I added a task for it, and manually made all non-blocked tasks block on this new one.
2 - 1/2
@publicvoit I also frequently append tasks in such manner - I add a "follow-up task" that blocks on the "final" tasks of a given subgraph.
In general, I see all kinds of operations that could be generalized as "splicing graphs together". In some cases, there's only one reasonable way to do it; in others, the operation may be ambiguous - so there may be a need for an interface for quickly specifying what connections should be made, and which should be omitted.
Something I'm planning to work on.
2 - 2/end.
@temporal This resonates with me.
So far, I manually squeeze in tasks and so forth. My fear is that complexity might cause some side effects when each sub-workflow of task management gets its own elisp functionality.
@publicvoit Can you elaborate on what you mean by "complexity might cause some side effects" here?
The effect I predict in my case is accelerating the proliferation of tasks in my projects. This is already happening for me - my biggest (in terms of org mode headlines) project gained 14 more tasks in 1 hour just last night, as a side effect of me doing few of the tasks.
But that effect is expected. I want to break work down to level I'm comfortable with, and org mode ergonomics is a limiting factor here.
@temporal I totally agree.
The thing about my fear of complexity refers to my inability to write and partly read Elisp myself, my inability to handle side-effects (like I'm currently fighting after an Org upgrade), remembering additional shortcuts (although this can be compensated with hydra), and so forth.
We both share very similar requirements & I'm more than happy to see your wishes come true. I'm going to evaluate them for my personal usage as well, of course. If I'm able to understand it.
Your chart is ready, and can be found here:
Things may have changed since I started compiling that, and some things may have been inaccessible.
The chart will eventually be deleted, so if you'd like to keep it, make sure you download a copy.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!