samba - Feb 2003 - OT: suggestion! (was Re: !!ATTENTION NEWBIES!!)

> -----Original Message-----
> From: Robert Adkins II [mailto:radkins@impelind.com]
> 	I have read a few more of your responses. It appears that you
> believe wholeheartedly that your more advanced questions are going
> unanswered simply because of the volume of lower skilled questions. 
I see it go both ways.

The really "interesting" problems that uncover new bugs in the Samba
code
generally get a lot of attention.  (Sometimes forwarding them to
samba-technical can be productive, incidentally.)

The easy problems generally get answered eventually, too, even if it's just
with a pointer to the right section of the manual.

It's the ones in between, the tricky problems that are difficult to work
out, but probably not actual bugs, that sometimes tend to languish
unanswered.

On Mon, 17 Feb 2003, David Brodbeck wrote:
>
>
> > -----Original Message-----
> > From: Robert Adkins II [mailto:radkins@impelind.com]
>
> > 	I have read a few more of your responses. It appears that you
> > believe wholeheartedly that your more advanced questions are going
> > unanswered simply because of the volume of lower skilled questions.
>
> I see it go both ways.
>
> The really "interesting" problems that uncover new bugs in the
Samba code
> generally get a lot of attention.  (Sometimes forwarding them to
> samba-technical can be productive, incidentally.)
Obviously, any real bugs need to be fixed asap. Many bugs are NOT
interesting - just a right royal pain!
> The easy problems generally get answered eventually, too, even if it's
just
> with a pointer to the right section of the manual.
I can not speak for anyone else, but my approach is to look carefully at
the posting (typically about 10 seconds). I answer if:

	- the user is new and shows they have tried to solve the problem

	- the user is experienced and made an obvious error

	- some else's help is wrong

	- the problem is not well documented either in samba code or
		through the mailing list archives

	- the problem pertains to something I can contribute something to

I do NOT answer if the answer can be readily found. This demonstrates that
the enquirer is lazy and wants to abuse my time and energy.
> It's the ones in between, the tricky problems that are difficult to
work
> out, but probably not actual bugs, that sometimes tend to languish
> unanswered.
You will note that sometimes I do NOT provide the answer, but I do ask a
question that contains the answer.

Example:
--------
Recently someone who had a clear name resolution problem was not using
WINS. They did not want to use WINS: I do NOT have time to educate every
subscriber who does NOT WANT to use WINS as to it's benefits in a NetBIOS
over TCP/IP environment. Some of my help in this area has gone on for over
10 interchanges - and I am tired of that. So I simply sent back a reply
that asked "Why are you sure you do not want to use WINS?" - from that
point forward it's up to the recipient to do some more home work.
>From my analysis of my January respsonses the average time I spent per
reply was around 13 minutes. Most replies take about 1-2 minutes, but a
few too MUCH longer. Several took over 1 hour.

I do carefully take note of problem areas and then try to capture useful
hints and answers. These get fed back into documentation. Most of the new
documentation is going into Samba-3.0.0. Hopefully the 3.0.0 release will
set a new standard in helpful documentation.

We need to be realistic though: the new documentation will largely close
gaps in older samba functionality. It will take a while to prepare and
include this same level of utility in documentation pertaining to new
features. This is a slow but beneficial process and is a key reason why I
often ask people who have solved a problem to document their solution and
to contribute it. Unfortunately, most people we help do NOT contribute
back in this manner (but human nature is like that).

- John T.
-- 
John H Terpstra
Email: jht@samba.org