Re: reporting requirements

[Ilya N. Golubev]

 No one is getting paid,

Unfortunately, the attitude, once established here, nearly inevitably
spreads to other situations, even exactly those of paid support.  It
would be nice to be able to nuke it in all assigned to paid support,
to automatically force everybody manifesting it to go back to unpaid
occupations, with free / open source software or other.
Unfortunately, no way to ensure that is known.

 expend the effort to do so

This tries to represent things as if some terrible effort is required.
Generally it is not so.  Instead, it requires much less work than
writing the voluminous, useless (and hurting - to some, not me) reply
that started the thread.  For exactly the same reason: it is inherent
ability of humans.

 way things work

Or, more often, do not work.


 you learned a lot more than

Acceptable only with `:-)': again, learning about tool internals (let
alone misfeatures or even bugs) is not desirable at best.


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, handled gracefully (as
many RFC say).


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: reporting requirements

[Philip Guenther]

On Fri, Aug 22, 2008 at 1:40 PM, Ilya N. Golubev [EMAIL PROTECTED] 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


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make