9front - general discussion about 9front
 help / color / mirror / Atom feed
From: "Lyndon Nerenberg (VE7TFX/VE6BBM)" <lyndon@orthanc.ca>
To: 9front@9front.org
Subject: Re: [9front] 9front man pages
Date: Fri, 08 Mar 2024 09:40:00 -0800	[thread overview]
Message-ID: <fa0140e6a2103c7a@orthanc.ca> (raw)
In-Reply-To: <23C3A366562C9ACE92010D2234E3B6D3@eigenstate.org>

My biggest concern with these sort of well meant attempts to help
with documentation is this:

  Writing *good* documentation about a piece of software
  requires you to have an intimate understanding of that
  software, down to its core.

Without that, you will make mistakes.  And quite often what sets
apart an amazing manpage from a good one is how it expresses the
subtleties of the software it is describing.  That requires a deep
understanding of the subject matter.

For the most part, the Plan 9 manpages are well written as they
stand.  A few suffer from ESL syndrome and could use some copy
editing to remove ambiguity.  But a wholesale drive-by edit of
everything is wrong, IMO.

My major gripe with all the manpages is how the options are documented.
I will disagree with Rob Pike until the day I die that they should
be described in-line as they currently are.  Just like he has
red-green colour blindness problems, I suffer from diplopia (very
bad double vision) that makes spotting those flag definitions nearly
impossible.  I firmly believe options should be explicitly called
out in a single section in tagged paragraph form (i.e. the idiomatic
format used in all the BSD manpages).  But that's a bikeshed for
another day.

In summary, I encourage you to find ways to contribute to the
community.  If you want to help with documentation, I would start
out by picking one or two manpages you feel need an update, then
proposing your changes.  I suspect you will learn a lot from the
ensuing discussion.  There is a lot of history behind the style and
conventions used; you can't ignore that.

--lyndon

  reply	other threads:[~2024-03-08 17:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08  4:47 eso
2024-03-08  5:07 ` Jacob Moody
2024-03-08  5:28   ` Roberto E. Vargas Caballero
2024-03-08  9:01     ` qwx
2024-03-08 11:30       ` hiro
2024-03-08 11:34         ` hiro
2024-03-08 11:35           ` hiro
2024-03-08 16:01           ` eso
2024-03-08 16:24             ` qwx
2024-03-08  5:23 ` ori
2024-03-08 17:40   ` Lyndon Nerenberg (VE7TFX/VE6BBM) [this message]
2024-03-08 18:30     ` hiro
2024-03-08 23:20       ` umbraticus
2024-03-08 23:50         ` ori
2024-03-09  0:40           ` sl
2024-03-09  1:08             ` hiro
2024-03-09  1:36               ` Stanley Lieber
2024-03-09 11:01                 ` sirjofri
2024-03-10 19:16                   ` Lyndon Nerenberg (VE7TFX/VE6BBM)
2024-03-10 21:05                     ` sirjofri
2024-03-10 21:11                     ` hiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fa0140e6a2103c7a@orthanc.ca \
    --to=lyndon@orthanc.ca \
    --cc=9front@9front.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).