on 11/14/02 9:17 AM, Peter Palmreuther <[EMAIL PROTECTED]> wrote:

> Have you _ever_ understood what qmail uses /var/qmail/users/* for?
> No? Than you lied and you haven't read qmail documentation.

The information in the rest of your email is very helpful.  Incredibly so
for me, and I thank you for it.  However, do you realize how full of
assumptions most explanations (e.g. helpful explanations from people who
know things) and documentation are?  Full of assumed knowledge and assumed
points of view.  So often this makes even extensive documentation almost
useless for asimilating even the basics - unless you have lots of time on
your hands and can study and study and study until the obvious hidden
information finally dawns on you.

I find that in particular information about the internet and about server
software is more buried right in front of us all than any other area I have
ever studied.

So the bottom line is no one really needs to prove anything about how hard
someone else has studied the documentation.  Some of us have studied until
it hurt.  Others reach their threshold of pain much sooner.  But let's face
it, learning from documentation is often a pain.  A little dialog with
someone can help almost effortlessly to bring forward the implicit points of
view and create seeds for the process of assimilation, so that returning to
the doc can then be fruitful.

Documentation writers can learn from this.  And learn and learn and learn -
I believe without limit.  Documentation can be much better.  It is hard to
be without attitude, and to rid oneself of all the hidden assumptions of
being involved in a particularly community of discourse.  Documentation is
ideally written for everybody.  That is an impossible task, but it can be

I appreciate this list and the help it provides to supplement the inevitable
limitations of documentation (limitations that are experienced very
differently by different people needing to learn and get work done).

I am just lobbying for the cause of relieving us all from any need to even
so much as clarify what someone has failed to do in using the documentation.
This would leave our helpful information totally uncolored by anything
besides help, which I think would be a good step.  After all there is no
need to defend the documentation.  Like everything it was hard work to write
it, and tries to meet an impossible goal.  It is good to be aware of both
all the time.  The "best" of us (and who is that anyway?) will miss the
obvious often enough whether writing or reading.

Kurt Bigler

Reply via email to