If I understand you correctly, your hypothesis is that a single individual has cast the sole too broad close vote on each of those six questions. I have good reason to believe that hypothesis is incorrect, since I cast the too broad close vote on two of them, and not on any of the others.
The two I voted to close as too broad were:
I do not believe either of those votes was in any way a mistake, though if you still think they were after reading this post, I'm open to criticism.
In this question, the OP asked how to write a complex, multi-part program that uses multiple application layer protocols to access an email service. (It only mentions IMAP but most likely, SMTP must also be implemented to send email.) Its wording also suggests the program should involve automatically installing Ubuntu programs or libraries and using them as backends.
Yeah, that's too broad.
It's also off-topic. The advantage of voting to close it as too broad was twofold:
It addresses the fundamental problem with the question. There are other SE sites where programming questions not specific to Ubuntu may be asked. There are no other SE sites where unfocused questions about how to perform a large complex programming task, with no specifics, no prior attempt, no implementation ideas, and no prior research are accepted.
Accompanying its initial off topic close votes was a comment telling the OP to ask the question on Stack Overflow. As discussed in subsequent comments, that would not be appropriate. Due to the specifics of the situation, the correct off topic close reason had the potential to contribute to encouraging the OP to re-ask the same question on SO. In contrast, the also correct too broad close reason would not contribute to that.
(It would have been better if I had also commented to say not to post it on Stack Overflow, rather than waiting for someone else to do so. In my mind, the question was so obviously too broad, that I expected it to garner other too broad votes that would effectively make this point without necessitating a discussion in comments. That was not good reasoning on my part, but voting to close it as too broad was still the right call.)
On that question, which as I write this is not yet closed but hopefully soon will be (unless it goes through a very major edit), you have commented:
This is not a question of the OS you use but of the options your router provides - hence off topic.
On the one hand, I do believe it's reasonable to vote to close that question as off-topic. If the OP really wants to accomplish this task with Ubuntu, far more information is needed. For example, if the router provides an interface to allow remote connections for purposes of traffic monitoring, the question would have to give specific details about that capability in order to get a useful answer.
On the other hand, it's not strictly true that this task cannot be accomplished with Ubuntu, nor that accomplishing it is necessarily OS-independent:
As I mentioned, some routers actually provide a way to remotely access that sort of information. This is particularly the case for commercial routers and for SOHO routers running "hacked" (i.e., community-supplied) firmware.
In this situation, software is necessary to connect to them. It may be a web browser, but it might be an SSH connection, or a USB connection to the device with proprietary device drivers, or other administration software.
Assuming the OP specifically wants to monitor wireless usage and attempted usage of their wireless router (many wireless routers also have LAN-side Ethernet ports), that can likely be accomplished, at least in large part, with Ubuntu (and depends heavily on OS-specific details).
Monitoring traffic on the network from an Ubuntu machine connected to it is entirely feasible: connect to the network and run a packet sniffer that has explicit Wi-Fi support. Many people believe that if you're connected a encrypted home wireless network, and you use a generally secure form of encryption (e.g., WPA2/PSK with WPS disabled), that one machine on the network cannot eavesdrop on connections between other machines on the network. That is almost always false. If you can connect to a wireless network where everyone uses the same key, you can listen in on everyone else. I believe unsuccessful connection attempts can be sniffed also.
The question contains no specific details to explain the OP's precise requirements or to identify or exclude any of the above possibilities. A full answer would be very, very long. It would probably have to start with a survey of all recent wireless routers--or router families--for home and commercial applications, and how they can be be configured. It would then move on to explain how software like Wireshark works and how to use it (some of that could be covered by linking to other questions perhaps). Then it would have to explain how to actually analyze the captured traffic to identify interesting usage patterns.
Most of that would be on-topic, Ubuntu-specific even. But that is a vast amount of information. The question is way, way too broad.
Perhaps I should comment to request more information. But I think your comment suffices; in the process of addressing what you have said, about how it comes down to what their router provides, they would probably fill in specific details of what they are asking for. Or your comment might fully point them in the right direction, which is good too.
I didn't vote to close any of the other questions as too broad and I don't think that close reason is a good fit for any of them. I don't even think they should all be closed. But I can easily see how someone consider them too broad. As this is mere conjecture, I'll run through it quickly:
- I think this one is a perfectly good, answerable question. It's reasonable to ask why continuing to install with media that's failed verification is a bad idea. But as there are very many things that might go wrong, I can see how someone might think it's too broad.
- This question is good, especially since it can be answered just by explaining what the proper documentation is and why it is proper. On the other hand, if one interprets it as asking precisely, in every respect, how does dpkg work--well, one could write a book on that. I interpret it as asking for docs and/or what specifically is inadequate about
man dpkg for package maintainers, and I think that's appropriately scoped for our site.
- There are many situations that could cause a Bluetooth adapter not to be found, each indicating a different solution. So too broad is actually acceptable there. I think unclear is best here--we know specifically what the OP wants (working Bluetooth), and really the problem is that there is not enough information to know what the problem is. In that scenario, unclear tends to be used. Then again, one could argue too broad fits that situation better than unclear. It depends if we interpret unclear to be about the question or about the situation being described by the question, I suppose.
- And much the same generality applies to a black screen on guest login.
