I like spending my free time on Microsoft’s TechNet Forums site. I feel like it’s a great place to test my mettle by helping to solve people’s problems, but also it helps me gain a deeper perspective into the issues the technical community faces with a given product. This in turn, of course, makes me a better engineer and consultant – But before you try this at home, let me warn you: it’s addicting!

I have been surfing, helping, contributing, asking for around 2 years now and I’ve noticed some funny behaviors from the people who post there. I have also noticed what “types” of posts seem to get answered the fastest and which posts seem to linger unanswered indefinitely! This is what I want to point out today. Hopefully with my advice you’ll get your questions answered faster and with more accuracy! See below for 7 do’s and do not’s of online tech forum etiquette:

1. Do use punctuation! I am not talking about proof reading your English exam here, but it’s surprising how distracting a lack of: periodslinebreaksandspaces can be. Remember that other than the few paid Microsoft employees who roam this site, we are all answering questions voluntarily. I won’t say 🙂 how many times I have skipped a question because the reading the article was going to take more energy than I felt like expending at the moment.

2. Do a quick internet search for your error code or problem description before you post! I don’t think anyone REALLY minds looking the error up and pasting the link back for you, but I can’t understand how people will post their error on a technical forum, which takes considerably more effort than to just look it up in the first place! I have reminded myself to hold back on many occasions from posting lmgtfy.com links in my answer!

3. Do not put ***URGENT!!!!!!!!1!!! in the subject line. A mentor of mine once taught me the subtlety of Urgent vs. Important. Many things are important, but not all of which are urgent. The accuracy of the definition, of course isn’t my gripe. It’s the impatience or perhaps arrogance of the poster. I can assure you that adding “urgent” to your subject will not move you higher in the mental queue of the participants. In fact when I answer these types of quotes I typically roll my eyes before reading the thread, expecting a question from someone who has taken no time to think about the problem for themselves.

4. Do Use paragraphs. Yes, this is similar to #1 but I wanted to give its own attention because having your problem reported in paragraph form makes it easier to digest and analyze. I love it when someone breaks their post out into: background info, specific conditions, and question sections! This allows our analytical minds to work better and to focus on specific areas of the problem.

5. Do ask one question at a time (ok maybe two). These threads usually come from people looking for design help. They often have no idea about the technology they have suddenly found themselves managing, and ask questions about anything and everything all at once. The reasons for this number should be obvious but it’s often forgotten in the panic of the poster. Ask a single question about a single procedure, or possibly how two or three items interact, or pros and cons, etc. Remember, there is no limit of threads you can start! Don’t try to cram everything into a single request. Also bear in mind the forum serves two purposes, only one of which is to answer YOUR question. The other is to serve as a reference for others. With long winded design discussions, this second objective is lost, the first is rarely accomplished either. Either RTFM or pay a consultant to come and assist.

6. Do not bash Microsoft’s products. It is perfectly acceptable to ask “on system “x” I could do this – how do I do it with Microsoft’s solution?” But on occasion I have seen that turn into whining or outright insults to the people who work at Microsoft. This type of post is immature and unwelcome. If you have something that you need to air, start a blog, and if it’s worth reading people will find it. In the mean time get out of the way of people trying to do real work here.

7. Do keep it short and sweet. Please provide enough information so that the problem can be analyzed without requiring a bunch of back and forth questions, but let’s not start with huge memory dumps or lots of event logs. I offer this advice only because it makes the problem seem more complicated than it may actually be. That in turn means you may have people shy away from reading your post entirely.

And there you have it! Happy posting!