Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
No, Open Source doesn't hate you...

By Whizard in Technology
Tue Oct 03, 2000 at 04:04:24 PM EST
Tags: Round Table (all tags)
Round Table

I've spent the past 6 years involved in a number of Open Source/Free Software support forums, ranging from IRC channels to Usenet Groups to Mailing Lists, and I've noticed that no matter what the forum, they all have a common problem: Nobody knows how to ask questions that people can answer.

With that problem, there's a pattern: Someone who's new to Open Source/Free Software, or even someone who's new to a particular piece of software, ventures into one of these support forums, and asks a question that basically boils down to "It doesn't work! Fix it!", and doesn't get a response, and based on that, decides Open Source/Free Software sucks, or that the software developers hate them. How should we deal with this problem? Can we?


An example would be a post that came across the local Linux Users' Group mailing list the other day. A user posted that he'd just recompiled his kernel to upgrade it by a version, and the new version was running slower than the default one that came with the distribution. He gave us the kernel versions, and proceeded to ask "Are there any configuration flags I need to make it run faster?". And that's all the information we got. No information about what hardware, what the kernel configuration currently looked like, why he'd recompiled his kernel in the first place, nothing. It's essentially an unanswerable question, or if anyone did have an answer, it would be grasping at straws.

People ask similar questions every single day, and the fact that they don't get answers just makes them more and more frustrated with this new technology they're trying to make work, and in general makes Open Source look bad when compared to big corporations, with their hundreds of support-droids who have the time to sit with these people on the phone and step through the "It doesn't work!" effect to actually drill down to the root of the problem.

Some people might be willing to write this issue off with a "well, then these people just shouldn't be using Open Source/Free Software...", and I'll admit that from time to time I agree with them. But as long as there's something new and cool out there, people who aren't using the new and cool thing are going to want to try it, so why not help them out a little. You know, World Domination and all that.

Another possible reason to write this off as being a "non-issue" is organizations like LinuxCare and RedHat that sell Linux support. And while that's a valid logic, we also have to remember that some of the people who are most strongly drawn to Open Source/Free Software are the ones who can't afford to pay LinuxCare or RedHat for their support. Remember, it's Free (as in gratuit) Software.

So this brings us to my question: How should we deal with people who don't know how to ask questions? Do we just let them continue to think that "Open Source hates me"? Should we flame them in the various support forums until they figure it out? Should somebody create an Open Source Support site, sort of like Experts Exchange, but just for Open Source? Is there something like that out there already that I've missed? (I'm well aware of the Linux Documentation Project, but it's a limited set of information.) Where can we send these people for assistance when we're tired of typing the same answers to unanswerable questions over and over again?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
It doesn't work!
o rm -rf / 14%
o dd if=/dev/random of=/dev/hda bs=1024k 16%
o Kick it. Hard. 32%
o Recompile your kernel. 6%
o Reboot. 10%
o Here, try this Win2K CD. 20%

Votes: 98
Results | Other Polls

Related Links
o LinuxCare
o RedHat
o Experts Exchange
o Linux Documentation Project
o Also by Whizard


