elb's Blog

Help us help you

In the various forums through which the Pidgin developers provide
support for building and using Pidgin, we see some very clueful
users who are enjoyable to work with, and a lot of users who make
support truly painful. In my opinion, there is one major thing
that users can do to help us make their Pidgin support experience
more enjoyable for all involved parties, and it's almost completely
effortless!

Now, before I go any farther, let me clarify what I mean by
"clueful" in the above paragraph. We do not ask that our users
know anything in particular about computers, operating systems,
package management, or any given topic; it is necessary that a
user have a certain fundamental knowledge from which we can work,
but that knowledge, in the right hands, is relatively minimal.
Instead, I am talking about clue related to receiving and making
use of help given. This is more a life skill than a computer
skill, and it seems that it is sadly lacking in an unfortunate
proportion of circumstances. I hope that this is more an
ignorance than a primary trait, and that it can be corrected via
some simple education.

Definitions out of the way ... what is that major,
important skillset in being helped? This isn't going to come as a
surprise to anyone, but it seems that a lot of people don't think
about it:

The most important skillset for effectively receiving help from
a support forum is listening and following directions.

I can't claim to know what the root cause is which causes this
process to fall down, but there do seem to be a few false pretexts
under which supplicants often labor. They are:

"I just need a little bit of help, it'll save time if I ignore
suggestions that I know are unrelated."

This comes up unbelievably often. The first thing to
remember to fight this tendency is that you are coming for
help because you have a problem you cannot solve, and the people
who are helping you are "experts" in the field. You may be
entirely convinced that your problem is unrelated to a particular
topic, but the developer who is helping you quite possibly knows
something that you do not. Often, more often than I care to think,
we ask a user to check some particular setting, feature, or aspect
of the environment, and they refuse, on grounds that they "know"
it to be correct/unrelated/etc. Sometimes this position is
correct, but often it is not, and when the user is
finally convinced to look into it, the problem can be
immediately rectified and everyone involved can move on. This
particularly comes up when a user believes that the reason the
particular question is being asked is to spite their personal
favorite operating system, window manager, distribution, or
whatever is perceived as being related; while the characteristic
in question may in fact be the reason a developer is asking, the
question is probably being posed because there is actual reason to
believe the problem exists. Stepping around the tendency to become
defensive and simply answering the question will allow everyone to
move on, either having solved the problem, or looking for the next
most likely cause.

"I've already looked at all possible causes, I just need
an oracle to tell me what's wrong. I can't be bothered to check
for those causes again, it'll just waste time."

This is really related to the previous point — if you really
had checked everything, and your conclusions were truly correct,
you wouldn't need to be consulting the experts, would you? That
aside, it is staggering how often a setting that a user "has
already checked," and "knows" is correct, is mis-set and causing
all of the problems they want to ask about. Again, if a developer
or support person is asking about a particular setting, option, or
compile flag, it is probably because it is known to be related. A
quick double-check won't hurt anything, and it might save a lot of
time in the end. Note that a common behavior that
support personnel see is a response of "yeah, it's set correctly,"
and "yes, I just checked after you asked," when the user has
not checked, believing they already know the answer.
This is particularly frustrating, and quite embarrassing (for the
user) when the user is finally convinced to look at the option and
admit to having lied, when it is not set as believed.

"I don't understand the questions I'm being asked, but
asking for clarification will just make me look dumb. I'll make
something up, instead."

This characterization is almost certainly an oversimplification,
but it sure appears to happen often, to those who
provide support. If someone who is trying to help you asks a
question, and you don't understand the question or don't know how
to answer, please ask for clarification. The more quickly the
correct questions can be answered, the more quickly the root
problem can be identified.

"I'll supply some helpful guesses as to what I think the
problem is, and start answering questions once I'm done. The
developers may not have thought of my insightful
predictions."

This is a hard one, because sometimes the user does
know something that the support person does not, and it really is
salient — but in general, the less informed a speculation
is, the less it is worth. The support person you are dealing with
very likely has more informed speculation, so hear them out before
you start second guessing with your own intuitions. A related
point is...

"I've just made some major changes to my
software/hardware/network/something, but I'm sure that's not
relevant. The fact that I need to seek support for something which
worked until about the same time the change was made is probably
coincidental. I don't need to mention the changes."

Wow, does this one happen all the time. There is
tension between this and the previous mindset, but in many cases
one can distinguish the difference. Rather than coming in and
saying something like "My Pidgin just stopped working on Google
Talk, can anyone help?," when you know you just performed a major
system update, a more helpful question might be "My Pidgin stopped
connecting to Google Talk after my last reboot; I had just
upgraded about a dozen system packages before the reboot, but I
can't find the problem." If the upgrade is likely to be relevant,
the support person now knows about it; if not, no harm was done,
and help can still proceed appropriately.

"This support person suggested that there is a problem
with a piece of software/hardware that I really like. I can't
stand for this!"

I don't know where this attitude comes from, but it certainly
prevents a lot of users from being effectively helped. All I can
say about it is, remember that "Your <X> is broken" is not a
reflection upon you, your mother, your upbringing, or anything of
the like; it simply means that your <X> is broken. This may
be a transient state, a correctable situation, or a simple
incompatability with no fault to be laid; it might also be a true
fault in <X>. In any of these cases, protesting that
<X> is truly the best and not to be slighted upon is
probably not going to fix the problem. Remember also that it, even
if the person helping you hates <X> and tells you so (and,
they probably have good reason, whether the circumstances from
which that reason arise are relevant to you or not), that really
doesn't affect you — if you're convinced of the
incorrectness of that statement, the best think you can do is get
your current problem fixed and then figure out what
can be done about the dislike of <X>, if you still care.
Refusing to be helped simply because you are using some piece of
software, hardware, or distribution that the person helping you
has identified as having a problem is beyond ridiculous. Becoming
belligerent or fractious about it is even more so.

These aren't the only traps to watch out for, but they help
illustrate mindsets which are unhelpful to receiving effective
support. Generally speaking, be open minded, try not to make
assumptions or pre-judge the situation, and be prepared to receive
advice from the domain expert at hand. Even when said expert is
wrong about a particular tactic, answering their questions and
proving that is the best way to identify the situation and help
them come up with a new hypothesis. Support personnel cannot be
expected to land upon the correct solution the first time, every
time, but we do do our best — and I think, in the context of
Pidgin, our best is actually pretty good.

Finally, remember that the person who is helping you is completely
uncompensated for their time or effort. Being short, rude, or
evasive with them is not only frustrating, but likely to cause
them to give up on you. For most of us, open source development
and support is a labor of love, not compensated labor; when it
stops being fun, we stop being driven. Fortunately, most of us
find identifying the cause of a tricky problem interesting, so if
you are polite and helpful, your problem is likely to be solved
relatively rapidly.

A related topic is how not to give bad advice, or, how to
helpfully help the helpers, directed at users who are not central
to the project but who wish to assist in support. That is a story
for another time, but the advice in this piece bears on the
situation.