25
\$\begingroup\$

In an effort to explicitly state our expectations for questions on EE.SE, I have adapted the StackOverflow Question Checklist by Jon Skeet. Below are a set of questions to check after you have written your question (or what to think about beforehand).

  • Have you done some research before asking the question? 1
  • Have you explained what you've already tried to solve your problem?
  • Have you specified part numbers for devices you're using, including packaging information where relevant?
  • Have you included links to all relevant datasheets?
  • If your question includes a circuit, have you included a schematic?
  • If your question includes schematic, have you checked that it's correctly formatted? 2
  • If your question doesn't include a schematic, are you sure it shouldn't?
  • If your circuit produces different results to what you expected, have you stated what you expected, why you expected it, and the actual results?
  • Have you checked that your question looks reasonable in terms of formatting?
  • Have you checked the spelling and grammar to the best of your ability? 3
  • Have you expanded all unusual/ambiguous acronyms and abbreviations? 4
  • Have you read the whole question to yourself carefully, to make sure it makes sense and contains enough information for someone coming to it without any of the context that you already know?

If the answer to any of these questions is "no" you should take the time to fix up your question before posting, by going through this list. I realize this may seem like a lot of effort, but it will help you to get a useful answer as quickly as possible; and you might even solve your problem yourself in the process! 5

In addition, when posting a question, you need to ensure you will be able to regularily check the possible feedbacks from other users, especially during the first minutes/hours after posting. Potential answerers may ask for clarifications or additional information, and if you don't reply in a timely manner, they may be tempted to let it go.

Don't forget that you're basically asking other people to help you out of the goodness of their heart - it's up to you to do all you can to make that as simple as possible.


1 If you went from "something's not working" to "asking a question" in less than 10 minutes, you probably haven't done enough research. This should include things like normal web searches (e.g. for an error message you're receiving), checking the documentation, debugging (particularly for exceptions) and searching on Electrical Engineering Stack Exchange itself for similar questions.

2 Olin Lathrop has written an excellent guide on making good schematics.

3 I realize that English isn't the first language for many Electrical Engineering Stack Exchange users. We're not looking for perfection - just some effort. If you know your English isn't good, see if a colleague or friend can help you with your question before you post it.

4 If in doubt whether an acronym needs to be made explicit, consider that anything less common than "MCU" should be clarified. Abbreviations are better avoided entirely.

5 This is a bit like rubber duck debugging.

