//

Overview of Textmind's Journal subrepo

Schema overview

The user's journal is at 2-Linked/Time/Me/Journal. It is a subrepo. It has two major directories, Plan and Review.

Historical records, such as completed walklogs, are filed to Review/Source.

Plan contains plans, which use the same dateranges as reviews. Plans are written after reviewing the prior period of equal length. Review/Plan compares plan to result.

Use atomic commits

Whereas the commit history of the main Textmind repo is lazily linear, the commit history of the journal should follow good commit practices. This permits insight into when the various stages of reviewing and planning occurred. This aids accountability and analysis. Unlike the main Textmind repo, the Journal subrepo can be orderly, because time is orderly.

Pairwise reviews stack binary

Pairwise reviews stack binary: 1d, 2d, 4d, 8d, 16d, 32d etc. Each review level is stored in a separate directory under Reviews. 1d reviews are together under Reviews/1d, 2d under Reviews/2d, etc.

Reviews/1d = calendar days

The basic unit of time is the day, starting on one's birthday. Ignore time zones; use calendar dates only. In Reviews/1d, each calendar date is a directory. If there is a walklog that starts on that date, it's filed into that directory. Otherwise the directory is left empty, in case other text data types are added to it later.

A walklog's duration never matches the 24-hour calendar day. To reconcile, cut the walklog as close to the boundary as possible while still preserving necessary context, and then move it to the appropriate 1d directory. Preventing edge fragments means there will be some overlap between the divided pieces of the walklog, which is fine.

Revising finished journal reviews

Sometimes one wants to add new data types to previously written reviews. One must first add the source data at the appropriate Reviews/1d calendar date, and then adjust the affected higher level reviews.

Use Org GTD and commit links to control this process. Prose is less amenable to merging than code, so keep it simple.

Add data at the lowest level, and then step the implications upwards until they vanish. Finish one data addition's implications before moving to the next.

Only one todo tag is necessary to propagate a changed 1d review up to the top of the affected review hierarchy. After editing the 1d, add a todo tag to propagate upwards. After editing the 2d, remove the tag from the 1d and place it on the 2d. Once the change is no longer significant enough to affect the next review, stop.

The ability to easily add new data sources to complete reviews means that one can do the first review pass based solely on walklogs, and then augment with additional data sources as needed. This makes reviewing much easier. Otherwise, trying to consistently integrate all relevant outside data into the initial review pass becomes a huge PITA over time.

Publish At: Author:Cyberthal

Read more posts by this author

Github
comments powered by Disqus