Here's what Bjarne Stroustrup said on this topic during the 2017 CppCon "Grill the Committee" panel (at t=14:23).
TL;DR: Bjarne observes that there's a lack of collaboration, a not very useful expectation for proposals to be made with details fully fleshed out, over-focus on technical details, and lack of focus on the problem and use-cases. He'd like to see a change towards the opposite: Starting with a clear problem and important use-cases (without expecting whoever raises the proposal to have a "perfect solution" ready), and then having the committee work collaboratively on designing solutions.
Jon (the host of the panel) asked the panel members:
You guys particularly are all associated with something you were pushing for, but in the committee, you could almost think of it as you wear two hats. You wear a hat where you're trying to push a particular proposal, and you wear a hat where you're trying to push back on proposals. 'Cause that's the game, right? So, I want to ask you to think about a situation and you don't all have to come up with this, but if we had some interesting stories that's what we'd want tonight, where you got pushed back, where you first thought it was kind of ridiculous, "okay I'll think about how to deal with that", and then realized, "oh wow, this proposal has really benefited because of something I hadn't thought through well" and at first, it wasn't an "oh wow, brilliant!" At first, it was like an (growls). But then you said, "no no, now I realize what's going on". Anyone want to fess up to that?
Bjarne:
From my perspective, I think it's the wrong question. Because my ideal way of having proposal develop, is that you articulate a problem, and then you articulate sort of a first idea of how to solve that problem. And then, you discuss- in committee and outside- ways of approaching this and discuss how you'd like use cases to be worked out and what would look like good code once you have it. And once that discussion is going on, [a] proposal firms up with more precise syntax, more work on edge cases, and refinement. And I find that one of the problems with the current Committee is that people want finished proposals prepared, put forward with exact semantics, except syntax, and endless precise wording. And we end up talking about technical details rather than what I consider fundamental language design problems, which is basically "what's the problem and what's the fundamental way of dealing with it?" And we spent endless time discussing technical details before we've agreed if and what the problem is.
Jon:
So do you believe, in general, the proposals that are coming to the Committee are trying to hard to have a full solution and [there] might be better proposals if they worked more on just defining use cases, defining edge cases, and giving much less thought to what the wording should be, and that kind of thing?
Bjarne:
I... think so, yes. I think that the Committee should be more collaborative in developing solutions. I think that people come in with a proposal, and they defend it, as opposed to bring a proposal and see how it works out and then jointly work towards a solution. I think there are too much defensiveness, too many demands of perfection before the time.
