Skip to main content
This forum is closed to new posts and responses. New discussions are now taking place in the IBM Developer Answers forum.
 
developerWorks
AIX and UNIX
Information Mgmt
Lotus
New to Lotus
Products
How to buy
Downloads
Live demos
Technical library
Training
Support
Forums & community
Events
Rational
Tivoli
WebSphere
Java™ technology
Linux
Open source
SOA and Web services
Web development
XML
My developerWorks
About dW
Submit content
Feedback



developerWorks  >  Lotus  >  Forums & community  >  Notes/Domino 6 and 7 Forum

Notes/Domino 6 and 7 Forum

developerWorks

  

PreviousPrevious NextNext


Karl-Henry Martinsson 4.Apr.13 11:58 AM a Web browser
General All Releases All Platforms


I keep seeing posts in this forum (as well as in the other Notes related forums) where the posts have very little information or background.

It is obvious that there is a need for some education on how to ask questions properly. If the question is asked properly, and contains all the information (including a background to what you are trying to do and what you already tried), it is easier for the rest of us to solve the problem.

I suggest that everyone read the following two links before posting any questions to the forum:

http://www-10.lotus.com/ldd/nd6forum.nsf/0/410171d83ddba6d485256df100832aba

http://www.catb.org/esr/faqs/smart-questions.html


Here are some excerpts:

------------------------------------------------------------
Questions Not To Ask:

Q: Where can I find program or resource X?
A: The same place I'd find it, fool — at the other end of a web search. Doesn't everybody know how to use Google yet?

Q: How can I use X to do Y?
A: If what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation. It is generally best to ignore such people until they define their problem better.

Q: How can I configure my shell prompt?
A: If you're smart enough to ask this question, you're smart enough to RTFM and find out yourself.

Q: Can I convert an AcmeCorp document into a TeX file using the Bass-o-matic file converter?
A: Try it and see. If you did that, you'd (a) learn the answer, and (b) stop wasting my time.

Q: My {program, configuration, SQL statement} doesn't work
A: This is not a question, and I'm not interested in playing Twenty Questions to pry your actual question out of you — I have better things to do. On seeing something like this, my reaction is normally of one of the following:
• do you have anything else to add to that?
• oh, that's too bad, I hope you get it fixed.
• and this has exactly what to do with me?

---------------------------------------------------------------

The people with the knowledge to answer your questions are generally busy and don't have a lot of time to read the forums. This document will tell you:
• How to solve most problems on your own (which is generally the fastest way to get an answer).
• How to get the attention of the experts who know the answers.
• How to maintain good relations with these experts, so they are willing to help you.
• How to ensure that your question has enough information to let someone work on it.

If someone has to ask you question after question, they may give up on your problem.

------------------------------------------------------------

• Bear in mind that we don't know how much you already know. You may get some suggestions that seem obvious or that seem to imply you don't know what you're doing. Many of the people who post don't know what they're doing, and we have no way to tell them apart from the ones who do.
• Search for answers before you post. We get really tired of seeing the same questions over and over (plus, you get an answer faster that way).
• Read the product documentation about the functions you're using.
• Try to solve the problem yourself before you ask for help. Make sure your post talks about what you've already tried.

A theme in those last three points is that you might do some work yourself before asking people to help you. If you don't consider the problem important enough to put in a little time on it, why should anyone else?

-------------------------------------------------------

We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding (often enough to bet on, anyway). Answering questions for careless and sloppy thinkers is not rewarding; we'd rather spend our time elsewhere.

So expressing your question clearly and well is important. If you can't be bothered to do that, we can't be bothered to pay attention. Spend the extra effort to polish your language. It doesn't have to be stiff or formal — in fact, hacker culture values informal, slangy and humorous language used with precision. But it has to be precise; there has to be some indication that you're thinking and paying attention.

Spell, punctuate, and capitalize correctly.

