My contribution to the thread follows.  (^&

 * An overview is defintely lacking.  The INSTALL document is an
   intimidatingly large document, IMHO.  I am a fairly technical type,
   but found the installation document a little much.  Yes, lots of useful
   stuff in it.  Yes, once you know how to install NetBSD you don't need
   the document at all, and it all seems straightforward.  No, I wouldn't
   just throw any of it out.  But if you only have one computer, you have
   to print it out for reference the first time that you install the
   system (well, I did).

 * The personal OS history is of dubious value.  Everyone will have
   different histories.  Mine was:

       TRS-80 -=> Amiga -=> BillOS '95 -=> NetBSD/i386

   (Somewhere along the way, some exposure to LINUX, Mac's, SCO UNIX,
    SunOS and perhaps a couple of others could be included---but I never
    had any on a computer of my own, and didn't use them much.)

   Including your history will make it personable, and may make it feel
   more inclusive for those who share your background.  But people who
   don't may tend to suspect that the documentation will be colored from
   your point of view.  Also, a personal history just doesn't seem
   appropriate for a tutorial.  It would only make sense, IMHO, if you
   are unabashedly ethnocentric about your background when writing the
   tutorial.  But being so ethnocentric would greatly limit its value,
   IMHO.

   Instead of putting a personal history into a new user guide, I might
   suggest submitting it to Daemon News; they have a monthly feature for
   just such tales.  (^&

 * Now might be a good time to repeat a suggestion that I made a week or
   two back when it was discussed whether to include an easier-to-use
   editor in the install base.  I have a sample ``help'' and ``help-ed''
   pair of scripts lying around that spit out a screenful of text (sized
   to an 80x25 (roughly) console).  The idea is simple: Provide a minimal
   bit of help in a ``help'' command.  The purpose is to bootstrap the
   user by pointing them to some information when they may not have a
   fully working system yet.  (E.g., I believe that some versions of
   NetBSD have shipped such that after installation they boot directly
   to multi-user---but 1.4.1 certainly does not.  You HAVE to edit a
   text file from single-user mode, and the chances are if you are new to
   NetBSD, or UNIX in general, you will be stuck.)

   Like the BIOS which is needed to get the system on its feet (and
   possibly the bootstrap loader in NetBSD), this bootstrap info is not
   intended to be part of the general information system that the user
   draws on.  It merely covers the barest basics so that the user can
   stumble on instead of crashing to a halt.

 * Perhaps it was hyperbole, but someone spoke of ``what little''
   documentation we have.  While the documentation isn't always perfect,
   and certainly is more geared for reference than tutorial, it is still
   of substantial volume and (by and large) substantial quality.

   In fact, the biggest problem that I have with them goes back to the
   remark about an overview: Often you can learn what you need by reading
   the appropriate man page, even if you are a relative newbie (though you
   may need to read several cross-references in the process).  The big
   obstacle is FIGURING OUT WHICH MAN-PAGE YOU NEED TO READ.  Even if you
   know about apropos(1), finding the right man-page can be a problem;
   you may not even know that you _need_ (or could use) information on
   some topic until you know about the topic.

 * Someone objected to yet another documentation format.  While a part
   of me agrees (if reasonable, it should be fit into existing
   mechanisms), there's also:

   We have several non-man-page documents already.  Most notably the
   /usr/share/doc/ directory.  Though those are mostly/entirely in
   *roff form, they are not pulled up via ``man''.  There are also
   examples, which are another (legitimate) form of documentation
   (/usr/share/examples/).

   Then there is some info on building device drivers that you can get
   on the web pages which (as far as I know how to find) is not covered
   in an installed system.

   Then of course there are packages...  (Hey, we even have info as part
   of our /usr/src/gnu/ tree, now...or did we always?)

   The point: Our documentation is already non-uniform.  It is not a
   fair argument to complain that the documentation system will be
   fractured by creating a non-man-page newbie tutorial.  It might be
   fair to say that such a document would hinder any effort at re-unifying
   the documentation---but that is making the tacit assumption that a
   single documentation form _is_ desired.

 * I don't think that a project should be knocked down just because it
   may make the system accessible to those with relatively little
   background.  A mainframe system administrator or a Mac programmer
   should be equally welcomed as a LINUX or FreeBSD convert, IMHO.  There
   is no reason, and no percentage, for being selective in that regard.
   Yet, a Mac user may have a harder time dealing with the command line,
   and my limited exposure to mainframes indicates that _those_ beasts
   are generally worlds away from UNIX.


In sum:

I like the idea.  An overview is needed.  If practical, it should probably
fall within some of the existing documentation structure---but the nature
of the man-pages is to provide an answer to a more or less informed
question.  An overview or tutorial serves a TOTALLY different purpose.

The personal history bit should probably not go in unless kept to no more
than a paragraph (even then...).

I still like the idea of a handful of one-screen help-files that get
displayed by typing ``help'', ``help-ed'' and perhaps one or two
others.  (^&  (I admit to having some bias on this last point, however.)


Re. reviewers/proofreaders:

I might have time to review drafts of the tutorial/overview if you would
like to send copies to my mailbox.  No promises, but it can't hurt and I
might be of some use.


  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com