I just failed an audit on a question that should be closed. Why? Because it has 5 upvotes and no close votes:


Look at the question. It's obvious it's one that the community likes, but is that a valid reason to put it as an audit? Maybe not, but because it has 5 upvotes and no close votes it should be put in the queue!? NO.

This question is asking why gcc and Visual Studio do something different with the same block of code. That is obviously off topic, but NO; The community likes it, so it has to be an audit. Really?

Now, before you tell me that it's just a simple little audit, I have failed others just like this one before. I know I'm most likely not going to deserve a "break", but something needs to be done about this. Maybe we could start by STOPing the automatic selection of "good" review audits? You rarely ever see a "close" audit on a good question, but you often times (relative) see "leave open" audits on bad (off-topic) questions. So, if we should not automatically choosing them, what do we do?

We have the moderators or some other group of people review them. That might work, but it puts another moderation job on people who are already tired of working on the close votes queue. If we don't want to do that, maybe we could invalidate failed audits if enough people fail them?

For example, say 5 people failed this exact audit, but only 1 passed; It's pretty obvious it was a bad audit, so we should invalidate the audit so people don't get closer to a ban (sorry - a break) for failing a bad audit. Essentially, just throw the audit out the window and recalculate the "should we give them a break" percentage. That might work the best. However, it requires that audits are shown to multiple people. I don't think that's the case. If I am the only one who will receive this audit, then this solution won't work.

We could change it so multiple people recieve the same audit, and then implement the StackExchange™ Audit Invalidator™, but my question is long enough. For the question in question (hehe), here it is: C++ programming riddle, fun with function pointers.

  • AGAIN and AGAIN!
    – Cole Tobin
    Aug 4, 2013 at 2:00
  • 3
    Your cookies are a lie.
    – jscs
    Aug 4, 2013 at 2:01
  • @JoshCaswell would you prefer a cake?
    – Cole Tobin
    Aug 4, 2013 at 2:01
  • 3
    No, I really like cookies. That's why I'm so disappointed.
    – jscs
    Aug 4, 2013 at 2:02
  • @JoshCaswell at least they're not oscillating
    – Cole Tobin
    Aug 4, 2013 at 2:04
  • 3
    On topic, though, your feedback idea -- using the pass/failure rate of the audit to gauge its validity -- is interesting, but it does create a loop that seems problematic. If the only audits that count are those that most people pass, how do we catch people failing audits? Maybe some simulated numbers would help here.
    – jscs
    Aug 4, 2013 at 2:05
  • @JoshCaswell you essentially "flip" the audit. The majority rules if it's good or not. If it's deemed bad, then the people who failed are fine, but the people who "passed" are given the audit again to see if they've learned. If they fail at it a second time, they're doing bad. If they pass, yay! Something like that might work. I'm just brainstorming.
    – Cole Tobin
    Aug 4, 2013 at 3:22

2 Answers 2


To elaborate a bit on @djechlin's answer, I'll go into why this is not off-topic. Take a look at the Help Center article on what is considered to be on-topic. Specifically, these are on-topic:

  • a specific programming problem
  • software tools commonly used by programmers
  • practical, answerable problems that are unique to the programming profession

This question satisfies three of the four checks for appropriateness. It has a definite answer, is about programming, and is a specific tool used in programming. So, I disagree with you: this is an on-topic question, and the review audit (in this case) was successful.

  • What about the others?
    – Cole Tobin
    Aug 4, 2013 at 3:19
  • @Cole Which others? I excluded "a software algorithm" because that isn't applicable.
    – user206222
    Aug 4, 2013 at 3:20
  • I meant my other ones. (My comment on the question)
    – Cole Tobin
    Aug 4, 2013 at 3:22
  • 1
    @Cole That first audit is questionable, but vaguely on-topic (if slightly unclear about what they're asking). The second audit seems definitely on-topic to me. What close reason were you reaching for?
    – user206222
    Aug 4, 2013 at 3:24
  • Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
    – Cole Tobin
    Aug 4, 2013 at 3:28
  • 4
    @Cole You're right, questions must show a reasonable amount of effort. Think from the perspective of the asker: If you have no idea what's going on, how would you search for something like that? The askers have made an effort to understand the problem, and this is apparent. That's where Stack Overflow helps; where users don't know what they need to know to answer their own questions.
    – user206222
    Aug 4, 2013 at 3:32
  • To me, just asking, "why does it do this" isn't reasonable effort. Taking a guess or at least mentioning that they can't figure out why is effort to me.
    – Cole Tobin
    Aug 4, 2013 at 3:47
  • 3
    @Cole Different questions require varying amounts of effort. If the question is one which the user cannot reasonably answer, then it is a good fit. If the user could have figured it out with more research and time, then they either need to demonstrate that effort, or look into it further.
    – user206222
    Aug 4, 2013 at 3:50
  • 7
    @ColeJohnson I think you may be interpreting the close reasons a bit too strictly and literally. Given enough time and effort, every question on Stack Overflow can be answered without asking it on Stack Overflow. Clearly, that isn't the intent here.
    – Adam Lear StaffMod
    Aug 4, 2013 at 4:04
  • 3
    Using VS to explain weird behavior in gcc was research effort.
    – djechlin
    Aug 4, 2013 at 11:42

Back up.

This question is asking why gcc and Visual Studio do something different with the same block of code. That is obviously off topic

That is clearly on topic and I have no idea why you think it could possibly be off topic. Which therefore means, the audit worked fantastically.

Sometimes audits serve the role of getting people back in line with community standards. The fact that you came to meta to post about this means it's working great. Can you please explain exactly why you think that question is off topic? At the risk of asserting my own opinion and judgment as fact, the question is emphatically not off topic.

  • There is no effort given. Remember that the definition of on topic is different now.
    – Cole Tobin
    Aug 4, 2013 at 3:18
  • 2
    @ColeJohnson proof of effort is overrated. "proof of effort" are merely words the community uses to close the questions they don't want. Aug 4, 2013 at 4:58
  • @Jan Was that explained on the announcement of the new close reasons? No. So, that shouldn't be a rule of thumb.
    – Cole Tobin
    Aug 4, 2013 at 5:05
  • @ColeJohnson you are free to comment there. I think it would be nice to clear that up, but it was stated several times that the way close reasons are worded reflects the reasons community uses to close, not to steer community towards a particular closevoting pattern. Aug 4, 2013 at 5:07
  • @ColeJohnson firstly if that's why you are saying this is on topic, you should say this somewhere in your question. At present you're exactly saying that a question "asking why gcc and Visual Studio do something different with the same block of code" is "obviously off topic." Secondly, for this question using Visual Studio was research effort. The OP got weird behavior on gcc so tried Windows. Anyway I'm guessing it's you who voted to close that question. The OP is confused and asked what's wrong with it, go try to explain your reasoning.
    – djechlin
    Aug 4, 2013 at 11:40

You must log in to answer this question.

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