Moving ID to another Category and Area

10-19 Concepts 14 Build your system
1

I haven’t seen any discussion on this, so wonder what the thoughts are. I am an academic. One of my Area hierarchies is as follows:

  • 30-39 Scholarship
  • 30 Proposals
  • 31 Funded Projects
  • 32 Papers & Presentations
  • 33 Patents
  • 34 Unfunded and Gestating Work
  • 39 Scholarship Archive

Lets say I have been developing a research area for a while, call it ID 34.12. It now reaches the point where I write a proposal, so it should be in category 30 (humor me since I know that JD prefers not to use x0 category numbers). If it gets funded, it should then be transferred into 31.

My inclination is to go ahead and do this and to notate in the index (i.e., first note that 34.12 is now unused but has been transferred to 30.17; then on funding, notate that 30.17 has been transferred to 31.23).

I know JD has ideas of getting a group of academics together to discuss applying his concepts, but it seems to me that the ordinary workflow that is most natural (at least to me, and perhaps to others) would argue for this sort of change in assignment of folders. Or maybe some will tell me that I’ve specified my system incorrectly to make it vulnerable to this necessity.

2

I’ll throw in my two cents. I hope it helps :grin:. What makes sense to me is to separate the workspace and the final products.[1] So, for me, 34.12 is the workspace for this project, then 30.17 is an output (proposal). If the proposal doesn’t depend on files in 34.12, then I’d keep the proposal in 30.17 from start to finish. If it does depend on files in 34.12, then I’d start it in 34.12 and move a PDF of the proposal and related documents to 30.17 when they’re finished and submitted. I would do the same for later outputs like papers and presentations based on the work in 34.12. Prepare them in 34.12 then assign them a new ID in category 32 when they’re finished. Or, work on them in their new ID from the start. Make a note of the relations in the index when you create the new IDs.

This way makes sense to me, at least. The project IDs have a better chance to sink into memory, which helps retrieval if you need something from them in a few years. And, it saves me from having to keep an expanding list of moved IDs in my index. If one or two things move, it’s not so bad. But if in five years, I’ve done 15 projects, half of which have gone through 34.12 or 30.17, the index gets messy and the IDs lose their memorability. Unless proposals always go through 30.17, for example.

One potential drawback is how fast you might use up IDs in 34. If you do five projects a year, you’ll have twenty years’ worth of space for projects, funded or not. If you do 20 or 50 projects a year, then it’s a different story. Even then, if in five years, you’ve used up all the IDs, you could do a batch archival to category 39, where perhaps each ID is a topic, a year, or semester.[2] In your index for those 39.xx IDs, you would note which 34.xx IDs moved to there. Then, in 2031 — you want to find that project that you did in 2024, and you remember that it was in 34.12. You search for that in your index and it shows up in 39.xx, where you’d moved it with its original index notes and all.

When you do the archival, you could also move the related proposals and other outputs at the same time. This would make sense if a large percentage of your projects get funded, for example.

An idea that came to mind is how your archive might be a JD system in its own right. But this is an idea for another post when I’ve had some time to think it through more.

  1. This is what I do when I write a résumé. I have a “factory” ID where I write my resume with LaTeX, then when it’s submitted to a company, I move the finished PDF to its own ID. Thereafter, if I get an email or a contract to sign, I put those related documents in the new ID. ↩︎

  2. I assume here would be a good place to break the soft “no subfolders” rule. ↩︎

1 Like
3

I like this solution, and using the cross referencing in the index. I’m not so worried about using up ID’s since if it comes to that (having watched JD’s videos so far) it is possible to expand the ID space beyond .99 say to .199. Cross referencing within each file folder could also be done (I am mac based) by putting the alias to the folder from the previous stage into the next stage.

4

Given that each ID means a “job to be done,” each such distinct job such a grant writing and then having the funded proposal exist as separate IDs since they are different jobs even though they might be related? In the index note, you could capture the link or if you’re using something like Obsidian, you can explicitly link between the items either using a note property or double square bracket links.

5

Moving this to its own thread. See you there if you’re interested.

6

I think this may be an issue with how your system is structured. The main problem I think is that some of your categories - e.g. Proposals, Unfunded, Funded - act less like fixed categories and more like fluid task states.

The way I see it, the areas and categories should define what the items are, not how they are, or what their state is. The difference is that former doesn’t change, whereas the latter may.

So, I’d say that in your case you have two options:

  1. Keep the system structure as is, and treat the projects in different stages (Proposal, Unfunded, etc.) as separate items, separate IDs, because each stage is a big enough chunk of work to warrant its own ID. As @LasTr already mentioned, this has the advantage of a clear separation between the different stages, but also downsides of when you need to share files between the stages and it’s not always clear where a file should belong.

  2. Restructure the system to make the categories identify the items themselves, not their state. For example, if you don’t expect to have more than 100 projects, maybe just having a category Projects would be enough, and then each of the projects gets its own ID, regardless of the stage it’s in.

2 Likes
7

A brilliant insight, @rxlecky.

Lucy almost designed something similar: she had the future for projects she wanted to do, the present for stuff she was doing, and the past for stuff that had finished.

Such a structure requires that you move things between categories. This is to be avoided.

1 Like
8

This would work, though it would mean copying a number of files into new IDs. But storage space is cheap

9

Can you elaborate? Do you mean that restructuring the system would require moving items from their original IDs to the new IDs?

I’m not sure what @johnnydecimal has to say about this but if your system is still fairly young and there are not (m)any external references to the IDs, I think it’s okay to just move things around, rename your categories, areas and IDs. But of course, this may not be feasible if there are already a number of things tied to your original structure.