Re: Dealing with levels in specs

Thanks for writing this up.

The main issue I have so far is the terms you use aren't defined clearly
enough.

What does: "latest stable version" mean? WD? REC?
What does "latest version under development" mean? WD? ED?

More importantly, how do you handle common cases where you have:

level-1 is REC 
level-2 is CR
level-3 is WD

What's stable above?

What about:

level-1 is CR
level-2 is ED

There is no level-2 WD so far, but ED is being used and referenced by
everyone. What's stable, what's under development?

Have you considered looking at this in different terms instead: eg
what's ready for IPR commitment and what isn't?

--tobie

On Fri, Dec 16, 2016, at 13:06, Denis Ah-Kang wrote:
> Hi all,
> 
> Thanks Tobie for starting the thread of that topic. Levels on /TR have
> indeed started to cause of a lot of problems because so far, we
> don't have a good way to manage the different versions of a
> specification.
> After discussing with different people, we came up with a document
> listing 3 proposals aiming at normalizing the latest version links. It
> is available at:
> https://w3c.github.io/tr-links/versioning/
> 
> The idea is to introduce new links to help the different
> audiences (browser implementors, web developers, etc) find the
> version of the specification they are looking for.
> 
> Please take a look at the document and I encourage you to create
> issues on the Github repository [1] if you have any questions/comments.
> FYI, I created an issue for each proposal [2][3][4]. Feel free to
> comment on it and/or +1 on your preferred proposal.
> 
> Thank you,
> 
> Denis
> 
> [1] https://github.com/w3c/tr-links
> [2] https://github.com/w3c/tr-links/issues/1
> [3] https://github.com/w3c/tr-links/issues/2
> [4] https://github.com/w3c/tr-links/issues/3
> 
> On 11/16/2016 12:45 PM, Tobie Langel wrote:
> > Hi all,
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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). 
> > 
> > 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.
> > 
> > Thanks for your time,
> > 
> > --tobie 
> > 
>

Received on Friday, 16 December 2016 16:48:10 UTC