Live data from Hacker News

The PostgreSQL documentation and the limitations of community

rhaas.blogspot.com

21–30 of 61 posts

Re: The PostgreSQL documentation and the limitations of community

#21
post #12

Here's my perspective. I've been a technical writer (TW) for ~10 years. 3 at an IoT startup, 7 at Google. > The strengths of this process are also its weaknesses. A developer is, by definition, someone who spends the majority of their time doing development, which is to say writing code. Updating the documentation becomes a task that must be completed so that the code one has written can get committed so that one can…

Just curious. Where do you think that an open source project like PostgreSQL gets a budget to hire anyone? Let alone to dictate a new line of authority to the volunteers who are already maintaining it? And don't forget that there are valuable volunteers who are likely to go elsewhere if too many new rules are added that they don't want to live with.

PostgreSQL, like many other open-source projects, has sponsors and accepts donations. Here's their sponsors page:

https://www.postgresql.org/about/sponsors/

Also, I think it's important to note that a lot of contributors aren't volunteering their "free time", they're being paid by some other employer to contribute to PostgreSQL as part of their job:

https://www.enterprisedb.com/blog/importance-of-giving-back-...

Re: The PostgreSQL documentation and the limitations of community

#22
post #17
post #6

Earlier quoted context omitted.

At this point I believe that documentation is the most important marketing artifact that a project has.

I always point out the readme pages of projects on github. How many times has that made the difference between you using the project or not?

Not zero if I can't figure out how to get started in a reasonable amount of time. I'll go look for another solution

Re: The PostgreSQL documentation and the limitations of community

#23
This is kind of what the old PostgreSQL "Tech Docs" website was useful for, back in the day (~20 years ago).

Here's a random snapshot of it from the Wayback machine:

http://web.archive.org/web/20040630081140/http://techdocs.po...

Much more user-level oriented than the reference stuff.

Re: The PostgreSQL documentation and the limitations of community

#24
post #19

Earlier quoted context omitted.

Open Web Docs is a potential model to draw inspiration from regarding funding: https://openwebdocs.org Presumably, PostgreSQL has leaders who are responsible for steering the ship. If the project is going to succeed long-term, those leaders have to find ways to keep their contributors happy while also creating an organizational structure that leads to good docs. Easier said than done, I know, but it really is as simp…

Sorry if any of my comments came off naive or obtuse when it comes to open source dynamics. If you want that apology to be meaningful, you should learn something. When you're talking about a highly successful open source project that has been going for more than 3 decades, it is beyond ludicrous for you to say, "If the project is going to succeed long-term..." It already has succeeded long-term. And you would be bett…

> When you're talking about a highly successful open source project that has been going for more than 3 decades, it is beyond ludicrous for you to say, "If the project is going to succeed long-term..." It already has succeeded long-term.

Yes, your reaction here totally makes sense. Feedback acknowledged.

> If you want that apology to be meaningful, you should learn something.

I have re-read my earlier comments and I feel that you are being more hostile to me than is justified. I do not think you are adhering to HN's code of conduct guidelines for comments: https://news.ycombinator.com/newsguidelines.html#comments

> you would be better off figuring out why it works rather than lecturing about how it must work

This doesn't seem fair. The original post is about the limitations of the PostgreSQL docs. Docs have been the focus of my career for 10 years. I have experienced and analyzed docs problems in many contexts: small orgs, large orgs, open source, closed source. I made an on-topic comment about ways to resolve the problems that the PostgreSQL docs are facing. Is it the only solution? Of course not. But I totally have relevant experience in this domain and, just like you have a good idea about what generally works and doesn't work regarding open source funding, I have a pretty good idea about what generally works for creating the conditions that lead to good docs.

> So comprehensive external documentation is hard to find.

Again, I think the web platform space is relevant here. Web platform documentation could easily devolve into a tragedy of the commons situation. Yet MDN does exist and is an amazing resource.

Paragraphs 4 to 6 of your last comment seem to be arguing that hiring TWs is not an option for PostgreSQL. That is totally understandable. On another day maybe we would have arrived at that understanding on friendly terms and would have had a constructive conversation about how to create good docs when hiring TWs is not possible. But it's clear that my ideas aren't welcome here so I'll just stop now.

Re: The PostgreSQL documentation and the limitations of community

#26

As a regular consumer of pg docs, I vehemently agree that they are incredibly detailed, and at the same time, daunting to navigate.

If their problem is an abundance of information that is hard to navigate, they really should start experimenting with retrieval-augmented generation search experiences [1] like Supabase AI. One of the great promises of LLMs for docs IMO is the ability to synthesize info from many sources to provide more targeted answers. [1] https://technicalwriting.tools/posts/playing-nicely-with-gen... (my blog)

