RE: DOM LS review

Thanks Léonie. That's a really helpful description.

Hmm... If the horizontal review happens *after* the snapshot, it will, by design, produce a conflict any time an issue is uncovered. Wouldn't it make more sense to do the horizontal review before the snapshot is taken and resolve (or defer) any issues at that point? Or at least plan to do a "CR candidate" snapshot for review and then a "REC" snapshot after issues have been addressed? From experience with Encoding, making the snapshot isn't that difficult, so it is mostly a timing problem. Admittedly the temptation is to make a branch so that we can cherry pick fixes...

One way or another I'm sure we'll resolve the I18N issues noted in this cycle: I'm more concerned about the long term viability of the process.

Addison

> -----Original Message-----
> From: Léonie Watson [mailto:lwatson@tetralogical.com]
> Sent: Tuesday, December 10, 2019 2:19 PM
> To: Phillips, Addison <addison@lab126.com>; tink@tink.uk
> Cc: Philippe Le Hégaret <plh@w3.org>; r12a <ishida@w3.org>; Fuqiao Xue
> <xfq@w3.org>; Bert Bos <bert@w3.org>; 'member-i18n-core@w3.org'
> <member-i18n-core@w3.org>; public-html@w3.org
> Subject: RE: DOM LS review
> 
> Thanks Addison.
> 
> We're only part way through our first attempt at this, but I think it goes a little
> something like this...
> 
> The WHATWG creates a snapshot (review draft) of the DOM and HTML
> standards every six months, on a slightly staggered timetable (DOM in June
> and December, HTML in July and January).
> 
> The plan is for the HTML WG to take those review drafts, put them through
> wide and horizontal review, and ultimately to Rec.
> 
> We've put the June 2019 DOM review draft [1] through wide and horizontal
> review, and we have consent from the WG to request its transition to CR.
> 
> 
> We've also sent the July 2019 HTML review draft [2] out for wide and
> horizontal review, but haven't yet triaged the responses.
> 
> This raises an interesting question though - what happens if we turn up an
> issue with one of the review drafts? The review drafts can't be
> retrospectively changed, so our best bet is to do all we can to get the issue
> resolved before the next review draft is created.
> 
> Which brings us back to the DOM and HTML review drafts and the i18n issues.
> 
> For DOM our options are:
> 1. Proceed with the request to transition the June 2019 review draft to CR, on
> the understanding that it will go to Rec with the i18n issue unresolved.
> 2. Halt the current process and start over with the next review draft, on the
> basis that the i18n issue should have been resolved.
> 
> The catch in this case is timing - the next DOM review draft will be created
> around the 20th December, and the one after that not until June 2020.
> 
> For HTML the options are essentially the same, but without having done any
> triage on the wide and horizontal reviews done on the July 2019 HTML review
> draft, I can't say what the likelihood of that review draft making it to CR might
> be.
> 
> There might even be an argument for not taking the July 2019 review draft to
> Rec, and aiming for the January 2020 one instead.
> 
> Hope this helps, but let me know if not - or if a conversation would be easier
> than an email thread.
> 
> Léonie.
>  [1] https://dom.spec.whatwg.org/review-drafts/2019-06/

> [2] https://html.spec.whatwg.org/review-drafts/2019-07/

