I would love to see rationales captured in this manner but my experience is that efforts to consistently capture such information tend to fall by the wayside as a project progresses towards completion. It becomes a simple question of prioritization. Do you spend time documenting the rationale for decisions or do you push on towards completion to meet the target deadline. The ES3.1 Object methods document really is most comparable to what we now try to capture on the Wiki. However, both then and now, once a feature moves into the the actual specification there is less motivation (and time) to also keep the Wiki proposals up to date. I've occasionally thought about trying to writeup more approachable feature summaries of what has actually been incorporated into the draft spec. but the same time management issue arise. Is it better to write explain what is going into the draft or move on to the next set of spec. work?
I suspect what is really needed to make this work is the dedication of someone who wants to see this happen but who isn't actually on the critical path for completion of the actual spec.. For example, it would be wonderful if somebody decided right now that they wanted to author an annotated version of the ES6 spec. that included design rationales. Then they would have a strong motivation to focus capture rationale information as work on the actual spec. progressed. This would be a great opportunity for anyone who wanted to be the Brian Kernighan of ES6. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
