Re: reporting requirements

[Philip Guenther]

On Fri, Aug 22, 2008 at 1:40 PM, Ilya N. Golubev <address@hidden> wrote:
...
>> expend the effort to do so
>
> This tries to represent things as if some terrible effort is required.
> Generally it is not so.

Oddly enough, that's not my experience.  When someone doesn't provide
enough data, the responder has three options:
A) write a completely general reply.  For any non-trivial question,
this quickly becomes
    impossible.
B) make assumptions.  If the assumption is wrong, then the answer is
worse than useless,
    at it starts the search in the wrong direction.
C) ask for more data.

In my experience, the biggest difference between someone good at
debugging and someone so-so at debugging is that the former person is
MUCH more aware of what assumptions they are making and performs
sanity checks on those assumption as they go.  If you're going to
insist that people make assumption about your setup because you aren't
interested in describing it, then expect misleading answers.


> Instead, it requires much less work than
> writing the voluminous, useless (and hurting - to some, not me) reply
> that started the thread.

Huh.  You seem quite sure about how much work it takes for me to write
different types of replies.  Interesting.


...
> Agree that, personally, normally would have checked more before
> posting.  Why it was unacceptable to do that in that particular time
> with that particular issue is improper here.  My point is that users
> getting in such situations are inevitable time after time, and that
> such a behavior of users should be allowed,

Right, instead of ignoring them, we ask question to help narrow down
the problem.


> "handled gracefully" (as many RFC say).

Heh.  Many of those RFCs also specify error responses to send when the
other end does something incorrect/non-compliant.  Guessing what the
other end meant is practically *banned* in many IETF protocols due to
the horrible experiences of some early protocols.  I recommend Paul
Vixie's published papers about BIND and how the "handle gracefully"
mentality resulted in security holes in DNS.


Philip Guenther