These are some things that you should do before you go out with your questions, so that you may not goof up.
1. Try finding your answer by searching the archieves of the forum.
2. Find your answer by searching web.
3. Read the manual.
4. Go through FAQ.
5. Inspect or experiment.
6. Consult a skilled source.
7. Explore the source code.
While you ask your question, display the fact that you have done the above things first.This will help establish that you’re not being a lazy sponge and wasting peoples time. If you get an error message it’s always good to google search the error text. In most cases you will get your solutions this way. Before asking questions, prepare your questions, work on it thoroughly. There are many things you should know before you approach a person.
When You ask a question pay attention to the following points.
[caption id="attachment_291" align="aligncenter" width="600"]
Debugging[/caption]
1. Choose the forum correctly.
a). You should be sensitive enough in choosing where to ask or post your queries and where not to.
b). Do not post you questions in a forum which is irrelevant off topic.
c). Refrain posting elementry question to a forum where advanced technicals are expected, or vice versa
d). Avoid cross-posting in too many different new groups.
e). Don’t post personal emails to somebody who is not personally responsible for answering your questions.
2. Stack overflow
Before putting up your question in
stackoverflow, search in web. There is a greater chance someone else has asked the same questions. Stack exchange sites are often near the top of the search results. If you didn’t find anything by google serach, search again in the most relevant sites. If you still don’t, post your question in relevant sites.
Stack overflow sites has grown to more than 100 sites. We will look at the most popular 3 sites.
a). Super user is for questions about general-purpose computing.
b). Stack Overflow is for questions about programming.
c). Server Fault is for questions about server and network administration.
3. Web and IRC forums
Check for a search feature before posting to a web forum. If it have search feature, try some keyword searches related to the problem. It’s always good to do a forum search even if you have web searched.
4. Use project mail list
If a project has mail list, other than mailing to individuals, even if you know who can best answer your question.Use it.There are some good reasons for this:
a). Any question good enough to be asked by one developer will also be of value to the whole group.
b). Asking questions on the list distributes load among developers.An individual developer may be too busy.
c). If certain questions are seemed to be asked often, developers can use that information to improve the documentation or the software itself to be less confusing.
5. Subject headers should be meaningful and specific.
Subject header is a golden opportunity to attract qualified experts. It should be maximum of 50 characters or fewer. One good convention of subject header is “object-deviation”. The “object” part defines what thing or group of things is having a problem, and the “deviation” part describes the deviation from expected behaviour.
6. Make it easy to reply.
Finishing your query with “Please send your reply to… ” makes it quite unlikely you will get an answer. If you can’t be bothered to take even the few seconds required to set up a correct Reply-To header in your mail agent, expert’s can’t be bothered to take even a few seconds to think about your problem.
7. Write in clear, grammatical, correctly spelled language.
Expressing your question clearly and well is important. Spend extra effort to polish your language. It doesn’t have to be stiff or formal — in fact. But it has to be precise, there has to be some indication that you’re thinking and paying attention.
8. Send questions in accessible & standard formats.
a). Send plain text mail, not html.
b). MIME attachments are usually ok, but only if they are real content (such as an attached source file or patch).
c). Don’t send e-mail in which entire paragraphs are single multiply-wrapped lines.
d). However, do not wrap data at any fixed column width.
e). Don’t send MIME Quoted-Printable encoding to an English-language forum.
f). In web forums, do not use “smiley” and “HTML” features.
9. Be precise and informative about your problem.
a). Describe the symptoms of your problem or bug carefully and clearly.
b). Describe the environment in which it occurs (machine, OS, application, whatever). Provide your vendor’s distribution and release level (e.g.: “Fedora Core 7”, “Slackware 9.1”, etc.).
c). Describe the research you did to try and understand the problem before you ask the question.
d). Describe the diagnostic steps you took to try and pin down the problem yourself before you asked the question.
e). Describe any possibly relevant recent changes in your computer or software configuration.
f). If at all possible, provide a way to reproduce the problem in a controlled environment.
10. Volume is not precision.
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.
a). Being able to invest effort in simplifying the question makes it more likely you’ll get an answer.
b). Simplifying the question makes it more likely you’ll get a useful answer.
c). In the process of refining your bug report, you may develop a fix or workaround yourself.
11.Don’t rush to claim that you found a bug.
When you are having problems with a piece of software, don’t claim you have found a bug unless you are very, very sure of your ground. Unless you can provide a source-code patch that fixes the problem, or a regression test against a previous version that demonstrates incorrect behavior, you are probably not sure enough.
12. Grovelling is not a substitute for doing your homework.
Some people who get that they shouldn’t behave rudely or arrogantly, demanding an answer, retreat to the opposite extreme of grovelling. “I know I’m just a pathetic newbie loser, but…”. This is distracting and unhelpful. It’s especially annoying when it’s coupled with vagueness about the actual problem.
13. Describe the problem’s symptoms, not your guesses.
It’s not useful telling hackers what you think is causing the problem. So, make sure you’re telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis. If you feel it’s important to state your guess, clearly label it as such and describe why that answer isn’t working for you.
14. 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.
15. Describe the goal, not the steps.
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.
16. Don’t ask people to reply by private e-mail.
Experts believe solving problems should be a public, transparent process during which a first try at an answer can and should be corrected if someone more knowledgeable notices that it is incomplete or incorrect. Also, helpers get some of their reward for being respondents showing competency and knowledge by their peers.
17. Be explicit about your question.
Open-ended questions tend to be perceived as open-ended time sinks. Those people most likely to be able to give you a useful answer are also the busiest people. People like them are allergic to open-ended time sinks, thus they tend to be allergic to open-ended questions.
18. When asking about code.
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.
19. Don’t post homework questions.
Hackers are good at spotting homework questions, most of you have done them yourselves. Those questions are for you to work out, so that you will learn from the experience. It is OK to ask for hints, but not for entire solutions.
20. Prune pointless queries.
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.”
21. Don’t flag your question as “Urgent”, even if it is for you.
That’s your problem, not experts. Claiming urgency is very likely to be counter-productive.Most hackers will simply delete such messages as rude and selfish attempts to elicit immediate and special attention. Furthermore, the word ‘Urgent’ (and other similar attempts to grab attention in the subject line) often triggers spam filters – your intended recipients might never see it at all!
22. Courtesy never hurts, and sometimes helps.
Be courteous. Use “Please” and “Thanks for your attention” or “Thanks for your consideration”. Make it clear you appreciate the time people spend helping you for free.
23. Follow up with a brief note on the solution.
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.]]>