I haven't read your blog yet, but I'd be lying if the same thought hasn't crossed my mind :)

Re: The PostgreSQL documentation and the limitations of community

#27
post #19

Earlier quoted context omitted.

Sorry if any of my comments came off naive or obtuse when it comes to open source dynamics. If you want that apology to be meaningful, you should learn something. When you're talking about a highly successful open source project that has been going for more than 3 decades, it is beyond ludicrous for you to say, "If the project is going to succeed long-term..." It already has succeeded long-term. And you would be bett…

> When you're talking about a highly successful open source project that has been going for more than 3 decades, it is beyond ludicrous for you to say, "If the project is going to succeed long-term..." It already has succeeded long-term. Yes, your reaction here totally makes sense. Feedback acknowledged. > If you want that apology to be meaningful, you should learn something. I have re-read my earlier comments and I…

If someone gets weirdly hostile and condescending towards you on HN (sadly not uncommon), I recommend that you try to just ignore them and keep contributing. I’d like to hear what you have to say.

Re: The PostgreSQL documentation and the limitations of community

#28

Here's my perspective. I've been a technical writer (TW) for ~10 years. 3 at an IoT startup, 7 at Google. > The strengths of this process are also its weaknesses. A developer is, by definition, someone who spends the majority of their time doing development, which is to say writing code. Updating the documentation becomes a task that must be completed so that the code one has written can get committed so that one can…

Just re-read the last two paragraphs from Haas. I have a couple further comments / questions.

Quote from Haas:

> But if on the other hand I propose some change to documentation that has existed for a long time, or some kind of structural change, there's a lot more room for disagreement. Because the change isn't strictly mechanical, the right answer is a lot more subjective. And because it's a change to existing content rather than the addition of new content, many more people will be familiar with it and have opinions on how it ought to be changed, if at all. Consequently, even when some developer does take time away from writing code to try to make some larger change to the documentation, it's often an uphill battle to get anything done, and people typically have to be content with small improvements.

Honest question: do PostgreSQL engineering decisions have the same dynamics as what's described here for docs decisions? If not, what is different about engineering decisions versus docs decisions? Is it just that engineering decisions can be literally benchmarked whereas docs decisions do not seem benchmark-able? Are there any other potential explanations for different dynamics between eng and docs?

If it does indeed just boil down to "docs are not benchmarkable" then I would suggest otherwise. You can create docs benchmarks. They won't have the rigor of engineering benchmarks but they at least establish some notion of docs quality and facilitate more targeted discussions during docs reviews. E.g. when there's a disagreement between an author and reviewer the author can say, "what docs benchmarks am I not following here?" The power of that kind of interaction is that you often do realize that the docs benchmarks are incomplete and some new dimension needs to be added to them. Or do the PostgreSQL contributor docs already have some guidelines along the lines of a "content quality checklist" and it's still not working?

A rigorous effort to survey the PostgreSQL community and get a deep sense of what the overall community considers "high-quality docs" can itself be a super insightful experience. Different developer communities often need / want a different focus in the docs. That can be the foundation for a fairly authoritative docs quality checklist.

Another thing that I'm very interested in, and will need to think through deeply some other day, is this notion that once you publish a doc, you can't touch it. It happens all the time and it's really weird.

Re: The PostgreSQL documentation and the limitations of community

#29
post #2

I think the main limitation of our docs is that it mostly explains what the pieces do, not how to use them to achieve a particular goal. For example, we have pretty good documentation of all the pieces to do HA, we just don't tell people how to assemble them together. 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),…

I really miss old-school printed documentation's "Theory of Operation" section. To me it's the most useful way to bridge this gap. The technical and operations manual describe all the parts and how they function, but the theory of operation really laid out how and _why_ all of these things were structured the way they were.

It also forced the designers to think in those terms and to document the product from an overall perspective rather than a component perspective. It was high level enough to be useful, but not so high level as to be abstracted into hand holding tutorial exercises.

I feel like most modern software documentation entirely misses this component and would benefit greatly from having it.

Re: The PostgreSQL documentation and the limitations of community

#30
I was recently reading the documentation for pgcrypto to implement user authentication in SQLPage:

https://www.postgresql.org/docs/current/pgcrypto.html

The page contains the documentation of many functions, all of which raise the following error by default when you run them: No function matches the given name and argument types.

It turns out you first have to "install" them by running "create extension pgcrypto", which is obvious to someone who already knows postgres modules well, but not to anyone else, and isn't mentioned anywhere on the page!

Post reply on HN