The loss of credibility is not because it’s discord,. specifically.
It’s because the project thinks a chat platform is an appropriate way to document a project. I would feel the same way if someone told me to get on IRC for docs, or Slack.
Actually the first should be the latter, not in the sense that there shouldn’t be a list of switches, a list of options somewhere, or no terse sum-up docs for all those little things, but that those sum-up docs should be the header to a guide.
I may be getting old but I think earlier UNIX had that, and we kinda lost it: Back when programs had few switches the man page would have a header explaining the command tersely – “foo grobnitzes flobboxes” or such, two or three options described equally terse, then you’d get into usage and examples. Nowadays, where GNU less lists its options as
, note the fucking alphabet in the beginning, it’s pages upon pages of terse technical definitions in the rest of the manpage. (Yeah I know less probably doesn’t need extensive usage docs it’s pretty self-evident but my point stands).
We have hypertext now. This can contain a gazillion links to this. And please no no gnuinfo I still don’t know how to navigate that thing, I barely know how to exit it. Lynx and w3m prove that it’s possible to do intuitive design with links in the terminal, do better. Me wanting to quickly look stuff up is not the right time to insist I learn your awkward pet documentation interface, Richard.
Wikis always seem to produce second rate documentation, except maybe the ones that are designed specifically around software projects. There are any number of tools out there that produce better documentation and it can be stored alongside the source code in a git repository to avoid drift between the code and the associated documentation.
The loss of credibility is not because it’s discord,. specifically.
It’s because the project thinks a chat platform is an appropriate way to document a project. I would feel the same way if someone told me to get on IRC for docs, or Slack.
Matrix for example would be better.
Nope, should be on a forum or wiki or normal doc
Not even a forum.
Documentation is not a snapshot of a discussion. It largely falls into two categories
The first is vital. The second is really really useful.
Actually the first should be the latter, not in the sense that there shouldn’t be a list of switches, a list of options somewhere, or no terse sum-up docs for all those little things, but that those sum-up docs should be the header to a guide.
I may be getting old but I think earlier UNIX had that, and we kinda lost it: Back when programs had few switches the man page would have a header explaining the command tersely – “foo grobnitzes flobboxes” or such, two or three options described equally terse, then you’d get into usage and examples. Nowadays, where GNU less lists its options as
less [-[+]aABcCdeEfFgGiIJKLmMnNqQrRsSuUVwWX~] [-b space] [-h lines] [-j line] [-k keyfile] [-{oO} logfile] [-p pattern] [-P prompt] [-t tag] [-T tagsfile] [-x tab,...] [-y lines] [-[z] lines] [-# shift] [+[+]cmd] [--] [filename]..., note the fucking alphabet in the beginning, it’s pages upon pages of terse technical definitions in the rest of the manpage. (Yeah I know less probably doesn’t need extensive usage docs it’s pretty self-evident but my point stands).
We have hypertext now. This can contain a gazillion links to this. And please no no gnuinfo I still don’t know how to navigate that thing, I barely know how to exit it. Lynx and w3m prove that it’s possible to do intuitive design with links in the terminal, do better. Me wanting to quickly look stuff up is not the right time to insist I learn your awkward pet documentation interface, Richard.
In comparison to discord, but true.
Wikis always seem to produce second rate documentation, except maybe the ones that are designed specifically around software projects. There are any number of tools out there that produce better documentation and it can be stored alongside the source code in a git repository to avoid drift between the code and the associated documentation.
They are only second rate if not used.
Your wiki can be hosted in a VCS. gitit I think is the original and as it uses pandoc it’s probably what you want to use. (Not so) random example wiki powered by it.
Two big advantages over plain text in VCS: You get to look at hyperlinked and whatnot output, and non-programmers can contribute.
Might as well be a telegram group chat.