How to Ask for Help on Tech Forums

calendarDec 18, 2018 · 7 min read · forums vmtn  ·
Share on: linkedincopy

All of us need help at some point, and it’s only too common to reach out to others to ask for help. Before you do that, however, you need to understand some basic rules. These rules exist not only to maintain a sense of courtesy and respect, but to ultimately get you the best help possible. While most of this wisdom is applicable to any online technology forum, it is specifically geared to the VMware Technology Network (VMTN), VMware’s official online community.

In the interest of brevity, this article has been intentionally kept short and sweet. These are only the most basic and essential of rules to keep in mind. It is not meant to be an exhaustive list (because you probably wouldn’t read it then). But please read all of these. All of them. Seriously.

There are four major categories you need to understand and read. All rules can be grouped in one of these categories.

A. Having an Issue

When a problem strikes and you get the itch to reach out for help, make sure you’ve done all these first.

B. Planning to Post

Once you’ve exhausted the resources on your own in Having an Issue, you want to make a post. Prior to that, understand what you’re walking in to and have a basic sense of expectation. It’s easy to forget some of these points.

C. Posting

Now that you have a level set of things, you want to create that post. Ensure you do all of these things correctly and you’ll almost certainly solve your problem.

D. Following-Up

You’ve created your post, but the job isn’t over. Follow through by responding and closing things out.

A. Having an Issue

  1. Help yourself first. Always. This means conducting multiple, basic searches on Google in addition to the forum on which you intend to post. If a user can answer your question with a result from a Google search appearing in the first page, you have failed this step.

  2. Read the documentation. The term “RTFM” comes to mind. You need to read what has already been written on the product in question. This includes the release notes. You should never skip any of these two steps.

B. Planning to Post

  1. Do not post angry or with an attitude. If you’re heated or frustrated with your issue, wait a while and calm down. Do not take your anger out on a public forum. It does absolutely no good and only turns people away.

  2. Always read the community rules. Yes, those you agreed to uphold when you registered an account. Read and commit them all to memory.

  3. Keep in mind these things when asking others for help:

    1. These are volunteers with professional lives.

    2. They are spending their spare, personal time to help YOU. That is time that could have been spent with their own friends and family, or to advance their careers.

    3. Their knowledge and expertise is worth hundreds or thousands of dollars in any other venue.

    4. You are getting all of this completely for free. You are expected to spend your time and convenience in exchange.

    5. The community members don’t owe you anything whatsoever. Assistance is provided on a best-effort basis but you’re entitled to nothing.

    6. While some are, most community members are not VMware employees which means:

      1. They don’t know futures and couldn’t tell them to you even if they did know. Don’t ask when a version is being released or if support for X will be included.
      2. This is not an extension of your support and subscription (SnS) contract. If you’re dissatisfied with a response or don’t get one, you can always open an official SR with VMware. If you can’t or don’t want to pay, that isn’t the community’s fault.

C. Posting

  1. Make your thread title appropriate and descriptive. Members should have a decent idea of what you’re asking before reading it. Examples of bad thread titles include:

    1. “Vmware”
    2. “I need help!!!”
    3. “Do not start”

  2. Thoroughly describe your situation. Don’t be a lazy poster as there’s no one people hate helping less than that. Include all product names, all versions, and all steps you performed to generate the result. Here are some examples of actual bad questions:

    1. “All our VMs were powered off on weekend and why dont know when and why?”
    2. “Suggest discovery tools for data center migration”
    3. “how to install SRM”
    4. “I need to be able to enable the option to edit hot. vMware vSphere 6.5 does not have the option.”
    5. “hello can someone help me with a kickstart script that will install esxi and configure a static ip address on vlan x for mgmt i would also like to add a second uplink to my vswitch and add a new portgroup for virtual machine traffic on vlan y”
    6. "Hello Expert, please help to resolve this problem <screenshot>"

Each of these examples is a violation of rules discussed earlier. If you aren’t sure why these are bad questions, start at the top and read again.

  1. Screenshots help immensely. If in doubt, post some screenshots anyway. VMTN allows pasting them directly in the body, making it extremely easy. But please don’t be an idiot by taking a picture of your filthy monitor with your camera phone (crashes excluded). If you don’t know how to take a proper screenshot, see Having an Issue and learn. Every OS has free screenshot tools built-in. Learn how to use them.

  2. Don’t ask for things on a silver platter. Asking for assistance is fine. Asking for someone to hand over bespoke or custom work to you is not. This includes scripts and custom documentation. Online forum communities are not places where you go to get your butt wiped.

  3. Attach logs. If you don’t know where they are or how to do that, see Having an Issue.

  4. Why do you want to do this thing? Use case matters, because very often what you think you want to do shouldn’t be done that way. The community might have alternatives that work better for you. You never know.

  5. English may be a second language. People understand that you may not be an expert in English and that it’s hard. However, just because you haven’t mastered English doesn’t release you from attempting to help yourself first or providing enough information in your post.

D. Following-Up

  1. Be responsive in your thread. When you open a thread/question, have the decency to reply to any answer you might receive in a timely manner. If you care less about solving your own problem than the community members do, don’t expect them to go out of their way to help you.

  2. Declaring an answer. If and when you do get a correct answer, don't just cut and run away with it. Confirm via some method that the answer is indeed the correct or desired one. This could be a verbal acknowledgement or, in the case of VMTN, use the built-in "Helpful" or "Correct Answer" buttons. This not only provides a modest point reward to those who spent their time helping you but also flags your post as being answered so others who come behind you have the benefit of a correct answer as well.

To sum up these rules and reminders, let me distill it into just a few short sentences.

Show the community you're serious about helping yourself. You do this demonstrating most of these points: You searched, you read, you attempted to help yourself. When that failed, you thoroughly described your problem and provided ample details for others to take on your case. After getting responses, you responded in a timely fashion and were cordial, expressing appreciation for being helped. Once receiving an answer, you acknowledged it in some form. If you can follow this pattern, you will have the absolute best chance of getting your issue resolved.