Re: Dealing with levels in specs

On Wed, Nov 16, 2016, at 19:14, Liam R. E. Quin wrote:
> On Wed, 2016-11-16 at 09:45 +0100, 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.
> 
> Note that in addition to levels there are also editions - e.g. CSS 2.1
> 2nd edition to correct errata.

Like most things, there's a tradeoff. Or we keep the system simple
enough that is economically sound to build tools to make our lives
easier or we don;t and we're back to manual work.
 
> In theory there could be a 2nd edition of (say) CSS level 2 text.

Well, if you consider all of these things a mere tags or branches,
then's that's fine I suppose.

> > So going back to spec levels, it seems there's no structure in place
> > within W3C to handle these levels correctly.
> 
> Nor is there consistent use of teminology across Working Groups.

There's no centralized place where that terminology is defined, so no
wonder.
 
> Nor do we have a requirement that Working Groups provide a mechanism to
> identify to which levels and editions of which specs they are trying to
> conform, making validation and archiving difficult.

Specref provides that when it can. So it's available to spec editors
using Bikeshed or Respec.

> > If W3C wants to go down the leveled-spec road instead of fixing its
> > IPR process
> 
> When the method of working is at odds with the IPR legal framework we
> have to ask which is broken and how. The way that specs are being
> edited, as you rightly point out, has descended into chaos. Part of
> that was because new tooling such as respec and github came along that
> were so much easier than using CVS and edln :), that people editing
> specs rebelled individually.
> 
> Probably we need to rein that in a bit.

People end up using the tools that makes their job easier. When one
wants to reign things in, it's easy, do it as part of improving people's
workflow.

For example, simplify the steps to obtain a shortname for new specs that
abide by whatever model is agreed upon (i.e. don't need director
approval for it).

> > - Automate where /tr/shortname/ points so there's consistency across
> > specs.
> Note, this would need to be done for all the existing specs too, I
> presume.

Yes.

> > - 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.
> OK...

The model I have in mind is that the shortname is roughly equivalent to
a Git repository. The levels, Rec track statuses, etc. are just
branches. The ED is the tip of the master branch. There might be some
things to figure out more precisely, but roughly, that's the idea.

> > - Enforce one ED referenced per shortname (in pubrules).
> so no branches?

Branches are fine, drafts per level are fine. What's required however is
a way to identify the tip of the master branch (and call it the ED).

--tobie

Received on Thursday, 17 November 2016 14:09:15 UTC