Sometimes, when deciding what to ask, the issue of how broadly scoped a question should be is relevant. This would be especially true when regarding policy or standards development as the process can take a long period of time and encompass many aspects.

As a site, how broad a scope should we encourage and/or discourage. As a punching bag, let's use my recent Secure Programming question as an example. Is that question scoped too broadly? Should we disourage such 'big' questions and instead encourage users break their process down into smaller chunks and ask about those specifically?

3 Answers 3


I dont think that question is too broad, sometimes what you need is the "big picture".
Especially when it comes to the non-technical questions, I think we're bound to have questions that require the broad answers.

On the other hand, if the asker wants a specific, detailed answer, the question should of course be specific.
Also, if it's TOO big, there's a lower chance that someone will give the entire broad answer, just cuz its potentially so big.

  • 1
    Also, if it's too specific, it may borderline on "too localized" - although I don't see many threads actually get closed for that.
    – Iszi
    Jan 28, 2011 at 16:39
  • @Iszi, I actually have closed one or two q's here for "too localized"... dont remember which though. But it was because it was way too specific...
    – AviD Mod
    Jan 29, 2011 at 23:30

There will always be some questions which, through no fault of the owner, will generate answers in an entirely different direction to that intended, however we probably should add something to the FAW in addition to the context background piece which will help to define the type of answers the asker wants to recieve.

I'll think up some wording around this and pop it up for thought.

Right - popped an updated FAW, including a quick mention of specific questions in the "what background" section discussed here: FAQ: request context and threat models

Have a look, and let a mod know what you think :-)


Hmm. That question does seem to perhaps run afoul of at least some of the guidelines in the faq.


It's kind of nebulous, broad and hard to answer as stated, isn't it? And it could conceivably have infinite answers, could it not?

I'd say make it a bit more technical and a bit more specific about what you are looking for.

What kind of questions should I not ask here?

You should only ask practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page. To prevent your question from being flagged and possibly removed, avoid asking subjective questions where …

  • every answer is equally valid: “What’s your favorite _____?”
  • your answer is provided along with the question, and you expect more answers: “I use _____ for _____, what do you use?”
  • there is no actual problem to be solved: “I’m curious if other people feel like I do.”
  • we are being asked an open-ended, hypothetical question: “What if _____ happened?”
  • it is a rant disguised as a question: “_____ sucks, am I right?”

If your motivation for asking the question is “I would like to participate in a discussion about _____”, then you should not be asking here. If your motivation is “I would like others to explain _____ to me”, then you are probably OK.

  • 1
    the problem here is that many of the questions we need to handle, are not strictly technical questions. In a lot of cases, there is no one empirically-proven all-correct answer that owns the rightness. Consider the types of questions on Programmers.SE... A lot of our questions are like that, "how do you handle...". Moreover, security is inherently about trade-offs, and these are by definition subjective. Yes, of course we can talk about what trade-offs make sense, and which do not, but that leaves us with a large range of "correct" answers.
    – AviD Mod
    Jan 30, 2011 at 8:33

You must log in to answer this question.

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