From the post:
> But, you know, I was a loyal servant of the community process. I was asked to document that stuff, and I did, and I put it in the documentation in the place where it most logically seemed to go. The fact that the overall structure of the documentation probably isn't for the best is not my fault, nor is correcting it my responsibility. And it's not anyone else's responsibility, either.
...
> It's not difficult to understand why this happens. If I add a new feature to do a certain thing to PostgreSQL, I am the expert on that feature. There's nobody else who knows better than I do what the documentation for that feature ought to say. My work might have shortcomings just like anyone else's, but especially if I'm just adding new entries to tables that already contain dozens or hundreds of existing entries, how much difference of opinion can there reasonably be? It's more likely that reading the documentation will cause someone to take issue with the design of the feature itself than it is that they won't like the way it's documented.
Which, I think, is blind to the bigger issue.
As you note:
> The reason is, I think, that flexibility is a pretty fundamental part of the project. We're great at providing building blocks (and documenting them), but we steer clear of describing a particular way to assemble them together.
...
> In other words, our docs are written by devs for devs, and we leave the higher level stuff to tutorials written by others etc.
The deeper and more common problem between those two symptoms, which the OP misses, is that the people writing the docs often don't use, and maybe haven't ever used, the tool or features they're documenting in their most common productive modes. The most productive devs are often the least knowledgable people in how most, or even many, users use it.
Companies often hire (and compensate) someone to try to take the giant mess of dev-written reference content and make guides out of them. But if those people don't use the product either, you just get better-organized docs that still miss the point.
Most tools need usage experts writing docs far more than they need feature or software experts. The time of open-source tools' usage experts — "written by others etc." — is often as or more valuable than the time of the open-source project's engineers'. Usage experts are likely being compensated to do almost anything but document the open-source tool, or might even be compensated to document the tools privately or internally for others in an organization to use them better than potential competitors — the opposite of community.
The kinds of tools where this trends toward open tutorial creation and documentation tend to have communities of users who aren't as focused on specific tools or narrow usage as systems tools like PostgreSQL — gamedev and media production tools come to mind.
"Make a game" or "make a movie" are no less varied than "make an app" or "make a service", and can still be prone to tooling disputes (ie. using Unity vs. Unreal vs. Godot, Premiere vs. Final Cut vs. Davinci), but seem to fall into the trap of hoarding tool knowledge less often. Maybe because there's more authorship and recognition to those types of work, I'm not sure.