architecture: point actors and glossary at the concepts page #41
Loading…
Reference in a new issue
No description provided.
Delete branch "concepts-single-copy"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
architecture-docs/architecture.md's## Actorsand## Glossarybecome a pointer to https://core.pages.git.fediversity.eu/concepts.html, so exactly one copy of that vocabulary survives.The page is new in the
fediversitymonorepo (core/docs/md/concepts.md), and is the union of the two copies that existed: it carries the rootREADME.mdtext plus this document'sMaintainers/Developerssplit under Actors and itsProvider,Provider configurationandResourceglossary entries. Nothing is dropped. It lives there because that is where the terms are used -- the option reference and the flake-attribute pages on the same site refer to them without redefining them.The two in-document links that pointed at the removed anchors (
- Circle: [actor](#actors)and the components note) are repointed at the same page's anchors.Separate note, not touched here:
### Proxmoxunder## Technologies usedstill describes Proxmox as the hypervisor. Thefediversityrepo no longer uses it -- it deploys through Incus. Flagging rather than rewriting, since the rest of that section is a planning document rather than a description of the code, and deciding what replaces it is a call for the project team.Assisted-by: Claude:claude-opus-5
Maybe this was merged prematurely because the page nor the markdown source seem to exist? I'm also not convinced a glossary doesn't belong in the architecture-docs, all the architecture documentation needs to reference it. The problem with referencing the Hosting Provider-facing documentation in the fediversity repo is that we may change the terminology there at some point to be clearer to interested parties.
apologies for the order - it landed now (fediversity/fediversity#1574).
this is far, of course.
so, the idea here kind of to move more from markdown files to actually deployed documentation, as this repo in practice is perhaps both less friendly to navigate as well as more ephemeral, containing largely historical stuff.
on source of the documentation, i'm seeing quite some close coupling to the point of it feeling sensible to update documentation and implementation in lock-step, so in that sense
core/(containing the data model modeling the concepts) felt like a sensible place perhaps.