• IdiosyncraticIdiot@sh.itjust.works
    link
    fedilink
    arrow-up
    114
    arrow-down
    1
    ·
    11 months ago

    Imagine being in a corporate environment trying to implement an OSS into your platform and having to tell your 50 yo teammate: “Oh yeah, just pop in this Discord server real quick to see any relevant info”. Instant credibility loss

    • evatronic@lemm.ee
      link
      fedilink
      English
      arrow-up
      128
      ·
      11 months ago

      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.

          • wewbull@feddit.uk
            link
            fedilink
            English
            arrow-up
            21
            ·
            11 months ago

            Not even a forum.

            Documentation is not a snapshot of a discussion. It largely falls into two categories

            • collections of facts e.g. what command line switches there are, or all the options in the config files.
            • Guides on how to use the software.

            The first is vital. The second is really really useful.

            • barsoap@lemm.ee
              link
              fedilink
              arrow-up
              4
              ·
              11 months ago

              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.

          • pingveno@lemmy.ml
            link
            fedilink
            English
            arrow-up
            4
            arrow-down
            15
            ·
            11 months ago

            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.