How to Ask Questions The Smart Way

Ken Roach

Lifetime Supporting Member + Moderator
Join Date
Apr 2002
Location
Seattle, WA
Posts
17,446
Today I came across a very useful document regarding participation in Forums like this one. It is specifically about PCs and Open-Source software, but it is just as applicable to Automation.

It should be read by every first-time poster, and will be useful (and entertaining) to long-time members as well.


 
To summarize the before-mentioned article,
How To Ask Questions The Smart Way, by Eric Steven Raymond

Before You Ask

Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
  1. Try to find an answer by searching the archives of the forum you plan to post to.
  2. Try to find an answer by searching the Web.
  3. Try to find an answer by reading the manual.
  4. Try to find an answer by reading a FAQ.
  5. Try to find an answer by inspection or experimentation.
  6. Try to find an answer by asking a skilled friend.
  7. If you're a programmer, try to find an answer by reading the source code
When You Ask:

Choose your forum carefully

Be sensitive in choosing where you ask your question. You are likely to be ignored, or written off as a loser, if you:
  • post your question to a forum where it's off topic
  • post a very elementary question to a forum where advanced technical questions are expected, or vice-versa
  • cross-post to too many different newsgroups
  • post a personal e-mail to somebody who is neither an acquaintance of yours nor personally responsible for solving your problem
Use meaningful, specific subject headers

On mailing lists, newsgroups or Web forums, the subject header is your golden opportunity to attract qualified experts' attention in around 50 characters or fewer. Don't waste it on babble like “Please help me” (let alone “PLEASE HELP ME!!!!”; messages with subjects like that get discarded by reflex). Don't try to impress us with the depth of your anguish; use the space for a super-concise problem description instead.

One good convention for subject headers, used by many tech support organizations, is “object - deviation”. The “object” part specifies what thing or group of things is having a problem, and the “deviation” part describes the deviation from expected behavior.

Stupid: HELP! Program doesn't work properly on my laptop!

Smart: RSLogix does not run on my laptop

Smarter: Rockwell RSLogix version 5.5 will not run on my Dell Inspirion Windows 2000 laptop.

Write in clear, grammatical, correctly-spelled language.

More generally, if you write like a semi-literate boob you will very likely be ignored. Writing like a l33t script kiddie hax0r is the absolute kiss of death and guarantees you will receive nothing but stony silence (or, at best, a heaping helping of scorn and sarcasm) in return.

If you are asking questions in a forum that does not use your native language, you will get a limited amount of slack for spelling and grammar errors — but no extra slack at all for laziness (and yes, we can usually spot that difference). Also, unless you know what your respondent's languages are, write in English. Busy hackers tend to simply flush questions in languages they don't understand, and English is the working language of the Internet. By writing in English you minimize your chances that your question will be discarded unread.

Be precise and informative about your problem
  • Describe the symptoms of your problem or bug carefully and clearly.
  • Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor's distribution and release level (e.g.: “Fedora Core 4”, “Slackware 9.1”, etc.).
  • Describe the research you did to try and understand the problem before you asked the question.
  • Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
  • Describe any possibly relevant recent changes in your computer or software configuration.
Do the best you can to anticipate the questions a hacker will ask, and answer them in advance in your request for help.

Courtesy never hurts, and sometimes helps

Follow up with a brief note on the solution

If You Can't Get An Answer:

If you can't get an answer, please don't take it personally that we don't feel we can help you. Sometimes the members of the asked group may simply not know the answer. No response is not the same as being ignored, though admittedly it's hard to spot the difference from outside.

In general, simply re-posting your question is a bad idea. This will be seen as pointlessly annoying. Have patience: the person with your answer may be in a different time-zone and asleep. Or it may be that your question wasn't well-formed to begin with.

There are other sources of help you can go to, often sources better adapted to a novice's needs.

How To Answer Questions in a Helpful Way:

Be gentle. Problem-related stress can make people seem rude or stupid even when they're not.

Reply to a first offender off-line. There is no need of public humiliation for someone who may have made an honest mistake. A real newbie may not know how to search archives or where the FAQ is stored or posted.

If you don't know for sure, say so! A wrong but authoritative-sounding answer is worse than none at all. Don't point anyone down a wrong path simply because it's fun to sound like an expert. Be humble and honest; set a good example for both the querent and your peers.

If you can't help, don't hinder. Don't make jokes about procedures that could trash the user's setup — the poor sap might interpret these as instructions.

Ask probing questions to elicit more details. If you're good at this, the querent will learn something — and so might you. Try to turn the bad question into a good one; remember we were all newbies once.

While just muttering RTFM is sometimes justified when replying to someone who is just a lazy slob, a pointer to documentation (even if it's just a suggestion to google for a key phrase) is better.

If you're going to answer the question at all, give good value. Don't suggest kludgy workarounds when somebody is using the wrong tool or approach. Suggest good tools. Reframe the question.

Help your community learn from the question. When you field a good question, ask yourself “How would the relevant documentation or FAQ have to change so that nobody has to answer this again?” Then send a patch to the document maintainer.

If you did research to answer the question, demonstrate your skills rather than writing as though you pulled the answer out of your butt. Answering one good question is like feeding a hungry person one meal, but teaching them research skills by example is teaching them to grow food for a lifetime.
 
Last edited:
Lancie1 said:
Busy hackers tend to simply flush questions in languages they don't understand, and English is the working language of the Internet.

Hello Lancie1,
英語がインターネットの言語であるとだれが言うか。
(y)
 
Well written and full of truth. Saw myself in there a few places.

May be worthy of a sticky thread.
 
Paulus,
The listed document did and don't you beleive everything you read on the net?:ROFLMAO:
 
Thanks, Ken, for bringing that to my attention.

I read the whole thing, agree with it, and actually re-phrased a question to a support line this morning as a result of having read it.

Good stuff.

Dan
 
TimothyMoulder said:
True - but I think that was Chinese...

If it is, Babel Fish couldn't decipher it. Worked fine in Japanese-English though.

See... this is exactly why you should use English :p
 

Similar Topics

Hi, my company is looking to implement an MES and I'm trying to figure out which is the best. Do any of you MES guys know which questions we...
Replies
17
Views
4,904
Good Morning , We are getting ready to launch a fairly large automation project. I have 3 robot integrators that submitted proposals. I am now...
Replies
9
Views
2,765
Many of you have experienced this before. Operators tend to get into a rut. If somebody posts a handy little cheat-sheet on how to operate a piece...
Replies
3
Views
4,040
I have a program that I've used 100 times. SQO settings: File N7:0, Mask 0FFFFh, Dest B3:1, Control R6:0, Length 8, Pos 2. Length & Position...
Replies
48
Views
798
We are to develop a first application in Codesys. It will contain motion (Softmotion) with drives on Ethercat (CSP mode). Off course there will be...
Replies
2
Views
836
Back
Top Bottom