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.