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.

As further recommended reading, I suggest How to Ask Questions the Smart Way, by Eric Raymond, and Why I Hate Advocacy, by Mark-Jason Dominus.