Numbered structure instead of hierarchical structure

[stuartpb]

Okay, so, right now the layout of this repository is a garbage mishmash of unrelated ideas. There's a "github" directory, but all it has is one file, describing how I use GitHub Issues. There's a directory called "starting", but all it has is one file called "apps", and it doesn't describe what I do to start apps so much as it describes my thought process and approach to starting any project.

And, as the root readme notes, it's kind of similar to Lean Notes, which is kind of better at structure? But is also kind of bad.

And, like, I've kind of launched on wanting to explore this idea a few different times - that's the impulse behind issue #2, wanting to split the Manual of Style out into its own repo - and also https://github.com/stuartpb/barfspace, where the whole idea was to free me from any kind of structural expectation (though structure, as it always does, did creep in, a little).

So, here's my new idea: I'll dig up one of the structural ideas I've been historically least fond of, and do a numbered hierarchy, like ITU OIDs, or the Dewey Decimal System, or a Table of Contents (even though there's no expectation of consistency between documents, at all).

The numbering, to start:

• 0: Do I Wanna Be Startin' Somethin'?
• 1: Got to Be Startin' Somethin'
  • 1.1: I Can't Say What It Is Exactly
• 2: Just Do It
  • This'd be a section on things that I don't set out to make into a whole thing - just something where I'm going to do it, like as a one-off task.
• 3: Maybe It's Software
  • 3.1: Maybe It's a Website
• 4: Maybe It's Hardware
• 5: Maybe It's a Writeup
• 6: Maybe It's an Event

Hang on, didn't I have an idea like this in my Planfile a while back?

[stuartpb]

OK, so, while I do think the numbered hierarchy thing is a good idea, I also think it'd be better to let that hierarchy be incredibly malleable - and, since I want to be able to have these documents cross-reference each other, I need another set of fixed identifiers for the documents...

Okay! Here's my idea: I'm going to keep them primarily in files named by UUID (kind of like the Unusual Studio Projects), and then I'm going to just link them all to each other using those UUIDs as symbols. (This isn't too far off from how the Trello boards for Lean Notes worked.)

In fact, I think I'm going to go ahead and merge Lean Notes into this, and then I might even do the thing like I did with Lean Notes where there are multiple different Tables of Contents, for different ways of slicing a problem.

In fact, I'm thinking the ToCs themselves should just be documents themselves, and the "main hierarchies" can be defined by link from the main README.md.

[stuartpb]

Really, this is starting to turn into Barfspace 2.0, and to be honest, I am here for that. I love the idea of having everything be about unnamed concepts, which are defined by the way things link to them, allowing for total semantic drift, without having to wrangle a bunch of name updates, necessarily.

This also makes Markdown link symbols feel way less redundant: I can pick arbitrary local symbols that don't need to match the content...

Hmm, and then I could make a tool that goes back, figures out what link that refers to, and updates references to the name on a case-by-case basis.

[stuartpb]

Also, like barfspace, this makes this repo work a lot better as an incubator - if I end up writing something that's solidified enough to work on its own, I can turn its document / documents into stubs pointing out to other repositories, like sacred-tenets, or hoard-guidelines, or stuartpb-loadout, or whatever, where the structure can live in a more stable format.

[stuartpb]

Also, a thing I love about UUIDs is that I can test for which documents link to which UUIDs by just searching for the UUID within the content of the document, and I don't even need to analyze the markup format or anything.

This would allow me to then "garbage collect" any documents that aren't referenced by anything linked from the README.md, figuring out why the idea became an orphan (as they say, success has many fathers, but failure...)

[stuartpb]

In fact... in light of #2, I think I'm going to go ahead and just make Lean Notes the whole thing I thought I would do for this, and turn this repo into a repo just for my Manual of Style.

I'm going to reparent the Lean Notes org stuff back over to my user account, then restructure that repo the way I was talking about with this repo.

(I also like the idea of "tagging" stuff, the way I was going to do with Lean Notes, so I think I'm going to have "tags" live as a sibling tree: the tags'll still be UUID'd, but they'll have different filenames, and they'll live in a separate tree because they're not the same kind of content.)

[stuartpb]

Okay, honestly, I'm looking at this some more, and I've decided that no repository deserves to be shackled to this repository's issue history or master branch, which I think has dangling references in my planfile history or something.

So, I'm just gonna go ahead and make another repository for my Manual of Style, copy the rest of the bits of this off to Lean Notes, make one last gravestone commit, then archive this repository (which will also help me from accidentally reusing the name, which was the whole thing that kicked off #1).