Etiquette (was Re: left justify)

[Fairlight]

Four score and seven years--eh, screw that!
At about Fri, Jun 10, 2005 at 11:38:50AM -0700,
Jeff Harrison blabbed on about:
> 
> I have a couple of problems with this.
> 
> #1  The original poster should always try to be as
> complete as possible when describing the problem.  You
> should include FP version, OS, sample code, etc. where
> possible.

Agreed.  See attached.

> #2  I don't think it is necessary to flame someone
> when they do not do this.  A simple "please provide
> more information" would do the trick don't you think?

That was a flame?  You have a really loose definition of flame.  When I
let loose a flaming-arrow-of-death flame, there won't be any doubt in
your mind.  This was, at best, a coffee warmer.  And in this particular
instance, no, I -don't- think what you propose will do the trick.  We see
30-ish plus message-long threads to achieve what could probably be done in
five or six tops, -if- the OP would actually do the appropriate amount of
research and supply adequate information.  It's happened multiple times in
the last few months, and it's getting ridiculous.

People should either supply enough accurate information, or not expect
help.  Period.  Many of us have better things to do than draw people out to
the point where they're useful to us, and hence to themselves.  I'm sure
Ken, for example is just -wallowing- in extra free time for which he has
no better use than helping Dennis trace problems that aren't elucidated
clearly.  Hey, if they're paying, fine...take your time, it's your dime.
If you want it for free, don't waste our collective spare time.  LTS.

And in this case, it was patently absurd to 'describe' a 'bug' in which two
potential problems existed, but were mutually exclusive.  He just didn't do
his homework, and wants someone to bring out the silver platter.  Maybe I'm
tired of seeing people's good will and natures walked on.

There's just too much lousy reporting going on in general to be of any
decent use without days of drawing people out, -forcing- them to give the
requisite answers by repetition of the same question over and over (Ken's
approach may be more polite than mine, but it takes far longer than a sharp
kick to the head--I prefer expediency) or by rephrasing the same thing 20
different ways for them to "get it" that they aren't helping us help them.

While I certainly don't dictate policy for the list (or anywhere except my
own company), I would posit that if someone -can't- completely fill out
the form attached, or isn't willing to supply all of this information,
***up-front***, in -some- format, they shouldn't be bothering to ask
for help at all.  It's not the format that matters.  It's the content
it implies should -always- be present in any kind of trouble report,
unofficial or official, which matters.

Mr. Burke's comment was also read, and my only comment is that it's his
prerogative to hold whatever views he chooses.  I -am-, however, trying to
make things -better-, not worse.  Subtlety has failed everyone for months.
I'm down to the direct approach at this point.

Could be worse--I could totally write some people off.  That's the final
step--when I decide there's absolutely no hope, I may as well /dev/null
their email that comes through the list.

mark->
-------------- next part --------------
filePro PROBLEM REPORT FORM
===========================


   filePro Version:  

  Operating System:  

        OS Version:  

  Modules affected:   dclerk [x]    rclerk [ ]   dreport [ ]   rreport [ ]
                     ddefine [ ]   dscreen [ ]   dmoedef [ ]   dxmaint [ ]
                       other [ ]   Specify:

  Problem Synopsis:  


 Specific Symptoms:  


      Reproducable:  [x]     Sporadic:  [ ]


Steps to Reproduce:  



 File Availability:

[x]     Files necessary for reproduction of the problem are available upon
        request.  (Public or private posting.)

[ ]     Files necessary for reproduction of the problem are available at
        the following URL  at your convenience.  (Public or private posting.)
        URL:  

[ ]     Files necessary for reproduction of the problem are attached.
        (Private Email only, last-ditch transmission effort.)

[ ]     Files necessary for reproduction of the problem are not available
        because the problem appears to be sporadic and non-specific.

[ ]     File are not necessary because the problem is not related to
        specific files.

[ ]     Files necessary for reproduction of the problem are not available
        because my company or I can or will not divulge even test data.
        Take your best shot, but we won't hold our breath.