Sunset docs for soon-to-be-deprecated projects

[LauraLangdon]

NB: all renaming will happen in a future PR. 😊

With the transition away from Atmo, we'll no longer be directing users' attention to Vektor, Grav, and Reactr. Subo isn't being deprecated, of course, but docs for using Subo with particular products will move out of a Subo category and integrate into the product docs (except for the install page, since that's the same for everything Subo).

None of the Vektor pages are referred to by any other pages, so they can safely be removed.

Of the four Reactr pages, only the language support and Reactr ❤️ Wasm pages are currently referred to outside of the Reactr category. It's not yet obvious whether the language support page should be moved to Compute or to Atmo, nor whether the Reactr ❤️ Wasm page (referred to on Subo -> Usage) should be absorbed into another category or be deleted. The language support page will move to Atmo, and I deleted the reference to Reactr from the Subo -> Usage page, so it can be removed.

None of the Grav pages are referred to by pages outside of Grav, so they can also be removed easily.

The Subo -> Usage page overlapped enormously with Atmo -> Get Started, so I combined them and Subo -> Usage can be removed.

Given all that's disappearing, we'll also no longer need a glossary. @hola-soy-milk made a great case for keeping an Atmo glossary, so I've removed references to deprecating projects and moved the glossary into Atmo.

[hola-soy-milk]

I'd love to recommend keeping the glossary in some form, or definitely bring in a new one, seeing as the Appspec lists a set of terms that I would need a glossary for

[LauraLangdon]

My thinking has changed on this! I'm now thinking that we should make word meanings clear in situ, like shift the burden of making vocabulary clear to us as we're writing instead of putting it on the reader to go looking for a glossary. I'd love to hear what you think about doing it that way, @hola-soy-milk!

[hola-soy-milk]

My first thought is: Why not have both?

The purpose of the glossary is to have the reader pop over if they see a term and need a quick refresher of what it means. Say, they've read it earlier and instead of having to scroll back to the definition.

Or did I misunderstand? Are you suggesting we make the terms like Tenant clear from context, or that we should change them?

[LauraLangdon]

Are you suggesting we make the terms like Tenant clear from context, or that we should change them?

Yes, to both! We should be able to make our terms clear in context, and if we can't then that's a flag that we should see if we can come up with a more informative term. In fact, Tenant is a perfect example of a term that should be easy to make clear in context, because IIRC a "tenant" in this context is someone literally renting resources (a hosted Compute customer). "Tenant" means exactly what it sounds like it should mean.

My first thought is: Why not have both?

My developing sense is that in addition to what I said above, I worry that having a "Suborbital" glossary might implicitly suggest that Suborbital's offerings are so complex that they need reference material that other products in the space do not (I haven't found one on any of our space-neighbors' sites', and haven't felt like one was missing, because terms were clear from context).

Having said that, I feel far less strongly about all of this for DeltaV than I do for Compute, because DeltaV is expected to be kind of niche in the first place. So having a DeltaV glossary in the DeltaV category—as opposed to a glossary for Suborbital as a whole—seems okay to me. Optimally we'd still make terms clear in context, though, even for DeltaV.

How that seem?

[hola-soy-milk]

The separation of glossaries sounds grand.

I'm afraid I'm also struggling from a language standpoint, as tenants refer to humans renting resources, making it a metaphor in this context, seeing as Tenant as we use it is "Also known as the tenant.yaml file or 'tenant config', this defines the declarative schema for describing a DeltaV tenant".

So that's okay, but when it comes to English as a second language, I would prefer to be one hundred percent sure what something means in a specific context, and I'm not sure this can be done by implication. I'm probably overthinking this.

I see the conflict of having a glossary implying there's a complex nature in the terms, but I'm also a fan of having a central place to hop in and quickly look things up. It's not something I often need, but when I do, it's indispensible. In fact, I'd even go as far as to say that maybe it seems complex because well, Wasm-based plugins are. If GitHub, Deno Depoy (which is in a similar space), React and other projects have glossaries for their complex terms, I think the same applies here, too.

I don't want to be a blocker on this, however. Another argument I'd see for the contrary is that being able to search documentation nullifies the need for it. Would that make it superfluous/difficult to maintain? I'm not sure.

[LauraLangdon]

I think everything you said makes perfect sense, and I appreciate you calling out ESL readers' needs especially 🤗. And thanks for the links to those glossaries! It looks like Deno's glossary isn't linked in the top-level docs categories (which is why I didn't see it!), and is only shown in the subcategory to which is belongs, so that feels like confirmation that doing the same for DeltaV would be a solid move.

I'm still hoping to not need one for Compute, but what do you think?