Hi.
Very, very recognizable. This is one reason why I keep on wanting to keep my ‘jdex’ spread throughout the filesystem: with an index.md – or index.org or whatever – in the folder of each ID.
The following is my attempt at generalizing your question, since it resonates very much with my yoyo experience.
The canonical Johnny Decimal way is to keep notes in the JDex. I.e. in the notes stored under 00.00, while the rest of the JD filesystem is for ‘bigger’ files. But I think your example of bug reports stretches the limits of this approach. It seems like you’re a Plain Text kind of person, using org files to track bug tickets.
I wonder if the following either/or question applies:
a) for plain-text-everything people, it needs to become acceptable to admit that a different approach/format to the JD system applies. Use index.* files through the filesystem, find them with whatever fast file search you use, and don’t look back. The separate-JDex format is for the majority of people out there who see their notes as records in an app, and have less need for plain text notes, and do all their work in various apps for which (binary) filetypes are the logical artifacts. Think Word documents, Spreadsheets, PDFs, audio/video, or an external issue tracker like Github.
b) there is still value in maintaining a separate JDex, even for plain-text-everything approaches. It allows you to plan your structure separately from the implementation. This is a collection of plain text files at 00.00, but see this more as metadata and put notes there accordingly. So in the case of bug tracking, this would only contain something like ‘I track bugs for my own software in org files at 22.10; bugs for contract work under agency X in Jira.agency-x.org under account Y, and bugs for contributions to open source project Z at Codeberg/Z …’ I.e. this is your lookup table to make unambiguous where you do what work, but not where you do the work itself.
This would allow a single 22.10 Jdex file which you could update as you modified your file structure, without having to change the Jdex structure. It requires a clear separation of what kind of notes you keep in each, or in other words, having such a separation needs to make sense to you. This would possibly eliminate a bunch of the IDs in your example: all external bug trackers like Jira for Agency X could be listed here (and delisted when no longer relevant, e.g. moved to 00.00/jdex.org_archive) and wouldn’t need a separate ID. If you track some bug requests in org files in your filesystem, then it would suffice (in my mind) to have a note in your JDex saying so, and have perhaps just 22.10.BugReports.org, 22.10.OtherRequests.org…
Another way of putting this is that the JDex structure would emerge from a post-it-on-whiteboard data collection process. Designing a JDex is more about collecting everything and then creating a hierarchy which unambiguously categorizes things into two levels. It’s really implementation-independent. I wonder if the problem arises for us because we work the other way round, and we have the unfortunate coincidence that the JDex is plain text and so is the rest of our day-to-day work. For many people that’s not the case (even if you use Obsidian, which stores things in plain text, the experience is that the notes are collected in an app, separate from The Actual Work. Org-mode or Vimwiki give the experience that notes are intermixed with The Actual Work.)
Maybe you’ve already cycled through the option I explored above! This is my thinking aloud using your example to iterate a bit … I hope that helps at all, but in any case it’s a recognizable problem for me.
> 22.11 BugReports > index.org, where index.org is 4 levels deep and it’s where my actual notes, links, etc would go for bug reports.