Unofficial FLL FAQ06-c - How to Ask A Good Question
UFAQ Table of Contents
Introduction

The quality of an answer depends on how well you ask the question. This guide will teach you how to ask a question so that you receive a helpful answer. This is a good skill to know not just for FIRST LEGO League, but life in general.

The people who answer most of the questions posted to the FLL forum tend to be experienced veteran coaches. We thrive on hard problems and good, thought-provoking questions. Give us an interesting question to chew on and we'll go to great lengths to answer it.

It isn't necessary to be competent to ask a question, but it is necessary to demonstrate the kind of attitude that leads to competence. We were all rookies at one time and understand that you have basic questions. Ask them, but please ask them the right way!

Before You Ask

Do your homework

  1. Read the FLL Coaches' Handbook. This is the orange and black paperback book that came with your materials from FIRST.
  2. Read the Rules. Available here: http://www.firstlegoleague.org/default.aspx?pid=23710
  3. Read the Mission Descriptions. Available here: http://www.firstlegoleague.org/default.aspx?pid=23720
  4. Read the Table Setup instructions. Available here: http://www.firstlegoleague.org/default.aspx?pid=23680
  5. Read the latest version of the Q&A. Available here: http://www.firstlegoleague.org/default.aspx?pid=23730
  6. Read the Unofficial FAQ. Available here: http://www.fll-freak.com/faq
  7. Use the search feature on the forum.
  8. Try to search the web using your favorite search engine. Google is a good choice.

Many of the non-mission specific questions can be answered by reading the above documents. It will take some time, but do read the material. At the very least skim the material to know what and where it is available.

Next, try searching the forum for an answer. Scan the appropriate folders for an answer or use the search feature to look for keywords. If that fails, try doing a Google search.

Prepare your question.

Think it through. Hasty-sounding questions get hasty answers. The more you do to demonstrate that you have put thought and effort into solving your problem before asking for help, the more likely you are to get good useful answers.

Make it clear that you are able and willing to learn. “Where can I find age appropriate information on gearing?” is more likely to get a good answer than “Please post links for our research paper”.

Choose your forum area carefully

The forum is organized in a directory structure. Each area is targeted for certain types of discussions. Asking your question in the proper place is important for several reasons.

The first is simply one of organization. If all the messages are placed haphazardly, it makes it nearly impossible for the next person to find information.

The second is that veteran users will have set up the forum to alert them of new messages only in areas that they are interested in or competent in. Post a RIS question to the Research area, and you may bypass the exact people you want to target. This is especially true of programming questions. Asking RIS questions under the RoboLab or General sections is confusing to all parties.

Please ask your question in just one discussion area. Posting your question to multiple locations is a waste of everyone’s time. If you pick the right area, the right people will see the question.

Be patient. The Forum is not an Instant Messenger type system. When you post a question, it becomes a permanent entry in the forum. Other users will log into the Forum at their leisure, see your question, and answer it if they choose to. Often you will get an answer in just a few hours. At other times you may have to wait a day or two.

Use meaningful, specific subject headers

On the forum, the first few words of the first paragraph become the subject line in the outline view. These initial words are your golden opportunity to attract attention. Don't waste it on “Please help me”. Make your subject line reflect your question well enough that the next coach searching the forum with a question similar to yours will be able to follow the thread to an answer rather than having to post the question again.

Etiquette

Asking for a reply by private email is rude. It indicates that you will not be bothered to stay current with the forum to get your answer, but are happy to take up others time. If you want to get an email when somebody replies to the thread, request that the Forum send it to you. Take the Forum tutorial to learn how to do this.

Don't TYPE IN ALL CAPS, this is read as shouting and it is also difficult to read.

PLZ keep IM abbreviations 2 a minimum.

Be courteous. Make it clear that you appreciate the time people spend helping you.

Messages with any foul or abusive language will be deleted as soon as found. Privileges to participate can be revoked.

Be precise and informative about your question.

Expressing your question clearly is important. Spend the extra effort to polish your language. It doesn't have to be stiff or formal, but it has to be precise.

Describe your question carefully and clearly.

When you ask your question, display some of what you have learned from your research. We like answering questions for people who have demonstrated that they have done their homework.

Do the best you can to anticipate the questions that will be asked and answer them in advance. Remember to state your programming language if applicable.

You need to be precise and informative, but this is not an invitation to write a tome.

Describe the problem, not your guesses

It's not useful to describe your guesses. Just provide the raw facts. You may be disguising the real problem.

Poor: The robot is not doing what we want it to do. I think the RCX is bad. How can I test to see if it is still good?

Smart: Using RoboLab 2.5.1 our robot does not stop at the proper rotation sensor count. Could the RCX be bad?

Smarter: Robot does not stop at the proper rotation sensor count using RoboLab 2.5.1. Reading the UFAQ and a search on the web has not provided any information that seems to fit our case. We have included a sample program. It runs on a typical robot using 24 to 40 gearing and the big bicycle wheels. The motors are on ports A and C. The rotation sensor is on port 1 and is geared at the same speed as the motor. Any hints for what we are doing wrong?

Describe the goal, not your approach

If you are trying to find out how to do something, begin by describing the goal. Only then describe the particular step towards it that you have taken. Without stating the goal, we have no way of knowing if you are even on the right path.

Poor: How can we reduce the power level on the motors below level 1?

Answer: You can’t.

Smart: Our robot is moving way too fast. We have tried to lower the power level down to 1 and it is still too fast. A few pointers to get us going would be appreciated.

Answer: Sounds like you need to learn about gear ratios. A great free resource is the chapter on gearing in “Building Mindstorms robots for FLL”. You can find it here: Building LEGO Robots for FIRST LEGO League

