Fórum Johnny.Decimal forum

Johnny.Decimal – 16 Sep 26 Apple Notes now available in the LAS/SBS downloads • Blog • Johnny.Decimal Apple finally built an import feature that doesn't suck.

Johnny.Decimal – 16 Sep 26 How I organised 15 years worth of passwords (video) • Blog • Johnny.Decimal Here's how I use the Johnny.Decimal system to manage my passwords.

Johnny.Decimal – 16 Sep 26 This week at JDHQ – 2026-09-15 • Blog • Johnny.Decimal The weekly email update, cross-posted here.

Johnny.Decimal – 13 Sep 26 Lucy loves unsexy, boring, functional, government information • Blog •... Lucy just spent two days going through a long list of small-business-related online resources that she's collected over the last few months.

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.

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. T

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 nuts

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? Do you keep one canonical JD location and use aliases/tags/searches/collections for all other views? Do projects live inside the JD hierarchy, or do you keep project/work views separately and point back to the canonical files? Where do TODOs live — with their topic/project, or in a central TODO area? 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

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? Do you keep one canonical JD location and use aliases/tags/searches/collections for all other views? Do projects live inside the JD hierarchy, or do you keep project/work views separately and point back to the canonical files? Where do TODOs live — with their topic/project, or in a central TODO area? 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

Johnny.Decimal – 9 Sep 26 JD CLI updated: now creates filesystem folders • Blog • Johnny.Decimal Typing `jd 12.34` now creates that folder if it doesn't exist.