Re: Dealing with levels in specs

On Wed, Nov 16, 2016, at 13:48, Philippe Le Hégaret wrote: 
> On 11/16/2016 3:45 AM, Tobie Langel wrote:
> > I'd have plenty to say on the irony of editing different spec levels for
> > evergreen browsers. And I still don't understand why we're not taking
> > advantage of versioning to fast-track spec snapshots to secure IPR at
> > regular intervals instead (which would avoid sidetracking the whole
> > editing process). But I guess that's a conversation for another time.
> 
> That's the approach a few Groups like webperf and webappsec adopted a 
> while ago. We didn't spread the practice yet across all groups.

Well it seems specs in these groups still have levels, so I'm slightly
confused as to how that's supposed to work.

> > If W3C wants to go down the leveled-spec road instead of fixing its IPR
> > process, it needs to do so in a structured and organized way:
> >
> > - Automate where /tr/shortname/ points so there's consistency across
> > specs.
> > - Document this so all WGs are consistent.
> > - Tie all levels together and not consider them as disjoint specs.
> > - Make sure the model you implement works with Specref so it can be
> > properly integrated.
> > - Enforce one ED referenced per shortname (in pubrules).
> 
> Whatever model we adopt, we also need respec and bikeshed to adopt them 
> as well. They don't have builtin support for multiple latest versions.

I'm not sure how that would work precisely practice, but "polyfilling"
that in both specs using custom metadata fields seems trivial.

It's the process/policy aspect that seems more tedious to setup at
present.
 
> > I know Denis has started working on some of this. I'm essentially
> > writing this email to suggest this issues get discussed in the open and
> > the work to fix it gets prioritized.
> 
> Indeed, Denis is looking into it and tasked to provide a proposal to 
> spec-prod by early 2017 at the latest. It's at the top of his list.

OK that's great news.

> Goal is to get the final proposal adopted no later than the AC meeting in 
> April 2017 (we don't need AC approval for this, it's just a deadline in 
> my mind). Note that, as part of this, he is also looking at revamping 
> our approach to the /TR page itself.

I'm not sure I see the value in having both of these things tied
together.

/tr has been a train-wreck since forever. Fixing it is good, but
everyone's used to its current state at present. It's not really a
blocker.

On the other hand, the level-related mess is becoming more painful by
the day. It impacts spec publishing (incorrect URLs), implementors
working on outdated content, authors not reading the right specs, etc.

The faster this is fixed, the better.

--tobie

Received on Wednesday, 16 November 2016 13:42:07 UTC