How do you combine a canonical JD file hierarchy with cross-cutting working views?

The Johnny.Decimal system
1

I just spent a week creating and then instantiating a Johnny.Decimal directory structure system as ordinary folders/files in Finder.

The problem is that real work often cuts across the hierarchy. I want one file to have one permanent JD home, but I also want temporary project views such as:

Current USCIS response
Current philosophy project
Things I need this week
Items waiting for someone

Those views may draw files from several JD locations.

I use DEVONthink because replicants, Smart Groups, and working sets are excellent for this — but I do not want DEVONthink to become a second competing hierarchy.

How do other JD users handle this?

  1. Do you keep one canonical JD location and use aliases/tags/searches/collections for all other views?
  2. Do projects live inside the JD hierarchy, or do you keep project/work views separately and point back to the canonical files?
  3. Where do TODOs live — with their topic/project, or in a central TODO area?
  4. What rule do you use to prevent temporary working views from becoming a second filing system?

I’m asking because I’ve spent the last week building a Johnny.Decimal directory structure in Finder. Finally, everything has a permanent home. The hierarchy is also peppered with Markdown files that I edit and interlink in Obsidian.

But I still need DEVONthink for project work and cross-cutting views, and its indexing—which is supposed to mirror the Finder hierarchy passively—has proved unreliable enough that I’m rethinking how the two systems should relate.

Thanks in advance.

2

This is what the fairly new concept (to us; it’s a borrowed idea) of Work Packages come in handy.

Very brief history lesson

In early JD days before people ‘designed’ systems, IDs tended to be more granular, and to be created more frequently. In this role, they acted a bit like project containers: you needed to do Current USCIS response so you’d create 32.18 or whatever and manage it there.

Lately – since we developed the fixed Life Admin System – IDs seem to have become broader, and more static. So now they’re more like permanent homes for things, leaving you with this question of ‘where do I do project-like work?’.

Work Packages

Are the answer. They’re an evolution of our old ‘creative pattern’, which recognised that in creative businesses, you very often have more than 100 ‘creative jobs’. Produce a video, make a logo, design a leaflet, so on.

We had that pattern for a while, then realised that it applies to any sort of transient job. Of which you will also have more than 100 over time. So the concept was expanded, and now we call them work packages.

It’s not documented yet

We only just came up with this, and I re-recorded the second part of our task & project management (paid) course to accommodate them. If you don’t have access to that there’s a YouTube video here which I recorded while trying to figure out the pattern. It’s close enough to the finished thing.

Lucy has it on her to-do list to create a proper documentation page for this.

Numbering

But here it is in a nutshell: create a new area with a special numbering scheme. They start with a W and get 4× digits like W0011.

W0000-9999 Work packages
  W0011~12.34 First work package
  W0012~32.18 … and so on

This gives you 10,000 over the life of your system. The important part is the link back to the parent ID as indicated with ~12.34. This is how you don’t just end up with a big list of unsorted work.

When you’re finished here, you never come back

Crucially, work packages aren’t a place to store permanent records. That’s what your IDs are for. We compare them to your garden shed: you come in here, bring some stuff in with you, bang about for a bit, and out comes – ta-da! – a beautiful new thing.

That thing is the finished product. It’s your USCIS response. And that thing needs an ID where it lives, permanently.

The last two are states, not places

‘Things I need this week’ and ‘items waiting for someone’ are states of being and are well suited to tags. If your structure is the vertical, these are horizontal slices across it.

Don’t move a thing to another place because it’s ‘waiting for someone’. Leave it where it is, and tag it somehow.

I keep one-off task-like todos in categories that mirror my system. Then projects get their own place, using the WP system noted above. Again, see the T&PM course for 5 hours of exhaustive detail.

3

Thanks, Johnny — this helps, especially the distinction between permanent homes and transient work, and your point that “waiting”, “this week”, etc. are states rather than places.

I think the Work Package idea solves only one layer of my problem, though. A lot of my work is legal/research work where the “stuff banged about in the shed” is itself worth keeping: successive drafts, annotated evidence packets, decision notes, correspondence, research extracts, evaluation versions, argument maps, etc. The final product is not the only durable record. And those durable by-products may ultimately belong in several different permanent IDs, not just the ~12.34 parent.

So what I’m really trying to preserve is this distinction:

One permanent canonical home for each record, but many temporary project/work views in which that same record can participate without being copied or moved.

DEVONthink replicants are excellent for that second part — they let a permanent record appear in multiple project contexts — but indexing creates some nasty technical problems when the canonical files live outside DT.

So I think my remaining questions are:

  • Is a Work Package meant mostly to contain references/aliases to permanent records, rather than copies of them?

  • And when intermediate products become worth keeping, do you “promote” each one out to its appropriate permanent ID while the WP remains merely the transient control/workbench layer?

That seems closer to the problem I’m actually trying to solve.

Thanks again!

4

Work packages are meant to contain temporary work. Let’s say I use one to produce a video.

The work package contains all of the raw footage; copies of images pulled from my creative library; a one-off music download that we used in the clip; and finally, the as-published output.

The only permanent artefact of interest is that as-published video. Everything else was interstitial work. Now, we still keep that. Maybe we need to re-edit the video in the future. But the key thing is that I don’t need to see it every day. I don’t need it up in ‘main ID world’ cluttering up IDs.

Theoretically we would copy that final artefact up into main-ID world. In practice, we don’t – because videos, say, are published on YouTube/Vimeo and that’s kinda their true home. But there will be different types of artefact where I’d say that the finished thing should be moved up top.

Once you’ve finished with a WP you shouldn’t ever need to go there again.

5

Reading this, I wonder if in your case the following edit to @johnnydecimal’s statement applies:

I.e., you would plan to keep all work packages in the state they were when you finished the work, and leave a link somewhere between the finished product(s) and which work package(s) they relate to. That way you can retrieve all the notes if you need to, e.g. for legal reasons. But you leave everything in there that you don’t need to show.

Is that technically feasible for you?

Wouldn’t it be great if we could create a new garden shed for every new batch of ‘banging around’, and store the previous shed exactly as we left it … hmm … 3D laser scanner … business idea …

6

And I think this is the reality for most. Honestly, we do it.

What I really want to stress is that WPs do not become another place for permanent storage of shared artefacts.

Let’s say the WP’s job was to create you a new logo for the business. That logo must 100% no exceptions be moved up to 43.ID Our logo so that it can be consumed from there in the future. You must not expect people to know that it’s buried in the WP that created it.

But if the WP created an artefact – a newsletter, say – that was published and is now essentially finished? Sure, leave it all in that shed and call Hans’ 3D Shed Printing Service to get yourself a fresh one.

Also I have this lovely plot of land to sell, excellent base for shed building. Call me.