comment overflow
On 10 Feb 2014, at 10:30, Michael Dyck <jmdyck at ibiblio.org> wrote:
On a more meta level, do the process plans for ES7 include any new mechanisms for: (a) submitting comments on spec drafts, or (b) reducing the number of errors in spec drafts to begin with?
If only the spec were maintained in a plain text-based format (like Markdown or even HTML) it would be easy to host its repository on, say, GitHub, which would enable commenting on inline diffs (= perfect for pointing out small typos etc.). That way, it would also be possible to link to specific lines in a specific revision of the spec. Those things would already avoid a lot of overhead currently present when filing bugs IMHO.
This brings us back to the good old let’s-stop-using-a-Word-document discussion.
I'd suggest grouping all minor editorial bugs by chapter. That's how I'll process them.
As noted in the release notes, Rev 22 is particularly rough WRT algorithm formatting because of some technical issues I was still working through. Don't bother reporting those sorts of issues for this revision. I already know about them.
Prioritize the reporting of actual semantic errors over minor editorial issues.
On 14-02-10 08:37 AM, Allen Wirfs-Brock wrote:
I'd suggest grouping all minor editorial bugs by chapter. That's how I'll process them.
So, just to be clear, a "chapter" is what the spec itself (usually) calls a "clause"? (I.e., the main body of the spec has 26 of them.) If so, that means I'll only have to create 20 bugs, yay.
As noted in the release notes, Rev 22 is particularly rough WRT algorithm formatting because of some technical issues I was still working through. Don't bother reporting those sorts of issues for this revision. I already know about them.
The release notes mention "(extra line spacing, wrong left margin)". It turns out that my pipeline is oblivious to such issues (as long as the left margin is consistent within a given algorithm).
What about metavariables losing their italicization: is that something I shouldn't bother reporting on? I submitted Bug 2428, in the hopes of covering them all, but if you need a complete list, I could incorporate that into my comments.
Prioritize the reporting of actual semantic errors over minor editorial issues.
I think my comments are all editorial (some minor, some not). It takes all my time just to find those.
On Feb 10, 2014, at 11:20 AM, Michael Dyck wrote:
On 14-02-10 08:37 AM, Allen Wirfs-Brock wrote:
I'd suggest grouping all minor editorial bugs by chapter. That's how I'll process them.
So, just to be clear, a "chapter" is what the spec itself (usually) calls a "clause"? (I.e., the main body of the spec has 26 of them.) If so, that means I'll only have to create 20 bugs, yay.
yes
As noted in the release notes, Rev 22 is particularly rough WRT algorithm formatting because of some technical issues I was still working through. Don't bother reporting those sorts of issues for this revision. I already know about them.
The release notes mention "(extra line spacing, wrong left margin)". It turns out that my pipeline is oblivious to such issues (as long as the left margin is consistent within a given algorithm).
What about metavariables losing their italicization: is that something I shouldn't bother reporting on? I submitted Bug 2428, in the hopes of covering them all, but if you need a complete list, I could incorporate that into my comments.
sure, add the complete list to bug 2428
the Alg1-Alg3 styles are being incrementally phased out in favor of consistent use of Alg4 to address other list related issue. It is easy for this sorts bugs to slip through the process so certainly let me know what you find but feel free to aggregate them. It's easier for both of us that way.
Prioritize the reporting of actual semantic errors over minor editorial issues.
I think my comments are all editorial (some minor, some not). It takes all my time just to find those.
Obvious, the more major ones are higher priority and may deserve distinct bugs.
Thanks for all the great reports,
On 14-02-10 11:53 AM, Allen Wirfs-Brock wrote:
sure, add the complete list to bug 2428
Done!
Thanks for all the great reports,
You're welcome. It's nice to hear they're appreciated.
I've more-or-less finished composing my comments on rev22, and I find that, even after eliminating comments that have already been made, I'm still left with about 280.
Now, there's no way I'm going to create 280 bugs at bugs.ecmascript.org. I'd go crazy with all the copying and pasting. Even if I group them by section, that's still about 175 bugs. I could use bigger groupings, but that maybe leads to unmanageable bugs.
I suppose I could write a script that sends a bunch of HTTP POST requests to create new bugs, but that sounds like something that could cause a lot of trouble.
So, what to do?
On a more meta level, do the process plans for ES7 include any new mechanisms for: (a) submitting comments on spec drafts, or (b) reducing the number of errors in spec drafts to begin with?