Display: Sort:
No, Open Source doesn't hate you... | 34 comments (30 topical, 4 editorial, 0 hidden)
SourceForge? (2.50 / 6) (#1)
by Mendax Veritas on Tue Oct 03, 2000 at 02:59:57 PM EST

Should somebody create an Open Source Support site, sort of like Experts Exchange, but just for Open Source? Is there something like that out there already that I've missed?
If you've missed it, so have I. I think OSDN may be heading in the direction of being able to support something like this, if they want to. SourceForge has a good start on being a "standard" place to store open-source projects online, and you can have a public forum associated with your project. That would be the logical first place to go to ask a question, if those forums are active enough, and read by the right people.

Re: SourceForge? (3.75 / 4) (#2)
by Whizard on Tue Oct 03, 2000 at 03:02:44 PM EST

I agree that SourceForge is a great place to go to ask for projects that are hosted on SourceForge. There's still a lot of projects that aren't, and probably never will be.


--
So Lawrence Lessig, John Perry Barlow, Rusty, and Prince are having dinner...
[ Parent ]
Re: SourceForge? (2.16 / 6) (#3)
by Whizard on Tue Oct 03, 2000 at 03:06:24 PM EST

And why can't we do <U> </U> tags in here? The bold makes the intent of this sentence look a lot more viscious than underlining would have. *sighs*


--
So Lawrence Lessig, John Perry Barlow, Rusty, and Prince are having dinner...
[ Parent ]
Re: SourceForge? (1.80 / 5) (#5)
by Mendax Veritas on Tue Oct 03, 2000 at 03:09:44 PM EST

Try <i> italics </i>.

[ Parent ]
K5 tag support (none / 0) (#20)
by kmself on Tue Oct 03, 2000 at 05:35:59 PM EST

If you want a specific tag supported, ask Rusty for it.

I personally far prefer italic to underline as underline tends to be confused with links in web content.

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

Re: K5 tag support (3.00 / 1) (#32)
by AArthur on Wed Oct 04, 2000 at 05:05:52 PM EST

That said, every typesetting guide I have seen, said use italics when possible, and not underlining. Underlining just makes type too hard to read.

Andrew B. Arthur | aarthur@imaclinux.net | http://hvcc.edu/~aa310264
[ Parent ]

Re: SourceForge? (1.66 / 6) (#4)
by Mendax Veritas on Tue Oct 03, 2000 at 03:07:58 PM EST

Sure, but this is perhaps one more reason why open-source projects should be hosted there. Additionally, it would be nice to be able to just go to one place to find any random open-source project, without having to go to TuxFinder or Google first.

[ Parent ]
Nonresponsive (none / 0) (#22)
by kmself on Tue Oct 03, 2000 at 05:40:40 PM EST

This is really nonresponsive to the issue raised in the article.

The problem is people who can't ask a meaningful question, regardless of forum. Sourceforge may address the issue of where to go for support. Personally, I prefer Usenet or mailing lists, and find the balkanization of support alternatives across websites to be disturbing, particularly when the sites don't readily support indexing through common indexes such as Google, AltaVista, etc (I don't know SF's own status in this regard). Though Deja's recent brokenness is even worse. <sigh>

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.
[ Parent ]

This is a common problem (3.40 / 5) (#10)
by fossilcode on Tue Oct 03, 2000 at 04:02:53 PM EST

I've supported both end-users and programmers in a variety of settings, and I can tell you that nobody knows (initially) how to write a meaningful problem report. Your example is one from somebody who wanted to solve the problem without help, and who is asking if a flag might be the cause.

Did anybody respond with the questions you posed? The biggest challenge is in getting people to tell you the details that they didn't realize could be important. ("I installed this fix, and now my widget won't start up, but I didn't do anything else! Oh wait, we DID move the whole datacenter last weekend and we're running on a new release of the OS, but I doubt if that's important!")

This isn't just an open source problem, it's pervasive in all software environments, closed-source, open-source, in-house developed custom systems, you name it.


--
"...half the world blows and half the world sucks." Uh, which half were you again?
(jk) (none / 0) (#16)
by Moebius on Tue Oct 03, 2000 at 05:08:57 PM EST

Who: Me What: My computer (it's slower) Where: In my bedroom When: After I put the new kernel in Why: I DONT KNOW!?!!! (that's why I'm asking)

[ Parent ]
Not a problem with open source... but people. (3.87 / 8) (#11)
by porovaara on Tue Oct 03, 2000 at 04:16:34 PM EST

In my experience (a lot with computer stuff and a lot with other things such as the ancient world) people just don't know to ask questions. I am constantly amazed at how incomplete the common question is... its like once people got out of the 3rd grade that forgot that 5Ws rule. I used to think it was out of ignorance or even just being dumb but as I get older I see it for what it really is; lazy. People only want to put forth exactly enough effort to get something done. If they can ask partial questions and the person answering still figures out what they wanted they then only had to put forth a small amount of effort. Of course this behavior has just been reinforced so they will continue to do this in the future.

What can you do? I dunno but what I do is even when I know exactly what someone is talking about when asking me a half-ass questions I drill them back with questions until what they want is determined in mind numbing detail. A few times of this and they either stop asking me questions (yay!) or come to me with a complete concise question.



Teach Them Better Behaviour (3.66 / 6) (#12)
by Phil Gregory on Tue Oct 03, 2000 at 04:38:08 PM EST

I think that is an element of the Neverending September syndrome (for lack of a better term). In general, the average end user has little idea about what is needed in a good bug report. Largely, this is because they don't understand programming, and no one has pointed out to them what good bug-reporting behaviour is.

The solution is education. Remember that ignorance is curable. Reply to the person, telling them that they haven't given you enough information to help them with their problem. (Be sure to tell what information you do need.)

Yes, putting together a good reply takes some time (and I have been guilty of ignoring bad questions rather than taking the time to enlighten the poster), but it seems that it's really the best solution. It would help if there were some resource on "How to ask for help/submit a bug report" available. (There may be, but I didn't find anything in a somewhat cursory web search. (Yes, I know how ironic that last sentence was.) Any enlightening URLs would be appreciated.)


--Phil (Still working on training his users to give him good bug reports.)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
Not just a computer support thang... (4.76 / 13) (#13)
by Simian on Tue Oct 03, 2000 at 04:43:17 PM EST

As a librarian, I assure you that this problem is an ancient and hoary one. In my world it's called the dreaded 'reference interview'. That's when someone tries to express to you what they want to know when they don't know what they want to know, or even if that's really what they want to know, or how they'd know if they didn't know to begin with. :^0

You should look at some of the library literature on this subject ('reference interview') if you really want to figure out how to extract enough information from people to answer a question before they clam up.

Let me summarize: Don't be confrontational. Don't make the questioner feel stupid, in any way, shape, or form (nothing kills an interview quicker than that.) Answer the first question or two with a few questions of your own, or restate what you think they said. Relate the question to the questioner's context. Why do they want to know x? School project? Just because it's there? Because they're going to be fired tomorrow if it doesn't work? This will affect the interview profoundly.

Basically, you need to not take people's first approximation of a question literally. If people knew how to ask the right question, they wouldn't need to ask for help. (of course, there are those who're just so fsckin' lazy they'd ask you to look up their own phone number...) If you can get someone to understand why they asked the wrong question, I guarantee they'll listen to the rest of what you have to offer.

In short: ignore the question, figure out the real 'information need'.

jb




"As I would not be a slave, so would I not be a master. This expresses my idea of democracy. Whatever differs from this, to the extent of the difference, is no democracy." Abraham Lincoln
How to deal with vague questions (4.50 / 8) (#14)
by RadiantMatrix on Tue Oct 03, 2000 at 04:56:33 PM EST

In every 100-level psych class, we learn that people hate the lack of feedback -- we hate to be ignored. Most people would rather be attacked than ignored.

I don't advocate attacking those who pose vague questions, though. How long does it take to post a reply saying: "could you provide more information? Here's what I need to know to help you." Another tactic that works well (we'll use the cited "kernel recompile" question): "Well, have you read the Linux Kernel Guide yet? It has a lot of information - at the least it will help you ask more specific questions."

One of my gripes is people who want answers, instead of wanting to know where they can find answers - and the best way to encourage the latter is to point them to resources without their asking.
--
I'm not going out with a "meh". I plan to live, dammit. [ZorbaTHut]

Linux Advocacy HOWTO (4.37 / 8) (#15)
by simmons75 on Tue Oct 03, 2000 at 05:06:52 PM EST

Yeah, it's specific to Linux, but some things apply to other operating systems/programs. Basically, it's a guide to being polite. :^) I notice a need for more politeness.

Case in point: I was sitting on #linuxhelp on irc.openprojects.net. Some guy came on asking about alternatives for Hummingbird eXceed. We started naming off X servers that are free (beer|speech). Someone caught on to the fact that, despite the poorly worded question, that this person wanted to control a Win32 box from a UNIX box. Tells us all to shut up, and tells the person who asked the question that if he mentions eXceed again he'd kick and ban the poor bastard. Through private chat I figured out that yes, that's what the guy wanted to do, but this person (goes by the nick "sgi"...don't piss this person off or you'll be banned...try to avoid saying "hi" :^) that had been railing on him to *not mention* eXceed, the entire time, was railing on the person for not answering...because this person was talking to me. Yeah, sgi was right (use VNC), but sgi wasn't going to convince *anyone* by railing on people.

If you want to help people get better mentally equipped to use Linux, you have to learn patience. Patience, and politeness. Otherwise, please don't bother; you're doing more hurt than help, even if you're right.
poot!
So there.

Cistron RADIUS (1.00 / 3) (#17)
by Farq Q. Fenderson on Tue Oct 03, 2000 at 05:13:00 PM EST

There's an OSS radius daemon, called Cistron RADIUS, and I've been on the mailing list for some time. I really appreciated the no-BS style in which the main developers respond to this: "read the faq, run it in debugging mode, and give us more info." They're training people to ask better questions -- even if they could make a good guess, if there's not enough info in the question, then they won't give an answer. If it goes on long enough, they tend to get pissy. I *like* this. Users simply need to be taught how to ask the right questions, I think every forum like this should keep the same policy as the Cistron RADIUS mailing list -- that way people will catch on.

The downside is that people tend to think that the maintainers are bastards, but if every forum behaved like this there would be no choice but to realize what's going on.

farq will not be coming back
Cistron RADIUS (3.80 / 5) (#18)
by Farq Q. Fenderson on Tue Oct 03, 2000 at 05:13:19 PM EST

There's an OSS radius daemon, called Cistron RADIUS, and I've been on the mailing list for some time. I really appreciated the no-BS style in which the main developers respond to this: "read the faq, run it in debugging mode, and give us more info." They're training people to ask better questions -- even if they could make a good guess, if there's not enough info in the question, then they won't give an answer. If it goes on long enough, they tend to get pissy. I *like* this. Users simply need to be taught how to ask the right questions, I think every forum like this should keep the same policy as the Cistron RADIUS mailing list -- that way people will catch on.

The downside is that people tend to think that the maintainers are bastards, but if every forum behaved like this there would be no choice but to realize what's going on.

farq will not be coming back
Post more data (4.75 / 4) (#19)
by kmself on Tue Oct 03, 2000 at 05:30:10 PM EST

Support groups are a dialog, not a single-shot question-answer forum. If someone posts an insufficient question, or seems to be missing the fundamental factors while asking a high-level question, I've got no problem saying "repost with more detail". I do this routinely. I've even created a couple of scripts to snarf relevent system information[1]. Likewise, I'll suggest that an question appears to be aimed at solving some more fundamental problem

It's also a problem I've seen with many different types of software, and other, support columns. The problem is essentially this: you're dealing with someone not only doesn't know how to accomplish a desired task, but probably has little idea as to what that task, or its alternatives and implications, are. They also have to realize that they are the person in front of the system, with the most information about its current state. The rest of the world may have much more general knowledge on the subject, but without accurate and pertinant data, its value is low.

If the original poster can't be bothered to follow up with the required information, I'll drop it (hey, it's not my problem). The first part of problem resolution, however, is identifying where the problem is. This in itself is a non-trivial task.

Typical incomplete questions, off the top of my head:

  • My system hangs on booting. Followup questions: where does it hang, what's on the screen, does it reboot, provide a prompt, respond to any inputs (including keyboard LEDs or network status lights if a NIC is present)?
  • How do I get Linux to log in and run program. You don't. Refer to /etc/init.d/ (Debian and derivatives) or /etc/rc.d/init.d (Red Hat and derivatives) and the SysV init process.
  • X Windows doesn't work -- I get a blank screen with a checkered background and a big X. X did work, you now either need to start a window manager or try one of your three (yes, three) mouse buttons to see if you've already got one started.
    A personal favorite, paraphrased:
  • I've installed Linux and started it, now it's giving me a line that looks like "[root@localhost:~]# ". Do I need to enter a registration number?. Reinstall Windows. Now.

Online user-based support isn't for everyone. Computers are complex devices, Linux is a relatively complex OS -- though you can get up and running with relatively little experience or knowledge. My line is: Linux has a steep learning curve, but a high payoff function. If the user is not interested in making the investment, they won't see the reward. This is OK. There is a rich stock of "dumb user" tech support humor. It has some basis in fact.

And finally, some spot-on, solid advice on how to report bugs was posted by Jeff Covey at Freshmeat in his February 26, 2000 article How to Report Bugs Effectively. Read it, and refer newbies to it.

Notes:
[1] Specifically, a kernel-bug reporting script, available on request.

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.

updated URL for "How to Report Bugs Effective (none / 0) (#34)
by mac on Sat Aug 04, 2001 at 09:28:28 PM EST

The URL seems to have changed. Also, the essay in the article is actually written by Simon Tatham. Here is the new URL: http://freshmeat.net/articles/view/149/ (for reference, this new URL is valid as of 4th of August, 2001)

[ Parent ]
Make them learn how to think (1.66 / 3) (#21)
by maketo on Tue Oct 03, 2000 at 05:39:57 PM EST

Give a man a fish and he is not hungry for a day. Teach a man to catch fish and he will never be hungry again. The modern (commercialized/american) idiotic spoonfeeding way is to break down every activity/component to the smallest piece so that you can have experts (err, "consultants") making money in fields unimaginable just 10-20 years ago. If you want to be one of those then write FAQs that even cover how to plug the cord into the wall. Or sit down and dedicate yourself to HCI or AI in hope you will create something intelligent enough to be different and actually easy to use. Or just go to bed every night thanking God you are not one of those brainless ones posting questions without even doing their homework first.
agents, bugs, nanites....see the connection?
Could Eliza Help? (2.75 / 4) (#23)
by mahlen on Tue Oct 03, 2000 at 06:00:08 PM EST

When i worked as a lab assistant for beginning Pascal classes at Berkeley in the late 1980's, a CS prof (Mike Clancy) suggested that there were six questions you could ask a struggling student, that, if they answered them as best they could, they would likely figure out for themselves why their program doesn't work. I don't have the list, but it was something like "What did you change? What results were you expecting and why?" and so on. He suggested that I build an Eliza-like program that could ask these questions, solicit responses, and then, either lead the user to the problem, or at least train them to know what info is required to answer such a question.

So, I'm wondering if a similar system, possibly combined with the rote answers that someone else suggested in these comments, could go at least part way to making this easier. Or at least, the answers to Linuxliza could be presented as the email. Would this help? (And no, i'm not volunteering to write this).

mahlen

It's against my programming to impersonate a deity!
--C3PO [Anthony Daniels]



read the docs.. (4.00 / 2) (#25)
by wolfie on Tue Oct 03, 2000 at 07:04:16 PM EST

hm everyone's elses comments have pretty much got this issue wrapped up but what the hey

I agree with what many people have said.. don't be too rude... remember that they don't know what they're talking about or they wouldn't be asking.. etc..

Of course there are exceptions, every so often you'll see the person who's a real piece of work, and have the attitude of "I don't want to read the docs, fix it for me" Which might work Ok if they're paying me $50/hour.. but not over IRC/mail/etc

In my experience.. the majority of people who are new, are pretty unfamiliar with the concept of man/info pages and the like.

It may seem quite obvious to *US* that you should read manpage foo, but newbies may not even know how to access them, majority of issues I encounter on IRC can be solved either with "Well did you man foo", "Did you read this [url]", "Did you change something?" etc.

As far as the original topic of the post goes.. I actually do know some people who avoid Debian simply because they're too lazy/ignorant to figure out how to use it (Slackware users), and thus *hate* the distro as a result.. granted this is a fairly immature reaction, it does occur.

Whether or not you care about those users is another matter, I don't think this phenomenon is new to open source, or even to software, Remember programming VCRs ?



There's documentation?!? (5.00 / 1) (#31)
by DebtAngel on Wed Oct 04, 2000 at 02:43:20 PM EST

Sing it, brother, sing it.

I come from a Windows background, but I came in nice and early, when Office came with real manuals, VB came with the reference manual (can you believe they *sell* those now? For Can$80?!?), and the help command worked in DOS.

No more sir. Things are supposed to be so easy in the Win9x world that you don't need good documentation. So when users that started with Win9x come into the Linux world, they don't know how to access the manpages because in the Windows world, manpages don't exist. They don't even have anything comparable. And even if the docs are there, they suck so much that they are essentially useless.

Point people to the documentation, and the documentation shall set them free. And hopefully they'll learn something.
Is this post not nifty? Sluggy Freelance. Worship the comic.
[ Parent ]
How to answer (4.66 / 3) (#26)
by mindstrm on Tue Oct 03, 2000 at 07:23:55 PM EST

As any good teacher would. If they didn't provide the required info, ask for it in more detail. Ask nicely.

'Were there any flags I should set?'. Hmm. That's actually quite a reasonable question. If he's not that familiar with linux, but sort of computer literate, it may seem likely that a new kernel version might have some important flag everyone but him might know about.

Instead of griping about what information he didn't give, why not ask for it?

After all, no matter what, questions can almost never be answered as simple question/answer pairs. A conversation must ensue. *especially* on software projects.

You see this in an IT department every day. 'My app won't run'. "Well, what happens when you run it?' 'It won't work' well, does it give you an error? "yes" well, what is it? "Ohh.. I'll go try it again and write it down. I guess that WOULD be important.". they don't mind finding out; they simply didn't think to ask because they don't do this every day.

Also.. do not take the exact wording of the question to literally. I can guarantee that nobody can ask a question outside of their realm of expertise right the first time. You simply don't have the perspective.

An example.. hmm.
The other day, someone asked me 'Why is my internet slow?'. Now.. there is temptation to hit the moral high ground and explain all the details they don't understand about the internet, and marvel at how they could ask such a stupid question.. or you can stop and think 'hey.. obviously it's some specific thing they are doing that's slow, and they just call it 'internet' because they don't know it the way I do'. Simply ask them to describe exactly what they did, and work from there. Works every time.


Hmm.. a thought (3.50 / 2) (#27)
by puppet10 on Tue Oct 03, 2000 at 09:02:29 PM EST

For web based forums wouldn't it be possible to create a default form with some general information that is generally necessary for diagnosing these types of problems (Hardware configuration, kernel version, gcc/libc version, etc.) possibly tailored for the specific forum they are posting in to at least try to generate the most basic necessary information (and maybe allow saving of this info in a user profile). Also allow an advanced user to skip this form if they think they know how to properly ask the question. (Possibly this could be extended to newsgroups with a post describing what information the poster should provide at a minimum, with the understanding that this might need to be extended for the specific problem being described)

Admittedly it wouldn't be perfect but it would allow a new user to understand the basic infomation needed to diagnose this type of problem and if they don't know that information to at least be able to ask where to find it if it is necessary.

Also I agree with the other posts stating the need for more polite discourse in these forums, yes the same questions get asked over and over (if it is that common politely direct them to a FAQ on the web and if that doesn't answer their question to ask again describing what part of the FAQ they can't understand) and the person asking the question can be impolite (tell them politely that they won't get any help being rude).

Fundamentally though troubleshooting a software/hardware rpoblem is an art form and it's hard to try to lead someone you know well through it even in real time over the phone let alone someone you don't know (level of expertise, don't want to condescend or confuse) in a slow format like a forum or newsgroup.

What happens when you reply with a question? (4.00 / 1) (#28)
by goonie on Wed Oct 04, 2000 at 01:35:09 AM EST

I answer support questions on a mailing list regularly, and when I reply to questions with a question perhaps 50% of the time you never hear from that person again. What I'd really like to know is why - have these people solved their own problem, or have they stopped using the program in disgust?

HOWTO on asking questions? (3.00 / 1) (#29)
by mac on Wed Oct 04, 2000 at 10:08:27 AM EST

Perhaps we should create a HOWTO for users new to Linux and the various support forums, which would outline how to ask questions in the most effective manner, such that they have the best chance possible of being answered? I realize this material has been discussed in the Linux Journal, some newsgroup and mailing list FAQs, and other places, but I think we need a centralized version of this info. Perhaps even distributions might want to automatically "cat" this HOWTO right after they finish installing... Just a thought.

My Experience (4.00 / 1) (#30)
by Simon Kinahan on Wed Oct 04, 2000 at 11:00:33 AM EST

I used (during a previous very dull job) to hang around on the Linux newsgroups and pick up on the random tech support questions. At that time I was supporting a small home network for a few friends and had a fair idea (having started in the position of having a CS degree and no admin experience) of the problems most people will run into.

Except in one exceptionally difficult case, I did manage to extract enough information to help the person, or at least point them in the right direction. In general, all questions need to be followed up with a request for details. Someone who knows enough to present you with all the details you need to answer the question on the first shot can probably answer the question themselves. Another reason initial questions tend to be vague is that people do not know whether they'll get an answer, so they do not invest much time in the initial question. If you really want to help, and feel there is a reasonable chance that you can, the best thing is to follow up the initial request for help by a private email asking for more details, so the requester knows they are getting personal attention. This is why most megacorps do tech support by phone: it feels personal, even though it is usually useless.

From the tone of the question, and the reposne to a request for further detail, it is usually possible to judge someone's technical level. From that, generally, you can judge whether it is possible for you to explain how they can do what they are trying to do. If someone doesn't know what a file is, they're not going to manage to configure sendmail, right ? If the person lacks basic underlying skills and information, the best course of action is usually to direct them to resources that will give them the information they need to start with, and advise them to come back to their immediate problem later. A similar approach is also best (certainly better than guessing) when people ask you things you really don't know but might be able to find out. Its better for them to read the docs than for you to do it and then try to explain, as they then have a resource they can refer back to later.

If you do get a question you can answer yourself from personal experience, common sense rules apply. Use plain English as far as possible, explain concepts that are likely to be unfamiliar, be polite, don't condescend, and emphatically never ever flame.

Simon

If you disagree, post, don't moderate
Try managers. (none / 0) (#33)
by aphrael on Thu Oct 05, 2000 at 03:25:59 AM EST

Unfortunately, it's not just people looking for technical support who have this problem. I had a very frustrating conversation today with a new project manager who wanted to know when I was going to be able to work on feature [x] of project [y]. Starting with the observation that I wouldn't even be able to get to it until early December, I attempted to explain what the feature was, why it is risky, and why I think, if we are shipping project [y] before date [z], we should drop the feature. Yet I was *completely* unable to tell if she was following the technical explanation, and her response showed no evidence of her having understood it, either.

Yeah, I know, that's OT, but I wanted to rant.

Both are symptoms of a more global problem: people don't want to have to think if they can avoid it. I noticed this a lot during my four years in technical support; people would call up wanting an answer but not being willing to think about it at all --- they were working on [x], [y] happened, and they just wanted [y] to stop happening because it was interfering with [x]; they saw it as a distraction, not an interesting puzzle in and of itself. A lot of that is a result of not having enough time --- understanding takes time and effort, and if you're already behind schedule when that problem pops up ...



No, Open Source doesn't hate you... | 34 comments (30 topical, 4 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!