On Thu, Dec 09, 2021 at 12:13:11PM -0500, Ben Cotton wrote: > > I don't think it'd actually be harder. Look at Python documentation — the > > top level links all go to https://docs.python.org/3/, which defaults to > > "latest", but you can choose earlier versions from the dropdown. We have > > that same thing with Antora, but two entry points. > > Sure. This topic isn't worth a battle royale for me, but I do think it > would represent a regression in how we present our documentation, even > though the docs are still there and findable. > > > Also though: that versioned documentation contains three things:> > This is a digression, but I agree with all of it. Ohhhh, let me expand my thought then, because it wasn't meant to be a digression. Having top-level big blocks for versioned documentation makes sense if, when you go there, there's a whole bookshelf. But we really only have ONE versioned document, the release notes. It seems better to make the top level thing just be "Release Notes", and to make the version more prominent once you go there. > > Yes. Right now, once you click on > > https://docs.fedoraproject.org/en-US/fedora-server/, you're in that space, > > and https://docs.fedoraproject.org/en-US/iot/ is another, each with unique > > left menus. What if we put them all into one unified menu, with the edition > > names as top-level menu items on the left menu? > > That would represent a pretty significant paradigm shift. We might be > able to get all of the docs to pull nav.adoc from an external repo, > but that would break local preview builds. Otherwise, we'd need to > combine all of those into a single repo, which presents its own set of > challenges. > > The other approach would be to reproduce all of the nav in each > module's nav.adoc. But this would require being kept in sync manually. > That content would be relatively static, so it wouldn't drift too > often, but that also means we'd probably forget about it when a new > change is made. Ohhhhh, no, those sound like terrible options. But I think there's a better way than either one? https://docs.antora.org/antora/2.3/navigation/include-lists/ > > > > 6. Not sure where stuff like Gaming should go. > > > Are we talking about using Games or participating in the Games SIG? > > > > I guess it is the later. But where would user documentation produced by that > > team go? > > For the latter, it would be under Engineering Teams. For the former, > when it exists, it would go under Quick Docs or release-specific docs, > I'd say. We might need to rethink Quick Docs if we keep throwing everything in there. :) > > Or to put it another way: I don't think the docs.fpo front page should serve > > as an index to the wiki, even if that part of the wiki is kept up to date. > > I agree with the fact that "where are the docs" is confusing. But > using docs.fp.o to point to things that are still in the wiki for > whatever reason makes it less confusing. The story is "go to docs.fp.o > and follow the link you want". If that stays on docs or sends folks to > the wiki or readthedocs or whatever other platform, that's okay. The > point is that docs.fp.o becomes _the_ front page of our documentation. Hmmm. I might be convincible on this (even though M-W doesn't think that's word). -- Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> Fedora Project Leader _______________________________________________ docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/docs@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
