"Too broad" close reason applied to "restricted source" puzzle

Question

After posting a rather specific, narrow, restrictive, one-language (well... one group of languages: POSIX-ey shells) puzzle, thats been "closed as too broad", commentators then offered explanations inconsistent with the notion of "too broad":

1. "challenges that are restricted to one language are usually frowned upon." Which seems to imply the puzzle was not broad enough.

2. "a do X without Y challenge that is also frowned upon - why shouldn't I be allowed to use language Z?" This also seems to imply the puzzle was not broad enough.

3. "The default close reasons are set SE-wide and we can't rewrite then, so we make do even when they don't totally fit." Apparently at least one user feels the close reasons themselves are too broad, and closers are compelled to apply them too broadly -- presumably the closees are therefore expected to somehow infer (or guess) at the narrower reasons the closers should have given if only they could.

So assuming the above results are not anomalous, the question is: what has this usage "too broad" come to mean here, not literally as written, but in actual practice?

Answer 1

First off, I'm sorry that your first contribution to our site was so poorly received. I hope this doesn't discourage from posting more challenges. Writing good challenges is really hard, especially for users who are unfamiliar with our rules and culture. But, they are extremely important for the health of this community, and something I personally enjoy doing very much! If you do decide to write more challenges, the best tip I can give you is to use the sandbox! It's an invaluable tool for ironing the bugs out of your challenge before it can be downvoted and/or close-voted.

---

You are absolutely right. Your challenge got closed for the wrong reasons. Absolutely nothing about your challenge says "Too Broad" to me. For what it's worth, many users noticed that the wrong close reason was given, and complained (1, 2, 3). However,

• The challenge should have been closed, and

• Now that it is closed, it's not worth the effort to have 4 people re-open it and then another 4 people re close it.

The unfortunate reality is that we are a challenge site, stuck in the body of a question and answer site. The reasons a question can be closed are fairly straightforward and cover most of the bases. But there are many many reasons a challenge should be closed. I've certainly complained about this before.

This isn't the solution I'd like to hear, but the truth is that there will never be enough close-reasons to cover the various reasons that a challenge should be closed. Because of this, I don't think it would be that bad if a couple challenges have the wrong closing text on them. This isn't ideal, but it's the best we can do with the close-reasons we've been given.

Why do I say your challenge is low-quality? Nearly every rule in your challenge is either unclear or something that is heavily discouraged for writing challenges. Here's a list of things that stand out to me as I look at it. I don't want this to come across as mean, I'm just hopefully able to explain where the close-votes and most of the downvotes come from.

• It's language specific, which, as you already know, is heavily discouraged

• No numbers (in any base) in any of the code.

  The "No numbers" rule is fine, but what does "in any base" mean? Does that mean I can't use a string and convert it to a number? Does this mean I can't use the length of a string (which is arguable in unary)?

• No sed, awk, or external scripting languages.

  What?? But you said Using shell script and standard nix tools. Nearly everything in bash and nix tools is an external binary. Obviously, there is a distinction between ls and sed, but they are both external programs. This doesn't make it entirely clear where to draw the line. I'm pretty sure I could use cat and echo, but can I use grep? Could I cat some text into a file, and build it with gcc? Could I do it in a vi session?

• No more than 120 bytes of code, but shorter isn't necessarily better, it shouldn't tax the CPU.

  Limiting answers to code with 120 or less bytes is discouraged, and "recommend features" (short code, not taxing the CPU) is also discouraged.

• Bonus I: the same, POSIX compatible (no-bashisms). Bonus II: as a one-liner, with one semicolon at most.

  How can I easily determine if it's POSIX compatible? How large are the bonuses?

But here is the biggest problem with your challenge: You never specified who wins! Is it the shortest program? The first one? The one with the most votes? Whichever one you feel like? I find it kinda odd that none of the close voters even mentioned this, when that alone is enough reason to close a challenge, all else considered.

So in my opinion, "Too broad" was definitely the wrong reason to close your challenge. It should have been "Unclear what you're asking" or "Questions without an objective primary winning criterion are off-topic, as they make it impossible to indisputably decide which entry should win."

Now, do we expect every single user to read through that entire thread of things to avoid on your challenge? No, that's crazy. There's like 30 answers on that thread! But the best advice I could give you on your challenge is to focus less on what the program should consist of, and more on what the program should accomplish. For example, a much better version of your challenge would be

Write a program in any language that prints the text "foo" 100000 times without any digits (characters [0-9]) appearing in your source code. Each "foo" should be on its own line. The shortest answer, scored in bytes, wins!

Now, I'm not going to say that would be an incredibly perfect challenge, with hundreds of upvotes, but it would be acceptable, and would fix most of the problems that have been pointed out to you. (Also, FWIW, I challenged myself to do exactly that and then spent an hour working on a solution. I had a blast!)

And above all else, use the sandbox!

Answer 2

A hard-and-fast rule of the site is that challenges must have an objective winning criterion. As far as I can tell, your challenge doesn't have one. Oddly, none of the commenters mentioned that, but this is a plausible close reason for which "Too broad" may be seen as the nearest approximation.