Re: documentation structure

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: documentation structure
Date: 2024-03-25 15:40:52
Message-ID: 682e11bd-07b9-4d8b-8bef-4990a13e0d22@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.03.24 15:10, Robert Haas wrote:
> Sorry. I didn't mean to dispute the point that the section was added a
> few years ago, nor the point that most people just want to read about
> the binaries. I am confident that both of those things are true. What
> I do want to dispute is that having a four-sentence chapter in the
> documentation index that tells people something they can find much
> more easily without using the documentation at all is a good plan.

I think a possible problem we need to consider with these proposals to
combine chapters is that they could make the chapters themselves too
deep and harder to navigate. For example, if we combined the
installation from source and binaries chapters, the structure of the new
chapter would presumably be

<chapter> Installation
<sect1> Installation from Binaries
<sect1> Installation from Source
<sect2> Requirements
<sect2> Getting the Source
<sect2> Building and Installation with Autoconf and Make
<sect2> Building and Installation with Meson
etc.

This would mean that the entire "Installation from Source" part would be
rendered on a single HTML page.

The rendering can be adjusted to some degree, but then we also need to
make sure any new chunking makes sense in other chapters. (And it might
also change a bunch of externally known HTML links.)

I think maybe more could also be done at the top-level structure, too.
Right now, we have <book> -> <part> -> <chapter>. We could add <set> on
top of that.

We could also play with CSS or JavaScript to make the top-level table of
contents more navigable, with collapsing subsections or whatever.

We could also render additional tables of contents or indexes, so there
is more than one way to navigate into the content from the top.

We could also build better search.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2024-03-25 15:44:34 Re: Popcount optimization using AVX512
Previous Message Bertrand Drouvot 2024-03-25 15:37:37 Re: pgsql: Track last_inactive_time in pg_replication_slots.