Hello everyone,

I've been using/contributing to SO for over a year now, and recently, I noticed that my questions are getting exceptionally low views (like 5 in the first 24 hours) and I usually only get 1 half-assed answer from someone who kinda knows the subject.

I'm not really sure if this is a problem with my questions (which I try to make succinct and well-written), their title, or if it's just the new nature of SO.

So, below are a few of the questions that I've asked most recently. I would love it if you could provide some feedback on how to make my questions better and perhaps be more apt to be answered by the gurus here on SO. I feel like I'm throwing questions out into space and they are disappearing into thin air almost immediately. It's slightly frustrating, but I don't know what to do.

  1. Rails Project - API Design Questions
  2. Should I use from_xml or from_json for importing objects?
  3. Good ways to manage a changelog using git?
  4. How do I stop firing two events using sortable and droppable?

Thanks very much for any input.

Edit: Just wanted to say thanks to everyone for the very quick feedback! I'm going to leave the question open for a bit in case anyone else has some more feedback, but I'll accept an answer later today.

  • It looks like the middle two received pretty good answers. They may not have received numerous answers because the questions don't have numerous answers. #1 is a little on the subjective side and people may not want to write as much detail as the question seems to call for. And #4... well, I can't explain that one, it looks fine to me, maybe you just got unlucky.
    – Aarobot
    Commented Aug 26, 2010 at 17:01

5 Answers 5


From How to bring attention to an old question you didn't ask to bring it up to date?

  1. Try To Be Clearer
  2. Try To Be Shorter
  3. Update Based on Community Input
  4. Do Extra Research, Help Solve It Yourself!
  5. Add A Bounty

As a continuation of that, in How can I attract the experts to answer my very specific question?

Basically the best way to look at each question is "why should [the experts] care?"

  1. It's easy. Low effort to solve.
  2. It's really difficult. Hard effort to solve. (some people love pain)
  3. It's high visibility. Lots of rep involved.
  4. You're clueless. Some people love to help.
  5. It's an interesting problem.

To combine the two answers. Basically you need to:

  1. Ensure that the question is answerable. That's what the first answer I linked is for. It includes all the information as to how to format your question to ensure that it has everything it needs to be answered.

  2. Ensure that people will want to answer it. This includes that you not make any absurd or insulting comments about any of the technology you are asking for help in. It also means that you need to consider the motivation of the people who would answer. This is what the second link provided is for.

  • @Jon B "Try To Be Shorter". You're always telling me that. But I think sometimes you need to elaborate more on your posts. - devinb.
    – user27414
    Commented Aug 26, 2010 at 15:46
  • Opps - I'm sorry, I got us mixed up there for a second.
    – user27414
    Commented Aug 26, 2010 at 15:47
  • Re: your edit: Oh, phew, that's better.
    – user27414
    Commented Aug 26, 2010 at 15:50
  • @JonB I was hunting down the second link. I have nearly 400 answers to sift through.
    – devinb
    Commented Aug 26, 2010 at 15:52
  • +1 - Thanks very much for the feedback. I'll try to update some of my questions/titles to make them a little clearer and to the point. I really appreciate the links to the other answers. Commented Aug 26, 2010 at 16:32

I'm actually a little surprised that some of your examples got such low views. But in general, here are some tips that I think apply here:

Write specific titles.

