I am another of the original close-voters. My thinking was similar to Tom Brossman's. While I didn't think the question's subject matter was necessarily too broad, I thought there were several different, related things the OP could have been asking.
Furthermore, it seemed that the question might have been intended as a feature request. Since posting feature requests here doesn't lead to features being implemented, where applicable I try always to ask an OP if they are requesting a feature and, if so, refer them to to the right places (usually Brainstorm and Launchpad).
It seems to me your edit substantially changed (or at least narrowed) the question.
Now the question is explicitly asking for auditing tools (rather than, say, a non-diagnostic sandbox for running an untrusted program to benefit from its functionality).
It was also not specified, or at least unclear, that an isolated environment was desired.
(Sometimes an isolated environment is not suitable--if the untrusted code is a module that must be inserted into a production machine's running kernel to provide support for some hardware, running it in a virtual machine or other isolated environment is unlikely to be an option--here, the better alternative to a sketchy driver is to seek a different driver or use a different device.)
When we know what an OP is asking and can answer it (and the answer would be appropriate for Ask Ubuntu), a question should never be closed. Here, I did not know what the OP was asking--and did not think it likely that others could confidently know either--so I voted to close the question with the hope that the OP would edit the question and/or comment, clarifying.
- I also posted a big comment asking the OP, in detail, about specifically what was intended, but I have since removed it as reopening the question rendered parts of it obsolete and potentially confusing.
Finally, some possibilities for what the OP was asking would be off-topic on Ask Ubuntu. Even now, I am unsure if it makes sense to have this question here--it would probably be a much better fit for IT Security. I am unsure if we can reasonably answer this question.
- Are there people here who can explain how some malware detects virtualization and acts nice, until it's brought over to a machine that it doesn't think is virtual?
- Are there people here who can explain how some malware is capable of spreading via virtual network (and/or shared folders) from a virtual machine to the host or to other virtual machines, even under circumstances where access to the physical network is limited?
- Are there people here who can explain how denial of service attacks are often easily carried out from within a virtual machine against the host machine?
- Are there people here who can explain, in detail and in a way that is practically helpful, how the barriers between host and guest are sometimes not nearly as strong as they seem, at the kernel/driver level of each system?
(Similar concerns often apply to other sandboxing methods besides virtualization.)
Still, I have no objection to your editing the question, or it being reopened.
While it's important to avoid turning one question into something altogether different (just because we can answer the different thing), and to avoid embracing questions we can't answer, it's also important for us to understand that the person chose to come to our community for advice. As Shog9 says in that article, when possible it's best to help a question fit into our community than to reject it; this seems to be the help you've given.
You were able to turn the question into something where the issue wasn't what it asked or if we could answer it, but how well. That was likely the right thing to do.
If someone had come here asking about how to deal with dangerous backyard pests, I'd firmly send them off to Gardening and Landscaping with a hoe and a kind word. But this is different. Once edited, this was clearly related to Ubuntu and of interest to our community. Therefore, even though we had good reasons for closing this question, I am inclined to agree with it being reopened.
- I'm still unsure if this is the best place for it. But with the clarification and information we provide, the OP can always post a similar, more narrowly crafted version elsewhere, should he so choose.
The second part of your question is about the problem of questions getting into the review queue and then being uncritically close-voted. Since I think it was reasonable to close this (though also reasonable to reopen it after your edit), I'm not sure that's relevant here. I know I didn't vote to close hastily; I put substantially more time and effort into this question than most questions I vote to close, both in considering whether or not it was right to close it, and in posting a comment detailing why and explaining how the OP could get it reopened. I have no reason to think anyone else was any less careful.
But what you're saying still is an important point and a real problem. Many questions are wrongly closed, and in a rush.
I don't agree with (at least my reading of) Tom Brossman that this is a result of people zipping through the game too quickly to get credit. I believe we have largely or completely solved that problem:
- There is now a maximum of 20 reviews per review type per day.
- In review, we all get the same credit for clicking Leave Open or Edit as for closing. (This is a very good thing, but it also creates a situation where the limit of 20 reviews makes sense. Please note that it is still possible for people with more than 20 close votes to close more questions after reviewing 20; just not by using review, and no review "credit" is assigned for it.)
If the review queue worked the same way but gave no credit at all and didn't keep track of how many reviews people had completed, I believe we would still have the problem of hasty closures, because:
- People want to move on to the next review item. Perhaps reviewing close (and reopen) votes should be a list instead of a queue.
- People assume a question with lots of close votes must merit closure, while actually it's more important to be critical the more close votes there are, since the more close votes there are, the higher probability your close vote will result in closure, and thus the more powerful it is. (Related.)
The introduction of the reopen queue is a substantial mitigating step, but this is still a problem. My recommendations for close-voting, to help address this, are that I (or any close voter) should:
- Be able to articulate clearly why the post should be closed.
- Comment unless it is overwhelmingly clear...and even then, usually. (But not if there is already an adequate comment. And not with text copied and pasted from the close reasons, as that's never helpful.)
- Assume posts are about Ubuntu unless there's reason to think they're not. Users of a Windows forum would never assume people are asking about another OS just because Windows was not mentioned specifically. I shouldn't start my day with the default assumption that nobody would use my OS, either.
- Don't stop reading as soon as I see words like "Mint" or "Windows." Often this indicates a question is off-topic. But we also have plenty of questions about how to install Ubuntu from another OS, or how to share files between Ubuntu or another OS.
- Assume the OP believes what they are telling me and might even know something I don't, unless there is major reason to think otherwise. Most people are not lying; sometimes something looks like it isn't Ubuntu (if I am insufficiently familiar with the subtopic at hand) but it is.
- When I think a close reason applies because of my understanding of the community consensus surrounding it, I should vote to close. If I am wrong, I can learn from my mistake, and the system is designed to accommodate differences of opinion among close voters. But when I think a question should be closed because some community consensus is wrong, I should come to meta first.
- Avoid close-voting spam. Spam should be flagged as spam--that deals with it faster and I don't waste close votes that are needed elsewhere. (Spam can also be downvoted, of course, but it should not generally be closed.)