Several recent messages to the list have passed my "too vague"
threshold, past which I just delete them. Answering vague questions is
hard enough to justify in the best of times, much less when you're
cleaning up from a tornado. This particular message was just the one
that happened to push me into ranting on the subject. No insult is
meant: I know I've asked my own share of vague questions in the past.
This is just advice on how to have your questions answered more often.
First off, I'd like to point out that questions can be broadly grouped
into two categories: "why" and "how". The first category includes those
questions wherein the questioner is seeing an unexpected result and wants
to understand it. The canonical example of this is the "Why do I get the
following error message when I do 'foo'?" The first part of Joerg's
message to the list is another example:
Joerg Maschtaler <maschi(_at_)chemie(_dot_)fu-berlin(_dot_)de> writes:
I have a mail and i want it to be handled by a shellscript (in sh).
The problem is:
procmail tries to execute the shellcommands in the script and produces many
error messages and break off the run of the script without result.
When asking a question of this sort, the most critical you can do is
provide exact information about what you're doing. A blow-by-blow
description along the lines of "When I type the command 'blah blah
blah', procmail prints the following errors and dies" is much easier to
work with than the statement "procmail produces many errors messages".
What did _you_ type, and what did procmail do in response? Cutting and
pasting the command line(s) and error messages directly into the mail
message is almost certainly the Right Thing to do. While sometimes the
error message by itself is sufficient to pinpoint the problem, don't
count on it.
These questions often call for simple and specific answers,
but in many cases the answer may see an easier way to tackle the
underlying problem, in which case the question morphs from "why
doesn't think work" into "how do I make this work better". This
new questions is an example of the second category of questions.
Where questions of the first category are all about details, questions
in the second category focus (or should focus) on _intent_ or the
implementation there of. You know what you want, and you know what you
have, and you know where you want to be, but you don't know how to get
there.
In these questions, a clear description of what you want as the end
effect is of critical importantance. The fewer assumptions you make
about _how_ the problem will be solved, the better. You should answer
the questions "what do you want?", and maybe also "why do you want it?"
and let 'us' (the readers of the list) tackle the "how". If you've
tried something already, or if you have special resources or tools that
may help you should mention them. If you have extra requirements on
the solution (say, procmail is the local mailer, so the solution can't
change the arguments being passed to it), then mention that as part of
the "what", not as a "how".
Most questions are in this category, or should be. Indeed: a common
'newbie' mistake is to ask a "why" question when a "how" question with
a "I've already tries this" clause would be more appropriate. For an example,
consider the first sentence in Joerg's message:
I have a mail and i want it to be handled by a shellscript (in sh).
That's the _real_ problem for which Joerg needs a solution. Procmail
may or may not be a part of that solution -- something that may not be
obvious given the mailing-list.
I hope the above speech made sense to everyone. Hopefully clearer
questions will lead to more (and clearer) answers.
Philip Guenther