> For products you're developing that involve multiple repositories, it's possible to use a "meta repository"[1] to establish what's called a login group
Gotcha; that makes sense considering how users are handled.
> There's some social stuff if you find later that you want it. Fossil development moved from a more traditional mailing list to a self-hosted forum a while ago, but it isn't enabled by default.
That all sounds reasonable (this + the tech notes you mention next). I generalized a bit too wide when I said "social stuff". I was thinking more along the social media angle (GitHub stars, follows, etc.); but with the way it sounds, that wouldn't make sense given the user model anyway!
I currently run a Forgejo instance for a small team, and I can disable some of those features, but it just feels a bit messy with so many UI elements that don't have a purpose.
> If you stick just to HTML and CSS, you should be fine. The functionality is pretty spartan.
I think I'll have to try it out to see what is possible on this front!
> This is governed by the capabilities assigned to a user. [...]
Between this and login groups, it actually looks quite reasonable to manage a set of repositories in the way I'd like! I really dig everything being so tightly coupled to a given project, actually. Makes me a bit bummed I never gave Fossil a look all these years.
> 2: Funnily enough, it shares the same pain as administering Plan 9's fossil(4) fileserver.
Reading that over, I can see how that requires some due diligence. I already foresee the inevitable "why weren't the changes propagated to the other repositories?" moment.
I think this will be my weekend project!