W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2016

Re: Dealing with levels in specs

From: Philippe Le Hégaret <plh@w3.org>
Date: Wed, 16 Nov 2016 07:48:07 -0500
To: Tobie Langel <tobie@codespeaks.com>, spec-prod@w3.org
Cc: Denis Ah-Kang <denis@w3.org>, jungkee.song@samsung.com
Message-ID: <3d21c5ea-2967-a1a7-8a5d-dd784701fdc0@w3.org>

On 11/16/2016 3:45 AM, Tobie Langel wrote:
> There's a growing trend in specs right now to start releasing different
> levels of a same spec. It seems it's mainly done to comply with Rec
> track requirements without slowing down editing too much.
> 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.

> So going back to spec levels, it seems there's no structure in place
> within W3C to handle these levels correctly. From my conversations with
> Denis, it seems W3C treats each level as a different independent entity
> and then does some ad-hoc redirecting on /TR/ depending on requests from
> editors or chairs.

That's correct.

> This leads to absurd situations such as that of the Service Workers
> spec. Currently, we'll find:
> An October 11 WD at https://www.w3.org/TR/service-workers-1/ which point
> to a "Service Workers 1" ED at https://w3c.github.io/ServiceWorker/v1/.
> A June 25, 2015 WD on https://www.w3.org/TR/service-workers/ which is
> obviously very much outdated and points to an ED at
> https://slightlyoff.github.io/ServiceWorker/spec/service_worker/ which
> itself redirects to a "Service Workers Nightly" ED at
> https://w3c.github.io/ServiceWorker/ (which according to the editors is
> the one which should be referenced).
> W3C's API (which Specref pulls data from hourly) makes no mention of the
> latter, and thus everyone is incorrectly directed to the former (with
> it's level-1 ED implementors should *not* be tracking).
> I've bumped into similar issues with CSP which I had to manually fix in
> Specref and others before that.

... you missed webperf. We're in a similar situation with this as well, 
mainly due to lack of tooling support.

> 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 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. 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. In its present state, it's not 
helpful (some would easily say, quite the contrary in fact). We don't 
have a solution for SEOs yet unfortunately but I'd like to fix that one 
sooner rather than later as well.

Received on Wednesday, 16 November 2016 12:48:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 12:48:15 UTC