###...except when fixing typos and formatting establishes that the question should remain open!

I agree with your general point here--the *Edit* button in the close queue means "this should be edited instead of being closed." It's not the only way to edit a post that is in the close queue; reviewers can choose to click the post link and edit it as usual, which doesn't drop the post from the queue.

The post *goes back in the queue* if it gets *one more close vote* though. (I quite distinctly remember a Stack Exchange employee explaining this. It might have been Shog9 but I'm not sure. In any case, if you believe Edit-reviewed posts are *not* being requeued by subsequent close votes, I recommend filing a bug on [MSO][1].)

I believe these are the appropriate general guidelines:

- If a question should be closed and also edited, it **shouldn't** be edited in the queue.
- If a question should be kept open and edited but the edit has no significant relationship to how it should be kept open, it **shouldn't** be edited in the queue. (Unless, I suppose, everybody already has come to agree it should stay open, as then there would be no harm in knocking it from the queue.)
- If you're not sure whether a question should or shouldn't be kept open, and the edit you want to do isn't likely to change this or clarify it to anyone, it **shouldn't** be edited in the queue.
- If the edit **does change** the post from being worthy of closing or not worthy of closing, or it clarifies why the post should remain open, or the problems with the post never required closing and are fixed by editing, it **should** be edited in the queue. This is why there is an *Edit* button in the close queue. It is by design that users will click the *Edit* button in this situation, and the newly edited post will be dropped from the queue.
- If the edit creates a significant likelihood that voters who have already voted to close the post will change their mind, it **should** be edited in the queue.

I do *not* agree that moderators should unilaterally close questions because someone reviewed them wrong in the close queue. The solution to the problem here is more close votes, putting them back in the queue, which appears to be what is happening. I, and others before me, have now voted to close the three out of the four questions you listed that should actually be closed.

For http://askubuntu.com/questions/407178/iso-to-img-permission-denied, you said "not sure why this one was being closed." But then you [asked moderators to close all the questions][2]! It's to avoid these sorts of mistakes and inconsistencies that the normal, slower 5-votes system exists. Even when a question that *should* be closed gets incorrect reviews, this can usually be corrected within the system. And of course you've done the right thing by bringing this to meta, so users with close votes can cast them as needed.

If you have links on hand to more questions like these, you might want to add them to your question here. Then all of us (who want to) can look at and (where appropriate) vote to close them, as well.

###http://askubuntu.com/review/close/210585 seems wrong, but is perhaps understandable.

There, the first duplicate close vote came a few hours before the *Edit* review that dropped it from the queue.

- *If* the editor agreed it should have been closed, they should have gone to the post (through the post link) and edited there instead.
- *If* the editor thought the edit, by making the code more readable, clarified that it actually wasn't a duplicate of the proposed question, then they were using the system correctly. However, it would have been much more helpful to add a comment in this situation. In any case, it really does seem to be a duplicate.

###http://askubuntu.com/review/close/210502 is an excellent illustration of your point.

Here, the edit helped slightly in clarifying that the post *should be closed*, so it was quite incorrect for it to have been applied as an *Edit* review. Furthermore, the original close votes came many hours before the edit. The editor does not appear to have disagreed with the question's closure. Dropping the post from the close queue was probably unintended by the editor.

###http://askubuntu.com/review/close/210502 was actually correct.

You said the edit to http://askubuntu.com/questions/407178/iso-to-img-permission-denied doesn't modify anything relevant to the question. But actually, it did.

This is a question about a problem creating an Ubuntu live USB that will boot on a Mac. The question [did not originally specify][3] what instructions were being followed, which made it unclear. The OP then [expanded the question][4] to include this information. That rendered the close vote obsolete (if it came before) or wrong (if it came after). At this point:

- *Any* further edit was *correct* to apply with the *Edit* button in the queue, because it was manifestly clear the post should no longer be closed. And the reason it should no longer be closed was that it was fixed by editing, so the "edit reason" even applied.

But I understand that might possibly be controversial. (I even included this sort of situation in parentheses in my list above and presented it a less authoritative tone, in recognition that someone might possibly disagree with it.) Fortunately, there is another related reason:

- [The edit you say didn't modify anything relevant][5] improved the display of the link whose presence was the reason the post was *no longer unclear*. The post was thus then even more clear. Furthermore, by adding the title of the linked post, the edit clarified that the problem was occurring when trying to create Ubuntu installation media. (All the `%20`s in the URL itself probably made this considerably less obvious before.)

    In other words, this edit was a direct extension of the previous edit, which brought the post even closer toward the goal of the previous edit. And the previous edit was what made the post no longer unclear and no longer a good candidate for closure as unclear.

###http://askubuntu.com/review/close/206035 wasn't as bad as it sounds from your description.

Presumably, http://askubuntu.com/questions/401436/why-am-i-unable-to-login-in-a-terminal-window had an "unclear" close vote, putting it in the queue. Assuming that is the case, I believe this is what happened next:

- For that post, the *unclear* close reason was wrong. It was a bit unclear, but not in a way that couldn't be fixed *by editing*. Closure for this reason was not correct.
- So the reviewer **did the right thing** and edited it. This dropped it from the queue, which is the way the system is supposed to work.
- For the *entirely unrelated* reason that this question has been asked and answered elsewhere--a matter further clarified by the edit--the editor noticed that it was a duplicate, and voted to close it as such. This put it back in the queue.

Would it have been better if the reviewer who edited had immediately recognized that it was a duplicate in the first place? Sure, but we don't all immediately know about every question that's ever been asked or answered on the site. It appears no one had suggested it was a duplicate, yet.

So in the case of [that fourth review][6], it seems:

- The reviewer used the system as it is meant to be used.
- The post was out of the review queue... for a few seconds before it went back in.

Of course the post may then later have fallen out of the review queue due to insufficient votes. Or several *Leave Open* votes. Since the original *unclear* close reason wasn't applicable at all to the question, any reviewer who saw the question *before* the correct duplicate vote and *didn't* know it was a duplicate would/should have clicked *Leave Open*. (I'm not sure if posts with multiple previous *Leave Open* votes *re*-enter the close queue with just one *Close* vote.)


  [1]: http://meta.stackoverflow.com
  [2]: http://meta.askubuntu.com/questions/8119/please-dont-use-the-edit-button-in-the-close-queue-to-correct-typos-or-improve#comment14515_8119
  [3]: http://askubuntu.com/revisions/407178/1
  [4]: http://askubuntu.com/revisions/407178/2
  [5]: http://askubuntu.com/revisions/407178/3
  [6]: http://askubuntu.com/review/close/206035