\$\endgroup\$
  • \$\begingroup\$ My intent is to make a close reason similar to one on StackOverflow that links to this guide. Feel free to comment and suggest improvements. \$\endgroup\$ – W5VO Jul 2 '13 at 20:52
  • 6
    \$\begingroup\$ If a circuit is built from scratch, it is helpful to include a photograph. A lot of poor circuit behavior can be traced to poor construction techniques. \$\endgroup\$ – markrages Jul 2 '13 at 21:05
  • 1
    \$\begingroup\$ @mark: Careful with the photograph part. While seeing the mess can be good, too many people thing a photograph tells us all we need to know and therefore won't include other information. We get people posting pictures and wiring diagrams regularly that then don't post a schematic. \$\endgroup\$ – Olin Lathrop Jul 2 '13 at 21:53
  • \$\begingroup\$ How to properly include photographs is a whole sub-topic on its own. Maybe that should be in a separate place with a link from here soo it doesn't look like we're overwhelming them. \$\endgroup\$ – Olin Lathrop Jul 2 '13 at 21:54
  • \$\begingroup\$ @OlinLathrop Did you make a guide on pictures, or am I imagining things? I think I'd link to the guide via subscript. \$\endgroup\$ – W5VO Jul 2 '13 at 22:05
  • \$\begingroup\$ @W5VO: No I haven't made a guide to pictures, but that is perhaps something we should have. We get a lot of really inappropriate and bad pictures here. \$\endgroup\$ – Olin Lathrop Jul 2 '13 at 23:16
  • \$\begingroup\$ link to photog.SE lazy? \$\endgroup\$ – Kortuk Jul 3 '13 at 1:05
  • 1
    \$\begingroup\$ I'm surprised by how many people don't even crop their photographs. The other main problem I see is badly out-of-focus photos. A guide to taking close-up photos of PCBs, breadboards, compnents etc would be a good idea. \$\endgroup\$ – RedGrittyBrick Jul 7 '13 at 7:33
  • 1
    \$\begingroup\$ I recently joined a Hungarian electronics site. (I do not speak Hungarian; there is some English-language activity on the site.) It's called Elektrotanya. I've often obtained hard-to-get schematics for old gear from there prior to signing up. The site is invitation only, and there is a self-serve process for generating an invitation for yourself: you have to pass a five question, multiple-choice electronics quiz consisting of a smattering of electrical safety, ohm's/power law, safety, and rudimentary radio ham knowledge. If you pass, you get an e-mail and you can then create an account. \$\endgroup\$ – Kaz Jul 10 '13 at 0:45
  • \$\begingroup\$ This only holds for Circuit Design & Development. Which i think is the real scope on here. \$\endgroup\$ – Brethlosze Dec 8 '17 at 4:36
  • \$\begingroup\$ @hyprfrcb Are you talking about your most recent question? That was about electrical code compliance - you need a licensed electrician, not a EE. \$\endgroup\$ – W5VO Dec 8 '17 at 11:47
  • \$\begingroup\$ Would you agree to make this post community wiki? I wanted to expand (following this meta post), to add two bullets: 1) providing all links to relevant datasheets, and 2) expliciting unusual acronyms (I think this is often a mistake made by new users). But since you're still the owner of this post, I'm not sure you want me to make additions... \$\endgroup\$ – dim Jun 15 '18 at 18:58
  • \$\begingroup\$ @dim Just make the changes - community wiki is depreciated. \$\endgroup\$ – W5VO Jun 15 '18 at 19:56
  • \$\begingroup\$ @W5VO Thanks, I'm doing it. But I'm surprised. Where did you see it is deprecated? \$\endgroup\$ – dim Jun 15 '18 at 20:03
  • \$\begingroup\$ @dim It's depreciated in that regular edit permissions have been expanded to make CW unnecessary. Even anonymous users can suggest edits, I believe, making the "any user can edit" feature of the wiki superfluous. \$\endgroup\$ – W5VO Jun 16 '18 at 1:34
5
\$\begingroup\$

Unfortunately I feel that someone asking a question on EE.SE that couldn't be bothered to perform some internet searches, also cannot be bothered to read a checklist. Even if it's short and concise (which it should be), they are going to cast their fishing line and hope for a bite.

That said, I totally support a checklist. Those asking a question that have done some legwork beforehand could greatly benefit from a few reminders. I know I've personally asked questions and forgot to link a datasheet, editing the question later with relevant information.

\$\endgroup\$
  • 1
    \$\begingroup\$ I might have asked this before, but is there a way to make the checklist pop up when a first time poster tries to submit a question, and them dump him back to the edit window to make changes, if appropriate? \$\endgroup\$ – Scott Seidman Jul 12 '13 at 16:01
  • \$\begingroup\$ In deference to the checklist, I mean "convenient way that is in the stack exchange framework". Of course, there's usually a way to do something if you throw enough resources at it! \$\endgroup\$ – Scott Seidman Jul 12 '13 at 16:02
  • 1
    \$\begingroup\$ Rather than a checklist , perhaps proposed format options given in the question form. $$ Problem Summary: Purpose : Specs : Environment: Schematic: Parts: datasheet links: Acceptance Criteria : Technical Fault or misunderstanding $$ \$\endgroup\$ – Tony Stewart Sunnyskyguy EE75 Jun 21 '18 at 0:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .