This reverts commit 690d16cdab.
Do not include complex tasks in the backlog agenda, as complex tasks are no
actionable items, but the backlog agenda should only list things that can and
should be done. Stuck complex tasks are shown in the Project agenda, and a list
of all others might only be necessary during reviews – but when complex tasks
need reviews (apart from when they are stuck), they should have a NOTE sub-item.
Sometimes only the backlinks to the items itself might be interesting, or
backlinks to the current item and its direct parent. To allow for easy
insertion of dynamic backlink blocks in those cases as well, include a
:parent-depth parameter. The default value of nil means no limit is imposed, as
has been the case until now.
This list only shows complex tasks, i.e., tasks with sub-items, and is therefore
not a faithful indicator for overwork (this was the original intention to have
this list). A better indicator might be to check the Backlog Agenda, but this
list might contain items far in the future and could thus also not be a valid
indicator for overwork.
The idea is that those entries represent project notes which should not get
tasks refiled as sub-items (sub-headings to structure these notes are fine,
though, and must be added directly). To connect tasks with project notes, use
links and backlinks instead.
This helps to prevent accidental refiling of tasks under notes and loosing them
there. A drawback is that `C-u org-refile` won't list notes as visiting targets
anymore; for this, use imenu instead.
Mostly making use of pcase-*, but I am not quite sure whether the `(,foo . ,bar)
syntax really helps …
Also adjusted some comments and some formatting.
We are interested in the backlinks so we now put them first. The backlink
targets (i.e., current item or any of its parents) are now grouped after the
priority of the item containing the backlink.
The previous version caused stack overflows in the regexp matcher, supposedly
because of matching newlines in the description. This should not happend
anymore, but description won't be matched anymore of they contain a line break.
NOP means „not a project“, so excluding them is plausible per se. NOP entries
will also be reviewed less frequently (usually once per month) so a combination
of NOTE and NOP would allow to have „abstract“ project notes whose main purpose
is to collect backlinks and thus group proper note entries (example: topics
relevant for release planning).
The idea is that items with identical priority but low effort are „more worthy“
than items with higher efforts (same gain = priority with lower effort).
Actually, the name “project” is too ambigious here, which is why I have replaced
it at some points with the more concrete word “task”. This is to mean that
tasks are items that work towards a particular, tangible goal but consist of
multiple steps to reach it. Project notes, then, capture the state of more
complex tasks with varying or multiple goals all interconnected in a specify
realm. Project notes are used for planning tasks and for capturing the current
state of affairs.
Topics, on the most abstract level, comprise areas of responsibility or activity
where not at every point in time there's something conrete to be done, but
periodic review is in order.
Related to PARA parlance (https://fortelabs.co/blog/para/), the mapping may not
be completely clear, as projects (in the sense of PARA) relate to both tasks and
project notes. Indeed, it could be the case that a project is small enough to
only have a associated task and no project notes (e.g., if everything is clear
and it's just „doing“), or a project (again in the sense of PARA) relate only to
some project notes (in my sense), e.g., when it's not yet clear or not yet
planned what needs to be done concretely or when even the goal(s) are not set
yet.
However, as far as I currently understand, the other items in the PARA
methodology map quite nicely to my terminology:
- Area of Responsibility ↔ Topics
- Resources ↔ Project Notes (or any other notes like my zettelkasten)
- Archive ↔ Archive (surprise!)
Maybe I should split my notes into two categories: project notes proper and
general notes containing information about not-necessarily-project-related
topics?
When appoints have been started but are then postponed to the future, I do not
want to see them on the WIP list. I could schedule them for the new date in
addition, but this would count the associated effort twice in the agenda view.
So let's just ignore timestamps in the future, they will show up when they are
due anyway.
This dynamic block will list all items (including their priority) that link to
the item at point or to any of its parent items. The use case for this is to
have a series of periodic appointments where certain topics should be
discussed (“jour fixe”), and where those topics can be referenced in those
appointments via backlinks. However, simple backlinks to an item on a fixed
date is not sufficient here, as there might not be enough time on that day to
discuss all items. To avoid having to manipulate all backlinks that could not
be discussed, one could simply add a reference to the parent item of all
appointments of the jour fixe series. Using the new dynamic block introduced
here, this item will be on the list of open topics until it's closed.
Daniel -