A few weeks ago I wrote an article on Supplementary Study Resources, which discusses sources of information beyond textbooks, including discussion forums and other interactive sources. Along a similar line of thought, today's post offers some guidance for asking questions on large public forums. For many readers, all of the below will be common sense. The advice is targeted primarily at two audiences:
- People who are new to the field
- People who can't figure out why no one replies to their questions
My advice is broken into simple dos and don'ts, with illustrative examples where appropriate.
Don't be clingy
Can someone help me configure EIGRP?
This is probably the most common error I see people make. Understand that any support for which you have not paid is ad-hoc and best effort; in other words, there is no guarantee you will be helped. And if someone does help, there is no guarantee that he or she will continue to help until the problem has been solved to your satisfaction.
Very few people are willing to offer themselves as a dedicated point of contact as you work through an issue. Don't specifically ask for someone to volunteer their services. Simply state your problem (be specific); if someone has the time and inclination to assist, they will.
Don't claim urgency
HELP!!!! VERY URGENT!!!1 TWITTER KEEPS TIMING OUT AND I HAVE SOMETHING IMPORTANT I NEED TO TWEET!!!!11
If it was actually urgent, you'd be paying someone to help you fix it right now, not making a forum post or chatting on IRC. Claiming undue prioritization implies that the time of others isn't as important as yours, and isn't going to get you any help.
Also, never capitalize your entire thread title when posting on a forum. It's simply poor netiquette.
Don't play chat tag
When conversing via IRC or some similar real-time chat, only ask questions when you have the time and energy to engage in conversation. Typically, other people will need you to provide more information to help you; don't simply paste your question into IRC, go to lunch, then come back and expect anyone to still be interested (or even remember your question).
If you want to put a question out there, but don't have time to respond to follow-up inquiries immediately, post on a discussion forum or mailing list instead.
When posting on a forum, post only once. Don't duplicate your post across multiple message boards. It's annoying and unnecessary. Further, it demonstrates an absence of basic understanding with regard to forum etiquette, which will only discourage others from responding.
Don't pretend you know more than you do
Hey guys, first off I just want to say I've been a techie for over ten years, I have a dozen certifications, and I make six figures so I'm definitely not a noob. I'm just trying to figure out what this little light blue cable that came with this router is for.
People who make inflated claims seldom realize how transparent they are. Or how hard everyone else is laughing.
Don't ask for things you know you shouldn't
Generally speaking, this includes but is not limited to asking for:
- Pirated books or software
- Answers to your homework
- Certification test questions (braindumps)
- Help hacking into your ex-girlfriend's Facebook account
A helpful rule of thumb for those with under-performing consciences: if you wouldn't ask the question in front of a crowd in person, don't ask it online.
First ask yourself how someone else would know the answer
Does an 1841 support MPLS?
There are two general types of questions that people ask: objective (dealing in absolutes) and subjective (dealing in individual experiences). The majority of technical questions are objective in nature: "Does model A support feature B?", "How do I configure C?", etc. Subjective questions deal more with opinion and experience: "How does model X compare with model Y?", "Should I enable feature Z?"
How do you suppose someone else would find the answer to the question above regarding MPLS support on Cisco 1841 routers? Clearly it's an objective question. The answer is easily researched in vendor documentation yourself; there is no excuse to ask someone else to do the work for you. Even if you don't know where to locate said documentation, the question should at least be rephrased, "How can I determine whether an 1841 supports MPLS?" You'll find people are far more willing to loan you a fishing rod than to catch you a fish.
Provide sufficient detail and context
Why doesn't NAT work on my router?
How would you expect anyone not standing over your shoulder to answer such a vague question? Details are invaluable things, and the more you provide the better your chance of receiving a productive response will be.
Include your configurations where applicable
The first reply in many, many forum threads is "Please post your configs." Rather than waiting for someone to ask, go ahead and attach sanitized configs (whole or partial, depending on the scope of the topic) along with your initial post. And don't simply dump configuration text into the post body: Remember to enclose configuration snippets in code blocks for easy readability. Attach long configs as separate text files.
Show your work
This is by far one of the most beneficial ideals you can include in a solicitation for help. Always remember to include the steps you've already taken on your own when requesting assistance. Consider the following two posts:
Guys, I can't get two routers to establish a BGP adjacency. What could be the problem?
Guys, I can't get two routers to establish a BGP adjacency. I've verified that they're both configured with the correct AS numbers and peer addresses. No authentication is in use.
show ip bgp summaryshows that the adjacency is getting stuck in active mode. I've attached a packet capture taken from the link if that helps. Any ideas?
The second post is far more likely to attract interest, because the author has demonstrated initiative in excluding some common mistakes prior to posting and in providing a packet capture for others to inspect. You want to write posts like the second one.
Finally, if you come upon a solution to your problem, be sure to return to your initial query and record the solution. The benefits of this are three-fold:
- You provide a sense of closure and appreciation for the people who helped.
- You provide potential help for others with your same problem who come across the post via Google.
- You have ad hoc documentation of the resolution for your own purposes should the problem recur months or years in the future.