Your "Rails Project - API Design Questions" title is not specific. Vague titles do not entice a reader to click on your question. I would imagine "API Design Questions" is long winded and rambling (without clicking on it - I'm just assuming). That brings me to my next point:

Keep your questions short and specific.

If your first three paragraphs are background about your project and you bury the question in somewhere at the bottom, people will skim or stop reading altogether.

If you need some explanatory text, put it after the actual question and highlight the actual question in bold to draw the reader's attention (see how you just read that?)

Avoid subjective topics.

Some of your questions are borderline subjective ("Should I use from_xml or from_json for importing objects" and "Good ways to manage a changelog using git"). Try make these more specific and technical, like "How do you manage a changelog using git?".

One final note: understand that not every tag on Stack Overflow gets the kind of traffic some of the mainstream tags get. The [ruby-on-rails] expert pool is a lot smaller than the [.net] pool here on SO. Even with well worded questions you might not get the kind of traffic you were hoping for. (I did it again - isn't bold clever?)

  • 1
    +1 - Thanks for your comments regarding highlighting the question and subjective topics. I hadn't really thought of mine as subjective, but now that you mention it, they really are. Commented Aug 26, 2010 at 16:33

In addition to all the great advice already provided...

I think the shared theme in all your questions is that they are stories about you instead of stories about programming.

All your questions begin with something like I've been doing such and such and.....

Instead your questions should begin with something like, What is a method of doing....

You should try and think of the heart of your question, and present only that, preferably with a quick example. The questions are tailored very much to your projects, instead they should be tailored to the generalizations of the problems you encounter in your projects.

For example:

Hello all,

I've been using Git for a while now, and I recently started using it to tag my releases so that I could more easily keep track of changes and be able to see which version each of our clients are running (unfortunately the code currently mandates that each client have their own copy of the PHP site; I'm changing this, but it's slow-going).

In any case, we're starting to build some momentum, I thought it would be really good to be able to show people what has changed since the last release. Problem is, I haven't been maintaining a changelog because I don't have a good idea of how to go about it. For this particular time, I can run through the log and manually create one, but that will get tiring very quickly.

I tried googling "git changelog" and "git manage changelog" but I didn't find anything that really talked about the workflow of code changes and how that coincides with the changelog. We're currently following Rein Henrichs' development workflow and I would love something that went along with that.

Is there a standard approach that I am missing, or is this an area where everybody does their own thing?

Thanks very much for your comments/answers!

Could become something like:

Hello all,

I use Git to manage an app. How could I show the changes made to my app from release to release? I'd like to present these changes in a well formatted manner that is easily understandable to non programmer users of the app.

I tag each release.

So far I've been manually going through the change log and summarizing it for each release. Is there a better way of doing this?

We are currently following Rein Henrichs' development workflow and I would love something that went along with that, but any help is appreciated!

That's a first draft, but the idea is to make the question useful to as many people as possible while maintaining its pertinence to your situation.

  • And it could lose the Hello all/thanks (I think)
    – Benjol
    Commented Aug 27, 2010 at 7:47
  • Thanks for the rewrite! That actually does help a lot. I guess people don't really care why I'm asking the question as much as what the question is. @Benjol - I generally put the hello/thanks to be courteous; but if many people think it's unnecessary, I'll definitely remove it. Commented Aug 30, 2010 at 19:55

To be specific about your 4 cases:

For the jQuery question I think the problem is:

  • Requires someone with expert knowledge of UI draggables & droppables
  • Is too long and would be better explained with a simple code example
  • Requires someone to set up a specific coding example from scratch to come up with and validate an answer which would take approx 15 - 30 minutes

Suggestions for improvement:

  • Cut down on the wording and provide some simple code and even better a link where someone could view your example
  • A link for someone to download your current example so they don't have to replicate everything from scratch (this is not 10 lines of code, this requires quite a detailed setup)

For the other three questions:

  • Require a lot of reading. By the time I have read everything you wrote I find myself reading it over a few times because I'm not quite sure what you are asking
  • Don't require or ask a specific clear question
  • Require someone to answer with a long winded answer rather than something specific (ask something vague get something vague)

Suggestions: - Cut down on the writing and ask something specific e.g. When converting from php to Rails which of these methods is preferred: from_xml or from_json. Please provide clear examples to back up your arguments.


Good meta topic, really.

But nevertheless I think that not bold makes topic more readable, especially when it dazzles but style of narration, clear topic, interesting and finite question, etc. Other answers are right about that. Quality not quantity. Style of text but not style of formatting makes question more readable. Am I clear?

  • I understand what you're saying (I think) about the text needing to be more readable from a comprehension standpoint; however, I think there is still a reason to style the text. It can help emphasize a particular point or, in the case of a heading, provide enough whitespace so that the paragraphs are cleanly separated. Perhaps we just have two separate schools of thought :-) Commented Aug 31, 2010 at 19:58

You must log in to answer this question.

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