Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
let someone read it who never had any contact with the project, then count the amount they say "wtf"
-
Good documentation needs to include context up to a specific point - without belittling.
E.g. it should be obvious that when you set localhost in a net address for binding, it's not reachable from the outside. Still you should mention it, because not everyone might knew this.
For me, good documentation is written in a neutral / funny way.
As an don't to do it, please - example:
https://vuejs.org/guide/...
The Vue documentation is trying _far_ too hard for my taste to achieve a personal connection. If you would take out all these "don't be afraid"… "Vue is awesome" bla blocks, it would be far more readable.
Plus a few of these blocks sound way too cocky.
The second thing I really dislike in the Vue documentation is the lack of explanation of adverbs.
https://vuejs.org/guide/components/...
"There is a default 200ms delay before the loading component is shown - this is because on fast networks, ...."
fast. What does it mean? There is a specific time mentioned (200 ms) so it should be possible to precise this.
The last thing regarding Vue documentation: It is nice when you have short pages by using a TOC (table of content) plus linking - what's not so nice is that when you can't download the documentation fully.
A pdf export / single page HTML isn't hard. I can read content very fast - short pages and constant clicking references becomes an "annoying" thing.
(Maybe I haven't found it… but I don't see it in the TOC).
What's good is the full text search.
I think it is not that hard to turn my subjective criteria into 3 categories for objective criteria:
language, structure, accessibility
I'd value language with 40 %, structure with 30 % and accessibility with 30 % .
Without structure (e.g. a good TOC, splitting pages) you just have a wall of text… without accessibility it becomes a mind boggling frustrating adventure to digest the text. Without proper language... Shit. -
JetBrains and MS use approval metrics: "Was this helpful?"
Seems as good as anything. -
atheist99912ySome languages you can include testable code snippets in the documentation, python has doctest built in, numpy and pandas put this to good use
-
No, because - although this isn't necessary for usability - the ideal documentation is subjective. It's a publication that's written with a specific type of reader in mind, and everyone else will find it either a bit verbose or a bit obscure. Ideal documentation is multilevel. Rust for example has the main book for newbies, the autogen docs for quick factual information, the optimization book, the unstable book, the macro books, I believe there's also a crate author's book, and a metric fuckton of other topical official long form resources intended for either sequential or random access reading by a particular audience. However, because these are separate resources for separate audiences by separate authors, it's infeasible to compare their quality. The newbie book and the macro book have non-overlapping target audiences.
Related Rants
How do you measure documentation quality? Do you think there's any way of making it objective?
question
projects
documentation
quality