General Trouble shooting procedures and asking for Help!
Trouble shooting procedures and asking for Help!:
To trouble shoot any problem you face we need to follow some procedure in order to get the most efficient solution to our problems
First we have to specify the problem by:
1) Describe what you are trying to do
2) What steps you took to do number 1 (list the instructions you followed)
3) What error message you are getting
4) What you have done to research the problem (searched bing, google, etc)
5) Lastly ask for a pointer in the direction of the answer, rather than just the answer
Before You Ask
Before asking a technical question by e-mail, or in a newsgroup, or on a website chat board, do the following:
- Try to find an answer by searching the Web.
- Try to find an answer by reading the manual.
- Try to find an answer by reading a FAQ.
- Try to find an answer by inspection or experimentation.
- Try to find an answer by asking a skilled friend.
- If you're a programmer, try to find an answer by reading the source code.
When you ask your question, display the fact that you have done these things first; this will help establish that you're not being a lazy sponge and wasting people's time.
Better yet, display what you have learned from doing these things. We like answering questions for people who have demonstrated they can learn from the answers.
Lastly, if you find your question hasn't been answered in the time you need it to, please don't repost the same question. It may be that no one had the time to look at your question or they may not have the answer. Doing so only fills up people's mailboxes.
Use tactics like doing a Bing search on the text of whatever error message you get (searching technet, blogs, groups as well as Web pages). This might well take you straight to fix documentation or a mailing list thread answering your question. Even if it doesn't, saying "I binged on the following phrase but didn't get anything that looked promising" is a good thing to include in e-mail or news postings requesting help.
Prepare your question. Think it through. Hasty-sounding questions get hasty answers or none at all. The more you do to demonstrate that having put thought and effort into solving your problem before seeking help, the more likely you are to actually get help.
Never assume you are entitled to an answer. You are not; you aren't, after all, paying for the service. You will earn an answer, if you earn it, by asking a substantial, interesting, and thought-provoking question - one that implicitly contributes to the experience of the community rather than merely passively demanding knowledge from others.
On the other hand, making it clear that you are able and willing to help in the process of developing the solution is a very good start. "Would someone provide a pointer?", "What is my example missing?", and "What site should I have checked?" are more likely to get answered than "Please post the exact procedure I should use." because you're making it clear that you're truly willing to complete the process if someone can just point you in the right direction.
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! Sending mails is not working on my server!
Smart:
Exchange SMTP refuses to send mail.
Smarter:
Exchange 2010 SMTP error code “405 temporary problem”.
Make it easy to reply
Finishing your query with "Please send your reply to... " makes it quite unlikely you will get an answer.
Write in clear, grammatical, correctly-spelled language
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.
Send questions in accessible, standard formats
If you make your question artificially hard to read, it is more likely to be passed over in favor of one that isn't. So:
Send plain text mail, not HTML.
MIME attachments are usually OK, but only if they are real content (such as an attached source file or patch), and not merely boilerplate generated by your mail client (such as another copy of your message).
Don't send e-mail in which entire paragraphs are single multiply-wrapped lines. (This makes it too difficult to reply to just part of the message.) Assume that your respondents will be reading mail on 80-character-wide text displays and set your line wrap accordingly, to something less than 80.
However, do not wrap data (such as log file dumps or session transcripts) at any fixed column width. Data should be included as-is, so respondents can have confidence that they are seeing what you saw.
Never, ever expect people to be able to read closed proprietary document formats.Most people react to these about as well as you would to give them a packed virus.
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.: "Windows 2003 SP1", "Windows 2008 R2", Firmware Version xxx, etc.).
Send ALL the log files and reports related to the problem.
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.
Don't claim that you have 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. Hint: 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. This applies to web pages and documentation, too; if you have found a documentation "bug", you should supply replacement text and which pages it should go on.
The people who wrote the software work very hard to make it work as well as possible. If you claim you have found a bug, you'll be impugning their competence,which may offend some of them even if you are correct. It's especially undiplomatic to yell "bug" in the Subject line.
When asking your question, it is best to write as though you assume you are doing something wrong, even if you are privately pretty sure you have found an actual bug.
If there really is a bug, you will hear about it in the answer. Play it so the maintainers will want to apologize to you if the bug is real, rather than so that you will owe them an apology if you have messed up.
Describe the problem's symptoms, not your guesses
It's not useful to tell programmers what you think is causing your problem. (If your diagnostic theories were such hot stuff, would you be consulting others for help?) 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.
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 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.
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.
Don't flag your question as "Urgent", even if it is for you
That's your problem, not ours. Claiming urgency is very likely to be counter-productive: most programmers will simply delete such messages as rude and selfish attempts to elicit immediate and special attention.
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.
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.
RTFM and STFW: How To Tell You've Seriously Screwed Up
There is an ancient and hallowed tradition: if you get a reply that reads "RTFM", the person who sent it thinks you should have Read The ****** Manual. He or she is almost certainly right. Go read it.
RTFM has a younger relative. If you get a reply that reads "STFW", the person who sent it thinks you should have Searched The ****** Web. He or she is almost certainly right. Go search it. (The milder version of this is when you are told "Bing is your friend!")
If you don't understand...
If you don't understand the answer, do not immediately bounce back a demand for clarification. Use the same tools that you used to try and answer your original question (manuals, FAQs, the Web, skilled friends) to understand the answer. Then, if you still need to ask for clarification, exhibit what you have learned.
Dealing with rudeness
When you perceive rudeness, try to react calmly. If someone is really acting out, it is very likely a senior person on the list or newsgroup or forum will call him or her on it.
If that doesn't happen and you lose your temper, it is likely that the person you lose it at was behaving within the programmer community's norms and you will be considered at fault. This will hurt your chances of getting the information or help you want.
If You Can't Get An Answer
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 currently be asleep, in a different time-zone.