> 
> 
> > -----Original Message-----
> > From: Phillips, Addison <addison@lab126.com>
> > Sent: 10 December 2019 17:35
> > To: tink@tink.uk
> > Cc: Philippe Le Hégaret <plh@w3.org>; r12a <ishida@w3.org>; Fuqiao Xue
> > <xfq@w3.org>; Bert Bos <bert@w3.org>; 'member-i18n-core@w3.org'
> > <member-i18n-core@w3.org>; public-html@w3.org
> > Subject: RE: DOM LS review
> >
> > Hello Léonie, (+HTML)
> >
> > Sorry for the late reply.
> >
> > Richard and I are confused about how to determine the status of W3C's
> > snapshot. The github repo seems to redirect to WHATWG. Richard and I
> > have been trying to figure out the schedule and where to look for
> > stuff just now. I, at least, am easily baffled ;-). Could you let us
> > know the schedule and, optionally, where to look for details/status? I
> > realize that this is a New Thing and processes are in flux. I guess that more
> work is needed to regularize this.
> >
> > Regarding the specific issue for DOM and HTML, I am working on a pull
> > request to HTML this morning. If it is possible for the W3C snapshot
> > to wait on our change to HTML, that would be ideal. If not, it's not
> > fatal--there will be other snapshots in the future. I do think that
> > this is actually an important fix, since we're finding that lots of
> > specs depend on HTML's definition of string equality.
> >
> > I also don't know the fate of our comment on DOM
> > (https://github.com/whatwg/dom/issues/793), which is what started all
> > this ruckus. Technically nothing is wrong with DOM, even if we would
> > prefer that DOM change to use better jargon that "case sensitive". I
> > think DOM doesn't need to wait and is not blocked on the HTML change.
> > Could you let us know what the process is here and what dates we need to
> hit?
> >
> > Thanks,
> >
> > Addison
> >
> > Addison Phillips
> > Sr. Principal SDE – I18N (Amazon)
> > Chair (W3C I18N WG)
> >
> > Internationalization is not a feature.
> > It is an architecture.
> >
> >
> >
> > > -----Original Message-----
> > > From: Léonie Watson [mailto:tink@tink.uk]
> > > Sent: Monday, December 9, 2019 1:14 AM
> > > To: Philippe Le Hégaret <plh@w3.org>; r12a <ishida@w3.org>; Fuqiao
> > > Xue <xfq@w3.org>; Bert Bos <bert@w3.org>; Phillips, Addison
> > > <addison@lab126.com>
> > > Subject: Re: DOM LS review
> > >
> > > Richard or Addison,
> > >
> > > Would one of you be able to reply to the thread on the HTML email list?
> > > If we need to call a halt to things it'd help us to know sooner
> > > rather than later
> > > - sorry, I know you're both flat out.
> > >
> > > Léonie.
> > >
> > >
> > > On 30/11/2019 20:59, Philippe Le Hégaret wrote:
> > > >
> > > >
> > > > On 11/30/2019 2:07 PM, Léonie Watson wrote:
> > > >> I've just replied to the thread with the WG to ask if the issue
> > > >> is a blocker. Partly because it's something the WG needs to know,
> > > >> and partly because I'm still not sure of the answer after reading
> > > >> through this thread. Either way, Richard and Addison, sorry I missed it.
> > > >>
> > > >> Looking at the process as a whole, having almost been through it
> > > >> once at this point, there are certainly some things we need to
> > > >> figure
> > out...
> > > >>
> > > >> The near total lack of a common process or platform for
> > > >> requesting review is exacerbated by the additional layer of
> > > >> abstraction we have in this particular case. For DOM and HTML
> > > >> I've sent emails that became Github issues, opened Github issues
> > > >> directly, sent emails to WG email lists (that sometimes went
> > > >> unanswered), and sent emails to individual team members.
> > > >>
> > > >> I think the I18n Github labelling process is the best of all the
> > > >> different processes currently in use, but it too bumps up against
> > > >> a logistical problem - that the review groups cannot add labels
> > > >> to issues filed in the WHATWG repos. The domino effect is that we
> > > >> (the HTML WG) has to ask the review groups to comment on the
> > > >> relevant review tracker issue in our repo, and that places an
> > > >> additional admin burden on review groups that already handling
> > > >> heaps of reviews at any given time.
> > > >>
> > > >> I know the team has been working towards making the I18n
> > > >> labelling system common to all review groups, but if we plan to
> > > >> keep going with this review draft to Rec thing, we're going to
> > > >> need to get that in place sooner rather than later.
> > > >
> > > > +1. Dom and I are working on it as far as we can. We keep bumping
> > > > +into
> > > > other priorities however so we can't dedicate full time to the
> > > > project by far. I have a sync-up meeting with Dom on Monday and
> > > > we'll review our status and how far we are.
> > > >
> > > >> We also have to think about what happens when there is a blocking
> > > >> issue. My assumption is that we'll simply decide not to publish
> > > >> from the given review draft, on the basis that a) the review
> > > >> draft cannot be updated after the fact, b) the process of
> > > >> negotiating a divergent specification would be horrible, and c)
> > > >> the fallout from doing that would have unhappy consequences.
> > > >
> > > > I think the best answer now is "it will depend on the issue". In
> > > > my thinking, if an horizontal group labels an issue with
> > > > "needs-resolution", this means that we need to dive into the
> > > > issue, weight the pros/cons, etc. For example, we recently allowed
> > > > High Resolution Time to Recommendation, despite the fact that the
> > > > Privacy folks were unhappy. We decided to keep the issue open, but
> > > > recognized it couldn't be addressed yet. Some really hard issues
> > > > take years and we just have to recognize it, without dropping them
> > entirely.
> > > >
> > > >> Whether or not the review drafts start to act as milestones to
> > > >> the extent that the WHATWG start to regard them as "must fix by"
> > > >> deadlines is something only time will tell. Our plan at the
> > > >> moment is to take every other review draft to Rec, but perhaps
> > > >> we'll need to think about taking both review drafts of both specs to
> Rec each year.
> > > >
> > > > Philippe
> > >
> > > --
> > > @LeonieWatson Carpe diem.

Received on Wednesday, 11 December 2019 16:31:58 UTC