Re: Reality Check
% 2) READ and UNDERSTAND the error
> I'm sure there is one. Also switching
> verbose mode on and trying again might
> be a good idea to know what the app was
> actualy doing.
IMHO a user might not *understand* an error message, what is useful to a developer as an error message might be totally unmeaningful to the casual user: "Wrong pointer to param &frobnicate of method foobar" or even a more user-friendly "Passing bad parameter in configuration file. Found int, expecting string" might not be something people understand ("what is a string, anyway?").
> 4) Narrow down what the problem is
> Try again with different
> settings/options/files and try to narrow
> down the submodule which might cause the
> problem. It's a difference to know
> whether it was the "whole
> program" or just a small part of it
> that might doing something wrong.
This might help, but do you prefer to have a bug fixed or a lazy guy not reporting (or being devnulled) because he didn't try all the possible configuration/compiler/modules switches?
> 5) Type your error message/problem
> description into google
> You might laugh, but just a c&p of
> the error message into google will get
> you a few hits of people who already had
> the same problem with possible
IMHO, if other ppl solved the problem either you know or you want to know in order to put the solution in documentation. Then, reply writing "the solution is in FAQ 3... Thanks for reporting anyway". It's 1 minutes and makes people feel good about you and your project.
> 9) Providing additional information
> If you are asked to provide additional
> information or to try something, then
> you should write a reply to the mail
> which is a) properly formated (the
> things mentioned above plus proper
> quoting, NO TOFU!) and b) with correct
> mail headers that provide In-Reply-To
> and References fields. Don't use broken
> shit like Webmailers or Outlook, they
> just break the thread and the other side
> will have a hard time to get what your
> previous mail was about.
People might be less netiquette-prone than you. Do you think this is a good reason not to solve problems in/with your software?
> 10) Send a thank you
> If someone took a lot of time to help
> you with your problem than you should
> thank him
I agree, and think that the developer should thank the reporter as well... :)
> Sometimes i think that we should charge
> everyone sending a bugreport a few
> dollars, just to cover those 5 minutes
> it takes to quickly read his bugreport.
> Maybe then they'll think twice about
> writing "it does not work, please
> help me". Beside, it would cover
> the costs of buying new hardware for the
> servers or maybe even make us rich :)
They are (trying to) work for you: trying to let you know that your program has what they think is a bug. That is either because *it is* or because they didn't find out it wasn't. That's a problem, anyway. And the developer should try to fix it, imho.
> % I couldn't agree more. The
> % automake/autoconf
> % tools are a nightmare to use, poorly
> % documented,
> % and hard to maintain. As a developer
> % really
> % struggled to make just a few
> % modifications to my
> % project's auto* setup (created for me
> % KDevelop).
Ever tried to read, say, openoffice generated HTML?
IMHO, autotools work just right, are portable, effective, and once you understand the concept, you just use it easily... Maybe get GNU Documentation about it?