Surely there are examples of specification details that "got past the goalie" so to speak. Making those mistakes known, analyzing why they got through, and adjusting processes accordingly would be a useful exercise both in terms of accountability and community education. I've been googling around looking for any such "postmortem" explicitly tied to the comity, but I have been unsuccessful thus far.
For example, the language feature that originally motivated my question is default exports. I don't think it's important to adjudicate my opinions about default exports here, but I was surprised to see that no content has been published by the comity discussing whether the inclusion of default exports in es6 was ultimately a good decision. I think it would be useful for teams creating style guides and beneficial to the quality of the language over time if these topics were addressed officially.
Because that is a very subjective opinion that the committee wouldn’t be able to gain consensus on in either direction. There’s nonzero people on the committee that regret const, class, and many other features.
That's great- I want to hear more about those disagreements , though I'll grant most people probably don't care much about the most extreme cases. I don't expect consensus, but if even a plurality of the comity ever comes to regret a particular decision I think that's material information for everyone outside the comity
While you can certainly locate and/or solicit opinions from past or present committee members, It's extremely unlikely that you'll get any kind of "official" comment like this - we couldn't even agree to recommend semicolons.
Cool- this response makes sense and is realistically about what I was expecting to hear back . I encourage any kind of "posthoc dissenting opinion" writing that might come from comity members in the future, but I'll also stop bugging you about it here