More generally, if you write like a semi-literate boob you will very likely be ignored. So don't use instant-messaging shortcuts. Spelling "you" as "u" makes you look like a semi-literate boob to save two entire keystrokes. Worse: 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.

If you are writing in English but it is a second language for you, it is good form to alert potential respondents to potential language difficulties and options for getting around them. Examples:

• English is not my native language; please excuse typing errors.

• If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.

• I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

• I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.

-----------------------------------------------------------

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).
• 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.
• If at all possible, provide a way to reproduce the problem in a controlled environment.

Do the best you can to anticipate the questions a hacker will ask, and answer them in advance in your request for help.

Giving hackers the ability to reproduce the problem in a controlled environment is especially important if you are reporting something you think is a bug in code. When you do this, your odds of getting a useful answer and the speed with which you are likely to get that answer both improve tremendously.

You need to be precise and informative. This end is not served by simply dumping huge volumes of code or data into a help request. If you have a large, complicated test case that is breaking a program, try to trim it and make it as small as possible.

This is useful for at least three reasons. One: being seen to invest effort in simplifying the question makes it more likely you'll get an answer, Two: simplifying the question makes it more likely you'll get a useful answer. Three: In the process of refining your bug report, you may develop a fix or workaround yourself.

-----------------------------------------------------------

Describe your problem's symptoms in chronological order.

The clues most useful in figuring out something that went wrong often lie in the events immediately prior. So, your account should describe precisely what you did, and what the machine and software did, leading up to the blowup. In the case of command-line processes, having a session log (e.g., using the script utility) and quoting the relevant twenty or so lines is very useful.

If the program that blew up on you has diagnostic options (such as -v for verbose), try to select options that will add useful debugging information to the transcript. Remember that more is not necessarily better; try to choose a debug level that will inform rather than drowning the reader in junk.

If your account ends up being long (more than about four paragraphs), it might be useful to succinctly state the problem up top, then follow with the chronological tale. That way, hackers will know what to watch for in reading your account.

------------------------------------------------------------

Describe the goal, not the step.

If you are trying to find out how to do something (as opposed to reporting a bug), begin by describing the goal. Only then describe the particular step towards it that you are blocked on.

Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path towards the goal. They come for help with the step, but don't realize that the path is wrong. It can take substantial effort to get past this.

Stupid:
How do I get the color-picker on the FooDraw program to take a hexadecimal RGB value?
Smart:
I'm trying to replace the color table on an image with values of my choosing. Right now the only way I can see to do this is by editing each table slot, but I can't get FooDraw's color picker to take a hexadecimal RGB value.

The second version of the question is smart. It allows an answer that suggests a tool better suited to the task.

----------------------------------------------------------

Don't ask others to debug your broken code without giving a hint what sort of problem they should be searching for. Posting a few hundred lines of code, saying "it doesn't work", will get you ignored. Posting a dozen lines of code, saying "after line 7 I was expecting to see <x>, but <y> occurred instead" is much more likely to get you a response.

The most effective way to be precise about a code problem is to provide a minimal bug-demonstrating test case. What's a minimal test case? It's an illustration of the problem; just enough code to exhibit the undesirable behavior and no more. How do you make a minimal test case? If you know what line or section of code is producing the problematic behavior, make a copy of it and add just enough supporting code to produce a complete example (i.e. enough that the source is acceptable to the compiler/interpreter/whatever application processes it). If you can't narrow it down to a particular section, make a copy of the source and start removing chunks that don't affect the problematic behavior. The smaller your minimal test case is, the better.

Generating a really small minimal test case will not always be possible, but trying to is good discipline. It may help you learn what you need to solve the problem on your own — and even when it doesn't, hackers like to see that you have tried. It will make them more cooperative.

If you simply want a code review, say as much up front, and be sure to mention what areas you think might particularly need review and why.

---------------------------------------------------