The smart version of the question is much better. The true goal (a slower robot) was stated given other Forum participants the chance to address your real problem (gears) not the red herring of power levels.

Be explicit about the outcome you are seeking

You are more likely to get a useful response if you are explicit about what you want respondents to do. Do you want pointers, somebody to check a program, provide a rule interpretation, or something else?

Poor: Our robot never seems to do the same thing twice in a row.

Answer: Sorry to hear that.

Smart: Our robot never seems to do the same thing twice in a row. We know it must be possible to get repeatable results but we can’t figure it out. The UFAQ has a paragraph on this issue but shies away from any direct answers. With time running out, we need a kickstart. What would you suggest for experiments that might help us figure out this issue?

Answer: What you are experiencing is very normal for a rookie team. To increase repeatability you need to run the following experiments. …

Don't bother asking for help on solving a specific mission

The whole point of FLL is to solve the missions in your own way. Asking for help is pointless. At best you will get the “That is up to you” answer or some tips on brainstorming.

This is not to say you can’t ask rule interpretation or strategy questions. For veterans these are often the most interesting questions.

Poor: How are we supposed to snag the znorknack?

Answer: Anyway you want.

Smart: Is it legal to snag the znorknack before pushing the flopersnork?

Answer:Interesting idea! Nothing in the mission descriptions or the rules precludes it so it should be permitted. Best of luck.

Follow up with a brief note on the solution

Post a reply after the problem has been solved to let them know how it came out. A short and sweet summary like: “It was a dead battery in my serial tower! Thanks, everyone. - Bill” would be welcome. Say what action solved the problem, but you need not replay the whole troubleshooting sequence.

Besides being courteous and informative, this sort of follow-up will help others searching the forum to know exactly which solution helped you and thus may also help them.

Last, and not least, the follow-up helps everybody who assisted feel a satisfying sense of closure about the problem. Trust us that this feeling is very important to those you tapped for help. Problems that trail off into unresolved nothingness are frustrating things.

How to Interpret Answers

If you don't understand the answer provided, do not immediately bounce back a request for clarification. Use the same tools that you used to try and answer your original question (Team manual, Rules, Mission Descriptions, UFAQ, the Web, …) to understand the answer. Then, if you still need to ask for clarification, exhibit what you have learned.

Example Questions

Poor: “How does a touch sensor work?”

Answer: “Inside the touch sensor is an electric switch that is connected to the touch sensor plunger. When released, the switch is open and when depressed the switch is closed. The RCX can sense the voltage difference between the two states. A current limiting resistor is added in series to the circuit to prevent damage to the RCX in the case the switch get connected to a motor port.”

Here the individual was probably interested in how to use the switch in a program or perhaps how to use it in a mechanism. What they got was an accurate answer to the question asked, but not the information they wanted.

Smart: “Where can we find some examples of using a touch sensor in a bumper? We have seen the ones in the Constructopedia.”

Poor: Where can I find out stuff about the rotation sensor?

Answer: Read the UFAQ or try a Google search.

Smart: I used Google to try to find “rotation sensor tank drive” on the Web, but I got no useful hits. Does anyone know where I can find information on using the rotation sensor in a tank drive robot?

Poor: Our program does not work. Is there a bug in the software?

Answer: Yes, you probably have a bug in YOUR software.

Smart: Our RIS program does not seem to work when waiting for a specific rotation sensor count. I read the UFAQ but some of the concepts go over my head. Is there a “Dummy’s Guide” or other documentation on RIS and rotation sensors for the novice?

Poor: Must the robot start inside the base?

Answer: Please read the rules, specifically the one on starting position.

Good: How much help am I allowed to provide to my team? They are stuck trying to get a working robot.

How to Answer Questions in a Helpful Way

Be gentle. The stress of the competition season can make people seem rude or stupid even when they're not.

Take negative comments off-line (private email). There is no need of public humiliation for someone who may have made an honest mistake. A rookie may not know how to search the forum or where the proper documents are located. A pointer in the right direction and a link to this document is all that is probably needed.

If you don't know for sure, say so! A wrong but authoritative-sounding answer is worse than none at all. Don't point anyone down a wrong path simply for the fun of it. Be humble and honest; set a good example for your peers.

Ask probing questions to elicit more details. If you're good at this, the asker will learn something — and so might you. Try to turn the bad question into a good one; remember we were all rookies once.

If you're going to answer the question at all, give good value. Don't suggest kludgy workarounds when somebody is using the wrong approach. Suggest the right path. Reframe the question for them.

Help your community learn from the question. When you field a good question, ask yourself “How would the relevant documentation or UFAQ have to change so that nobody has to answer this again?” Then send an update to the document maintainer.

If you did research to answer the question, demonstrate your skills rather than writing as though you pulled the answer out of thin air. Answering one good question is like feeding a hungry person one meal, but teaching them research skills by example is teaching them to grow food for a lifetime.

Acknowledgements
This document is an altered version of “How To Ask Questions The Smart Way” by Eric Steven Raymond and Rick Moen. The original (age inappropriate) version can be found at: http://www.catb.org/~esr/faqs/smart-questions.html

UFAQ Table of Contents
Home

Disclaimer: This FAQ is not an official FIRST document. It is an accumulation of knowledge derived from six thousand messages posted to the FLL forum over three seasons. It has been reviewed by numerous people, but may still contain errors. Use at your own risk.
Readers are encouraged to submit errors, suggested wording changes, new topics, or comments to Skye Sweeney at skye@fll-freak.com
Copyright 2003-2006 Skye Sweeney; Last Updated on 10/28/2006