> On Apr 8, 2015, at 12:19 PM, Domenic Denicola <[email protected]> wrote: > > This was discussed briefly at the previous meeting, perhaps un-minuted. > > The basic plan is to develop the spec on GitHub, using [Ecmarkup][] and > [Ecmarkdown][]. It will take pull requests, have a master branch that you can > view (and implementers should view, to see any bug fixes made since the Ecma > version), etc.
I think generating feature spec’s on github, using these technologies is a fine idea. > > Brian did a prototype conversion a while back, based on an older draft and an > older dialect of Ecmarkup (no Ecmarkdown); you can find that at > https://github.com/bterlson/ecmascript. I believe the current status it that > we're waiting for the "final" GA-submitted version before doing the real > conversion, since Allen is making editorial tweaks and bug-fixes up until the > deadine. Once that's done we'll use some mutated version of Jason's > [converter][] and start iterating and tweaking from there. However, I’m skeptical that they will be the technologies used to actually publish ES2016. I suspect, that for 2016 we will end up manually integrate the new material into the Word document. Here’s why. We are immediately, upon GA approval, starting the ISO fastback approval process. Based upon past experience this will take about a year and produce a significant number of edits to the ES2015. spec. We need to keep those changes in sync with ES2016 work such that the final ISO spec. will probably be the ES2016 spec and it will need to be a Word document. I support experiments working towards converting the entire spec. to alternative development approaches including proving that we can generate a paper publication quality version of the spec, and working with the ECMA and ISO/ JTC/1 on the publication pipeline. However, that is a lot of infrastructure work and I don’t think we should let it to get in the way of shipping our first yearly update. > > Unlike the current process, the post-ES2015 spec process requires two > shipping implementations before a feature is integrated into the spec. While > we're waiting for that, we anticipate proposal documents to prepare for > integration by being written as Ecmarkup/Ecmarkdown spec deltas, with their > own issue trackers. For an example of this, see [Object.observe][]. > > There's been less discussion about what to do with the issues list: GitHub > issues vs. bugs.ecmascript.org. At the very least I would hope that we > welcome community issues on GitHub, even if bugs.ecmascript.org stays active. There is already a bugs.ecmascript.org <http://bugs.ecmascript.org/> “product” for ES7 and it is open to community issues. We should certainly try moving towards GitHub issues for individual post ES7 feature proposals and it that works out well perhaps we can migrate the the ES7 bugs.ecmascript.org <http://bugs.ecmascript.org/> issues to github issues. Allen > > > [Ecmarkup]: https://bterlson.github.io/ecmarkup/ > [Ecmarkdown]: https://github.com/domenic/ecmarkdown > [converter]: https://github.com/jorendorff/es-spec-html/ > [Object.observe]: https://arv.github.io/ecmascript-object-observe/ > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
