OK, so when talking about the explanation being “sparse”, you can be talking about two things:
What is expected is not adequately explained.
How to do it is not adequately explained.
I think that the explanation adequately explains what to do. It starts with:
Create a function that sums two arguments together. If only one argument is provided, then return a function that expects one argument and returns the sum.
That is abundantly clear to me exactly what is required. Then it additionally provides two examples of what is expected for both possibilities. Reading the test cases will further clarify what to do in cases of bad data. (If I had a criticism of the problem statement, it is that it should explicitly state how to handle other data types rather than have you figure it out by looking at the test cases.)
I don’t see how what is required could be any clearer. You state, “Where I work if a ticket / bug is ambiguous the devs are told to not work on it until there is a clear explanation of exactly what the product owner wants. [emphasis added]” Yes, again, “what is required/wanted”. I would agree for the most of the part that that should always be there. Of course, at my work, I’m often working on new features that aren’t as fleshed out as I’d like, and we’re and Agile environment so we often go with it until we can clarify with the UI/UX team, but I agree that the ideal is that what is clearly stated, and especially in a learning environment. But it is clearly stated in this challenge. Is there another interpretation of those instructions?
So that leaves us with how. When you get a ticket, does it tell you how to do it? Do they tell you which libraries to use and which algorithm? Your work place must be very different than mine. First of all, we all pretty much know how to do it, and if we don’t we grab another dev and whiteboard it out. I can’t remember a ticket ever telling me how to do these things. In fact they’re usually written by non-coders so they wouldn’t even know how to do that. Yes, our team would eagerly refuse to work on something if we didn’t know what was required - we’ve certainly kicked things back to UI/UX before, but if I refused to do something because I didn’t know how, I wouldn’t last long.
A learner at this point should have learned everything to complete this challenge. Now, FCC does move rather quickly and (I presume in the interest of not boring people) does go over things over and over so it is easy for people to not remember every little thing. But again, I think that is a good thing. On a good day I only google or check the docs on something a few times an hour. This is a fundamental skill of dev work. I might even argue it is one of the most important. I think this is a good way to teach this skill. I think we would be doing a disservice to the learner by spoon feeding the learner every little thing about how to solve the problem.
But that information is a click away with the “Get a hint” button. Many learners may specifically not want the hints on the main page. I for one generally like to try to find an answer on my own before getting hints. I expressly don’t want to see the hints. I learn more when I figure it out, or even fail for a while before looking at a hint.
Now, I will be the first to admit that FCC is not perfect. It is an open-source, non-profit site. There are a lot of mistakes. There are a lot of things that can be improved. I’ve made some PRs myself. You are welcome to do the same. But reading over this example that you provided, I don’t agree with the criticism. I don’t think the hints should be on the same page as the problem statement. I’m sure there are some problems where what is expected is not adequately or correctly explained. I’ve found a few myself. If you find some, please make an issue on the repo. But if your issue is that the problem statement doesn’t tell you how to do it, I think you’re going to get a lot of people disagreeing with you.