comment overflow

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

comment overflow

Michael Dyck
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?

-Michael
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: comment overflow

Mathias Bynens-2
On 10 Feb 2014, at 10:30, Michael Dyck <[hidden email]> 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.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: comment overflow

Allen Wirfs-Brock
In reply to this post by Michael Dyck
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.

allen



On Feb 10, 2014, at 1:30 AM, Michael Dyck wrote:

> 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?
>
> -Michael
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: comment overflow

Michael Dyck
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.

-Michael
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: comment overflow

Allen Wirfs-Brock

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,
Allen
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: comment overflow

Michael Dyck
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.

-Michael
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss