And they do a great job of keeping docs for older versions available. They're on version 15 and they have back to 7.2 available.
If I can't figure out how something works in another DBMS, I usually read the comparable postgresql docs to get a good overview, and then go and re-read the docs for what I'm actually using to fill in the implementation-specific bits.
There are great examples of top-down authored docs in this thread, but Arch's docs manage to be comprehensive while being largely community contributed. Odds are if I have a question about any Linux distribution, I can find an answer for it in Arch's docs. As a result, they also often have considerable localization.
You can ask what a specific shortcut key does, you can ask what a specific lisp function does. Everything is linked together (so you can get from the shortcut to the function and vice versa) -- there's a direct link into code/implementation so you can traverse various levels of abstractions.
When I contributed a module to melpa last year, the biggest back and forth was about documentation and description of what everything does.
The doc system makes Emacs a joy to use and really makes it a stand out.
https://documentation.divio.com/
The idea is that there are four different goals that should be accomplished independently.
The Rust Programming Language: https://doc.rust-lang.org/book/ (the Rust standard library also has very comprehensive documentation)
Cocoa architecture: https://developer.apple.com/library/archive/documentation/Co...
Python: https://docs.python.org/3/tutorial/index.html (also pretty good standard library docs)
Scheme R5RS: https://standards.scheme.org/official/r5rs.pdf
Racket: https://docs.racket-lang.org/
SQLite: https://www.sqlite.org/docs.html
Point in case https://learn.microsoft.com/en-us/dotnet/api/system.linq.enu...
Redis command docs are excellent and you can try the commands on the site itself!
Also love that they include the availability by version and the time complexity and tag the commands such as @slow for potentially slow commands, etc.
I think you'd benefit by finding retrocomputer people and asking them about docs they've seen to find the best technical writing of the century.
I don't have a short list of IBM Mainframe docs, but those are probably "the best documentation money could create" in the 50s-70s.
Easily second best would be the DEC TOPS-10 Software Notebook Series which in my experience was a set of 20 binders and in one shelf it contained all you need to run a major 80s minicomputer operating system including apps.
What 80s DEC documentation did VERY well, was every doc was planned out intelligently and in detail by actual users to make sense to a professional sysadmin on the job. Unlike "sales/marketing" driven docs, the software notebook series TRULY understood its audience of professional sysadmins. I also feel that 80s DEC documentation had the best intros in technical writing I've ever seen. Intros are underrated and the author(s) need to make a "contract" with their reader before throwing detail at them. Take for example, volume 6 or so of the dec-10 software notebook series which has the ALGOL programmers's reference guide with the best intro ever. "This is where you start" should be the most carefully designed and written chapter of the docs, not a filler chapter. In summary, don't skimp on outline and don't skimp on writing a real intro.
Personally I like some of the Tandy/Radio Shack Z-80 manuals. Perhaps the extended basic manual for the model III, or the 6809 assembly book they resold are the pinnacle of late last century technical writing for a more general audience.
Retrocomputing is a fun hobby that extends far beyond technical writing critique, obviously.
The text itself is also well written. It's clear and doesn't feel lacking in detail.
As an example, here's the doc for the backslash operator that solves a linear system: https://www.mathworks.com/help/matlab/ref/mldivide.html
[0] https://www.gnu.org/software/emacs/manual/html_node/emacs/in... [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/in...
1. Reference docs that describe the behavior of the thing and the API
2. Example code and tutorials that show you how to use the thing
3. Architecture docs that describe how the thing works at a high level and how you integrate it into your system
4. Operational docs to tell you how to run the thing in production with backups, monitoring, debugging, and scaling
5. FAQ and anything else
Lots of docs tend to focus on only a few of these. But you've got really great docs when you bring these all together.
http://glench.github.io/fuzzyset.js/ui/
The interactivity really lets you play around with the library to understand how it works and sharpen your knowledge by testing edge cases.
1. https://plaid.com/docs/errors/invalid-request/#invalid_field
The Elasticsearch Guide:
https://www.elastic.co/guide/en/elasticsearch/reference/curr...
WorkOS: https://workos.com/docs
Twingate: https://www.twingate.com/docs/
Railway: https://docs.railway.app/
Planetscale: https://planetscale.com/
Evervault: https://docs.evervault.com/
Mintlify is also the best alternative to ReadMe or GitBook that I've found.
Say what you want about the product, but the documentation is certainly top-notch.
Edit: I think pretty much all the GNU documentation (and most of texinfo documentation) I saw was nice, but as particular and common examples, there are manuals for Emacs and Elisp, GNU libc, coreutils, bash.
Additionally the way they structured their API responses is brilliant. The API response data structures are deeply nested which means you have to perform less API calls to get related data (which often occurs with payments data).
The new SvelteKit docs: https://kit.svelte.dev/docs/introduction
In addition to being thorough, it has personality.
https://starwars.fandom.com/wiki/The_Stele_Chronicles
SimEarth had a spiral bound 200+ page manual that went in to great detail, and was also a joy to read.
Kubernetes for sure. When anyone asks for a good place to get started with understanding k8s - I tell them the docs should be all you need, then go get hands on.
The stuff is world class.
I use it for Mathematica. Its notebooks are full of editable examples.
They have the best documentation that I have come across and come to rely on.
They are extremely well written, and contains examples for each method.
I really like them.
(There are other projects with better «reference style» docs)
I'll start off with the worst one: React.
Arch Linux, SQLite
It provides multiple layers of documentation along multiple dimensions.
Say you're an end-user. Where do you start? Maybe you read the tour on the webpage. Maybe you watch one of the countless videos. The first time you open Emacs, your cursor is on a link to the tutorial. The tutorial is interactive and allows you to save and continue later. The system sets you up for success in learning.
The tutorial leads you to the manual, written in Texinfo which is published in multiple formats. Within Emacs, you can use the info browser (you can access the same from the terminal outside of Emacs) to search and navigate the documentation. All manuals and references are also published to Html (as single page to facilitate searching terms across sections), as well as PDF and bound paper copies (available from the FSF). There is no single interface to the documentation. The interface can be a web browser, the info browser, your thumb on a physical page, etc.
Info/texinfo is amazing. Documentation is indexed. This allows you to search for terms, as well as section headers and keywords. If a term doesn't appear explicitly within the text or within your current document, it may be included as an index. What would fail in the pdf or html is found this way. You can search across documents (for example, the user manual vs. the programming reference). The apropos function even compiles search results as a table of contents.
Navigation of the documentation is robust. Forward, backward, up, down, top. Within Emacs, this is even better. There are lookups for functions, variables, and symbols. Lookups within the various documents (manual, reference, do strings, etc) is quick and integrated. Because the cost/pain of lookup is low, as well as terms indexed, separate documents feel like one.
Each function and variable has a quick-to-access docstring. The docstring may include links to other useful features or reference to other documentation. Documentation always has a link to the source code.
A lot of what I've said addresses the interface to the documentation. It's also important to consider the use-cases for the documentation and its intended audience. There are tutorials to introduce high level concepts (assuming zero prior knowledge), there are references for in-depth explanation of component details, there are docstrings to explain specific functionality, and there is the source code, two clicks away and able to modified immediately. When pictures are helpful, they're there. Manuals include examples, offset from the main text.
There are clear, published guidelines for how to write documentation. I've found those generally helpful.
There are mailing lists which are excellent documentation. The rules for participating, such as avoiding top posting and organizing topics in threads, aid comprehension and accessibility. The mailing list documents why decisions are made. They document the history of an idea.
If you've ever wondered why some people are fanatical about Emacs, an underlying reason is that information about it is really easy to get at and is accessible.