My analysis of some recent discussions.

["Eric M. Monsler" <emonsler at beamreachnetworks dot com>]

"Robinow, David" wrote:
> 
> Larry, have you considered just shutting up when you don't know the answer?


> > From: Larry Hall (RFK Partners, Inc) [mailto:lhall@rfk.com]
(snip)
> >    5. If I know nothing about the subject, I keep my mouth shut.


You know, I considered a smart-ass answer about whether David Robinow
had read all of Larry Hall's email.  But then I did notice something in
the two phrasings that could help explain what has been a dominant topic
on this list recently:

"What constitutes helpful responses?"

It seems to me that there is a fundamental disconnect in terms of how
responses are perceived.  

- There is a class of people for whom responses of Larry's type 1,3, and
4 are helpful.  They consider that in those cases, Larry does indeed
"know something about the subject", even if he does not "know the
answer."  These are people willing and able to read, ponder, experiment,
draw conclusions, and attempt solutions based on the information given. 
In short, willing to debug their problem, whether it be with code or
configuration.  While they may dearly wish that their question was
directly answered, they have been (at least marginally) helped and are
typically aware of it.

- There is a class of people for whom the same responses are not
helpful, who interpret them to mean only "find out for yourself", who
are not willing to debug, who need explicit, step-by-step instructions
either from scratch or whom wherever they happen to be.  These are
typically described as "newbies", but that does not cover it; someone a
complete newbie to cygwin who was comfortable in their DOS and Win3.1
config files, and in their Win* registry settings, might well be in the
first category even if unfamiliar with cygwin and even *nix in general.

These are harse, extreme descriptions of the endpoints, most people fall
somewhere in between.

The chief difference between the two catergories is *mindset*.  I know a
very good developer, wrote good code, debugged it well, comfortable with
IDE's or with Emacs/gcc, who could not get cygwin working because he did
not read the setup directions.  This was for playing around with code at
home for fun, but he was not willing to work at getting the environment
set up.  Fine, he bought VC++.  

Conversely, we have seen many newbies appear, burst questions onto the
list (sometimes initially including ones obviously in the FAQ or
documentation), and then gradually have success in both using cygwin and
presumably in finding information for themselves.  There may be a
"Thanks for all the help" email, and then they presumably go off the
list, become lurkers, or even occasionally offer their own answeres to
newbie questions.

The biggest hurdle to moving from the second category into the first, I
believe, is believing that you are able to.

The current state of cygwin, with the setup.exe and the current
documentation, is sufficient that many people in the second category are
able to use it successfully.  The problem is those in the second
category who encounter difficulties, or require something non-standard. 
People in that category who will not move towards the first category, or
(as we have seen some examples of) feel that the work involved in being
a self-debugger is an unreasonable expectation, are doomed to be unhappy
with the cygwin "product" and community.

Message to dedicated contributers: Don't let those folks get you down!

Message to folks somewhere between category 1 and 2: The regular posters
are attempting to answer a great many questions in a finite amount of
time; they believe their response will help you, if only in giving you
information with which to *rule out* possible sources of the problem.


Eric "Social Critic" Monsler

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/