General remarks
First of all, I appreciate the feedback. While good moderators can strengthen a site, bad ones (whether deliberate or unwitting) can be toxic. If any community member is unhappy with a moderator action, I'd much rather know about it.
Second, moderators do make mistakes. Community members do too — sometimes five of them together. Fortunately, nearly all actions are undoable.
As you've observed, languages with less traffic tend to get more moderator action and less organic closures/reopenings. As an objective-c reviewer, moderation affects you more than average.
How and why I decide to close questions
I often close questions that appear obviously broken, or that need clarification. I'd much rather put the question on hold while the author works out the issues. Fixing such issues after a first answer has been posted would generally invalidate any answers, so swift closure is beneficial.
Some reasons for reopening
If a question is marginal, I prefer to err on the side of leaving it open. This is especially true if the question already has an answer. If it stays closed,
- Early answerers will be unfairly rewarded with upvotes.
- Latecomers, forced to sit on the sidelines, will feel compelled to answer in comments instead.
- Having a half-dead question lying around doesn't do much good.
I'll usually consider the existence of an answer as evidence (but not the only factor) that the code is reviewable.
Specific question
My reasoning on question 59864 was as follows:
There were two existing answers, including one by you, before @Jamal closed it. I interpreted your answer as an expert assessment that the code was reviewable.
In retrospect, I suspect that you felt compelled to answer as a "rebuttal" to the first answer, which you felt didn't address the issues properly.
@Jamal wasn't sure about closing the question. He closed it with your support. So, there never was a community consensus that it should have been closed in the first place.
Even though the question mentions "architecture" a few times, it's not a high-level architecture question. For example, "Should I use WebSockets or polling?" would be an architectural question that is blatantly off-topic. On the other hand, this iOS question is asking about whether the code presented is sane or insane. I don't see such questions as being off-topic. The question could have been better if there were a more substantial amount of code, but there was already enough code to write two reviews.
Since it wasn't a pure architecture question to begin with, as soon as the word "architecture" was taken out of the title, I felt that it was good enough to reopen. (Remember, reviewers are free to comment on any aspect of the code, not just what the author wants to ask.)
It's sufficiently concrete that I doubt Programmers.SE would be interested in it. Basically, it's closer to being of interest to "Just You" than to "All Programmers".
Migration would probably be rejected. Bouncing hot potatoes between sites is horrible for user experience. Anyway, I think that the question deserves to be kept on Code Review on its own merit (even though it's not a great question).
Signposting
Stack Exchange moderators are encouraged to leave comments explaining their actions. In many cases, I do. However, as you can see, the reasoning here was quite complex. If I had write that kind of explanation for every routine action, nothing would get done. I'm glad to explain my actions on request, though. And if there is a general sentiment that I made a mistake in a specific case, I'll gladly undo my actions. If the community feels that I'm being too heavy-handed, I can act on that feedback too.
