unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: George Clemmer <myglc2@gmail.com>
To: Nils Gillmann <ng0@n0.is>
Cc: "Clément Lassieur" <clement@lassieur.org>, 31786@debbugs.gnu.org
Subject: bug#31786: 'pre-inst-env guix --version' is not updated by new commits"
Date: Sat, 16 Jun 2018 12:06:33 -0400	[thread overview]
Message-ID: <87k1qyaf7a.fsf@gmail.com> (raw)
In-Reply-To: <20180615203018.clbx3kqjqfzcyink@abyayala>

Hi Nils,

Nils Gillmann <ng0@n0.is> writes:
[...]
> Long text short nonsense: you end up with lots of work and long books if you
> do it right. It should be done this way. Maybe if not directly applied we
> could collect the proposals somewhere in the repository? I've recently
> started to strip out a whole chapter with repetive installation instructions
> in GNUnet. A while back I would've argued for keeping it, that we really
> need to cover and guide every case.
> Some projects have written "An introduction to..." books to lead up to
> the manual.
> In my opinion access to knowledge should be easy and without much 'rough
> edges' to get it.
> Do we keep it selfcontained? Reference other books? A middle path? It's
> difficult to get it right if you don't have the time to think about this
> as a fulltime job.
[...]
>
> Do we really have to assume that everyone has the same skilset who wants
> to get involved? Not about this topic, but in general? I think the assumption
> that we share the same knowledge is difficult. Part of the excercise is to
> reach out, actively, in person. Another part is to try and do it in text (be
> it on a website or a (new) chapter in a manual).
[...]
> Counter-proposal: What about additional man-pages? man has enough sections
> to provide well written, to the point, collection of notes for such day-to-day
> usage. I'm not against your proposal, just another suggestion in context of
> what I've written above.

I think the Guix strategy, AIUI, of putting 99.9% of the doc effort into
a single doc via Texinfo is very efficient. INFO and HTML reach the two
extreme user types: hackers that use INFO and people use that google.

Partitioning the problem into sub-parts is tempting.  But it increases
the risk of a sub-part drifting out of date at which point it is better
to not have had the sub-part ;-)

The Guix "mico-man-page" effectively eliminates a sub-part. Hackers can
use INFO and people who google don't use man, so I think the micro-man
approach is fine.

I think the most promising and productive way for Guix to improve the
end-user-friendliness of the doc is to use end-user "support incidents"
to drive doc additions. At the end of an incident the user question is
fresh in your mind, you have information that you know could have been
helpful to at least one user, and you capture the support effort into
something longer lasting.

- George

  reply	other threads:[~2018-06-16 16:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-11 18:01 bug#31786: 'pre-inst-env guix --version' is not updated by new commits" George Clemmer
2018-06-12 13:21 ` Ludovic Courtès
2018-06-12 18:28   ` George Clemmer
2018-06-12 20:33     ` Ludovic Courtès
2018-06-13  0:51       ` George Clemmer
2018-06-13  6:54         ` Ludovic Courtès
2018-06-14  1:39           ` Leo Famulari
2018-06-14 15:18             ` George Clemmer
2018-06-14 16:10               ` Clément Lassieur
2018-06-14 16:45                 ` Clément Lassieur
2018-06-14 16:36               ` Ludovic Courtès
2018-06-15 19:13                 ` George Clemmer
2018-06-15 20:30                   ` Nils Gillmann
2018-06-16 16:06                     ` George Clemmer [this message]
2018-06-15 22:02                   ` Ricardo Wurmus
2018-06-15 22:24                     ` Ricardo Wurmus
2018-06-19 16:47                       ` myglc2
2018-06-16  1:35                     ` George Clemmer

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

  List information: https://guix.gnu.org/

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

  git send-email \
    --in-reply-to=87k1qyaf7a.fsf@gmail.com \
    --to=myglc2@gmail.com \
    --cc=31786@debbugs.gnu.org \
    --cc=clement@lassieur.org \
    --cc=ng0@n0.is \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).