P.A.R.A.more #4 — The Meta Layer (Supplementary Post)

A Lightweight, Anti-fragile Tagging Approach Made for P.A.R.A.

Photo by Helena Hertz on Unsplash

💡 This is a supplemental post to the fourth installment of my series on extending the PARA organizational method. Confusing? Here’s an index for the whole series.

---

My previous post was a contemplation on the use of tags.

I explained why tags can be a valuable addition to P.A.R.A.

I also derived six criteria for creating an effective, sustainable tagging system:

1. Reduce the upfront decision cost as much as possible

2. Remove the need to memorize tags

3. Separate tags from content and let tags evolve naturally

4. Review & consolidate your system opportunistically

5. Strive to make every tag count

6. Choose a lightweight, antifragile approach to tagging

These are probably not exhaustive but are enough to move from tagging as a “fragile burden” into a powerful tool with a great return on investment.

In what follows I will give you a personal example of how such a tagging approach can look in practice.

Interestingly, when reviewing my tags for this post I found that they seem to have magically fulfilled all the guidelines mentioned above.

Maybe that’s why they have stuck?

My system consists of five different types of tags:

1. Temporary State tags

2. Permanent State tags

3. Type information tags

4. Potential Action tags

5. Source & Destination tags

These are the tags I found personally useful in conjunction with my personal productivity stack. For you and your unique setup, there may be many other potential types of useful tags. But if you struggle with some of your tags I propose that you evaluate them against the criteria above.

1) Temporary State Tags

In P.A.R.A. the location of something tells you what “state” it is in. If it’s in a project container, it’s "hot" and relatively fresh. If something is in an archive container, it's "cold" and maybe slowly dying out.

However, with bigger projects I often find myself needing a more granular state. And I use tags to denote that.

These are the granular tags that are part of my tagging system:

1. next_🔜  — want to review next/soon in this context

2. wip_🔥  — indicates "work in progress" in this context

3. done_✅  — indicates I am "done" with that item in that context

4. draft-1_✍️ — 1st draft stage for blog posts (applied after 1st working session)

5. draft-2_✍️ — 2nd draft stage for blog posts (refined from a 1st draft)

6. draft-3_✍️ — 3rd draft stage for blog posts

7. gdocs_✍️ — public draft for getting feedback on blog posts

These temporary state tags usually only have a meaning in the context they are introduced in. In most cases, I will use these tags only for active project material. As these projects are completed or single files move somewhere into A.R.A. I would remove these tags again.

Example Use Cases

1. Often when I have a research-intensive project with many notes, I will want to work through a lot of notes over several working sessions. In order to manage that with some visual guidance, I will then tag all the untouched notes with next_🔜, the notes I am currently working on with wip_🔥, and the ones I already finished reviewing with done_✅. This gives me a visual sense of progress when I look at the whole project and helps me avoid opening the same note again and again.

2. When I first write out / draft a new post it gets tagged draft-1. Once I revisited it in a later work session I switch to draft-2 and with more challenging posts sometimes also use draft-3 . After that, if I port the text to Google Docs for getting feedback on it, I tag the note with gdocs_✍️. Once it has been released I removed this granular tag again. These tags to indicate draft stages are useful since I usually work on several blog posts at the same time and depending on my daily motivation and the draft stages of various posts I can make ad-hoc decisions on what to work on at that moment. 

Are These tags fulfilling the criteria?

1. Reduce the upfront decision cost as much as possible

   • By default, I set no temporary tag. So there is no upfront decision cost. Rather, the tags arise from a concrete need (e.g. to get visual progress). Each of these tags has a clearly defined usage and it’s quite clear which tag is to be used in which situation. Using emojis that I am familiar with (from task management) further makes these tags easy to use.

2. Remove the need to memorize tags

   • I only maintain about a handful of granular state tags in my system. Also, since these tags are by design temporary and are applied within active projects, there is no need for memorizing them. They are handled within short-term memory and are fresh in mind.

3. Separate tags from content and let tags evolve naturally

   • These tags denote state, they don’t say anything about the content itself. They were not predefined but arose organically from my requirements. For instance, before I started this blog there was no need to have tags for different draft stages. I added these tags to my system once I felt I needed them.

4. Review & consolidate your system opportunistically

   • These tags get reviewed upon project completion where I triaged all project items and distribute them back into P.A.R.A.. So there is a clear trigger point that ensures they do not get outdated. However, we are human, and slips happen. But even if they do, they are highly context-dependent. That means they won't make sense in other places and can be purged opportunistically when reencountered.

5. Strive to make every tag count

   • These tags are very much part of active project management and thus are always highly relevant to the task at hand. You won't use any tags that are not valuable, since you'll be too lazy for that.

6. Choose a lightweight, antifragile approach to tagging

   • Temporary state tags should be mutually exclusive, i.e. only one such tag should be applied at once. This keeps the whole system lightweight. Further, sometimes forgetting to remove a tag from a note can create a surprising advantage when the note lands in another place and “stands out”.

2) Permanent State Tags

In addition to temporary states sometimes I need a more permanent tool - something that I can set once and usually maintain indefinitely.

Here are some of my personal examples to indicate such a permanent state:

• substack — to indicate that this post has been released on substack (applied after draft-3 )

• gold_🏅  — this is a highly valuable note that I refined multiples times or put much thought into

• public_⚠️ — a warning that this item is shared publicly and changes to it may be visible to others

• locked_🔒 —  this item is “frozen” and should not be modified further.

There are many potential use cases for permanent state. They sometimes are helpful for filtering, but most often work more like visual hints that tell you something important about the items you encounter. They usually applied once and never go out of date. If they do it's immediately clear e.g. if I edit a locked file or if I remove the public sharing from a note then these are the triggers to remove the tags.  

Example Use Cases