Resist the temptation to close your request for help with semantically-null questions like “Can anyone help me?” or “Is there an answer?” First: if you've written your problem description halfway competently, such tacked-on questions are at best superfluous. Second: because they are superfluous, hackers find them annoying — and are likely to return logically impeccable but dismissive answers like “Yes, you can be helped” and “No, there is no help for you.”

----------------------------------------------------------

Send a note after the problem has been solved to all who helped you; let them know how it came out and thank them again for their help. If the problem attracted general interest in a mailing list or newsgroup, it's appropriate to post the followup there.

Optimally, the reply should be to the thread started by the original question posting, and should have ‘FIXED’, ‘RESOLVED’ or an equally obvious tag in the subject line. On mailing lists with fast turnaround, a potential respondent who sees a thread about “Problem X” ending with “Problem X - FIXED” knows not to waste his/her time even reading the thread (unless (s)he personally finds Problem X interesting) and can therefore use that time solving a different problem.

Your followup doesn't have to be long and involved; a simple “Howdy — it was a failed network cable! Thanks, everyone. - Bill” would be better than nothing. In fact, a short and sweet summary is better than a long dissertation unless the solution has real technical depth. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.

For problems with some depth, it is appropriate to post a summary of the troubleshooting history. Describe your final problem statement. Describe what worked as a solution, and indicate avoidable blind alleys after that. The blind alleys should come after the correct solution and other summary material, rather than turning the follow-up into a detective story. Name the names of people who helped you; you'll make friends that way.

Besides being courteous and informative, this sort of followup will help others searching the archive of the mailing-list/newsgroup/forum to know exactly which solution helped you and thus may also help them.

Last, and not least, this sort of followup helps everybody who assisted feel a satisfying sense of closure about the problem. If you are not a techie or hacker yourself, trust us that this feeling is very important to the gurus and experts you tapped for help. Problem narratives that trail off into unresolved nothingness are frustrating things; hackers itch to see them resolved. The goodwill that scratching that itch earns you will be very, very helpful to you next time you need to pose a question.

Among hackers, this sort of good followup behavior is actually more important than conventional politeness. It's how you get a reputation for playing well with others, which can be a very valuable asset.

---------------------------------------------------------






Tips on how to ask questions in thi... (Karl-Henry Mart... 4.Apr.13)
. . RE: Tips on how to ask questions in... (Barry Shapiro 4.Apr.13)





  Document options
Print this pagePrint this page

 Search this forum

  Forum views and search
Date (threaded)
Date (flat)
With excerpt
Author
Category
Platform
Release
Advanced search

 RSS feedsRSS
All forum posts RSS
All main topics RSS
More Lotus RSS feeds

Resources

 Resources
Forum use and etiquette
Native Notes Access
Web site Feedback

Lotus Support

 Lotus Support
IBM Support Portal - Lotus software
Lotus Support documents
Lotus support by product
Lotus support downloads
Lotus support RSS feeds

Wikis

 Wikis
IBM Composite Applications
IBM Mashup Center
IBM Connections
IBM Connections Cloud Developers
IBM Docs
IBM Forms
IBM Mobile Connect
IBM Sametime
IBM SmartCloud for Social Business
IBM Web Experience Factory
Lotus Domino
Lotus Domino Designer
Lotus Expeditor
Lotus Foundations
Lotus iNotes
Lotus Instructor Community Courseware
Lotus Notes
Lotus Notes & Domino Application Development
Lotus Notes Traveler
Lotus Protector
Lotus Quickr
Lotus Symphony
IBM Web Content Manager
WebSphere Portal

Lotus Forums


 Lotus Forums
Notes/Domino 9.0
Notes/Domino 8.5 + Traveler
Notes/Domino XPages development forum
Notes/Domino 8
Notes/Domino 6 and 7
IBM Connections
IBM Mobile Connect
IBM Sametime
IBM SmartCloud Notes
Lotus Enterprise Integration
Lotus Protector
Lotus Quickr
Lotus SmartSuite