RE: Normative references and stable documents

It would be great to start harvesting from this set of threads some concrete suggestions for changing the formal W3C process and informal practices to address some of acknowledged problems.  Just to start things off:


1.       Errata - Chairs and the team should more strongly encourage WGs to identify outright errors and fix them quickly, ideally inline in the published document but at least in an errata document.  Jeff’s blog<http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/> acknowledges that W3C can learn from WHATWG on this, and we need to make it happen.

2.       Published drafts of W3C specs should have sections annotated with information about how stable, widely accepted,  widely implemented, and proven in practice the feature as defined in the spec is.  It might be a good idea to flesh that list/taxonomy out and make some concrete suggestions for the process or practice.

3.       We could revisit the very thorny question of how to ensure that owners of specs and products that depend on a W3C spec actually review changes early in the process before changes are set in stone.  Hixie’s proposal that specs and dependencies be changed in lockstep is interesting but could not possibly scale up to include all stakeholders at Web scale. And as Daniel Glazman has pointed out, this simply doesn’t work for many enterprises who want to control the rhythm of  their own infrastructure and app updates themselves. But I’m sure we can do better than we do now.

4.       Jeff’s blog mentioned that Community Groups – which do not require broad consensus to proceed, but do not produce “standards” – are a way to develop specs more quickly. Indeed, the whole point of the blog was to muse on the right balance between strong editors (that some CGs have) driving “lazy consensus”<http://openoffice.apache.org/docs/governance/lazyConsensus.html> (to adopt the Apache term) and traditional W3C “broad consensus.” Should we discuss how CGs and WGs fit together in the W3C culture and process, continue to let them evolve independently from the process doc and team’s oversight, more strongly encourage specs to be incubated in CGs before a WG is chartered to standardize them, or what?

I don’t think this is an exhaustive list, just a few that seem to come up over and over in the WHATWG / W3C meta-thread.
From: Chris Wilson [mailto:cwilso@google.com]
Sent: Thursday, October 9, 2014 10:55 AM
To: Ian Hickson
Cc: David (Standards) Singer; Tim Berners-Lee; public-w3process
Subject: Re: Normative references and stable documents

On Mon, Oct 6, 2014 at 7:10 PM, Ian Hickson <ian@hixie.ch<mailto:ian@hixie.ch>> wrote:
On Mon, 6 Oct 2014, Chris Wilson wrote:
> That's an unrealistic expectation of the entire content of the world
> pivoting around the current spec, rather than the state of the spec when
> the content was developed.

If it's not realistic to expect all the people referencing the spec to
update, then *don't change the spec*.

Also not realistic.  People have been writing production code on WebRTC for some time now, despite it being "unstable" in practical terms.  Paving a long-existing cowpath is one thing.  Building a superhighway on a pathway you just blazed is another.  This all comes down to "there are different levels of baked, and more baked must equal more stable and a bigger event to change."

If it's not realistic to expect one to update one's spec when specs one
references change, then one should not be writing specs. Writing specs is
like writing software. The point at which you stop maintaining it is the
point at which it dies.

As a spec editor myself, I'm not worried about editing the spec.  Deploying browsers, and far more importantly deploying web properties that rely on those browsers' behaviors at certain points in time, are far harder.

> reaching stability in a spec, or even large portions of a spec, creates
> important inflection points in implementation.

It's certainly true that a spec can have layers where one set of features
are "v1" and another are "v2" -- the HTML spec does this a lot, for
instance, I even use that terminology internally to track when to add new
features -- but that has nothing to do with publishing snapshots, and it
isn't what the W3C is doing anyway.

I disagree that this isn't what the W3C has done in the past.

"HTML5" mixes long-stable stuff with
highly immature unimplemented stuff (and has lots of stuff that's been
fixed for months on the WHATWG side, making it even less "stable" than the
WHATWG living standard equivalent), for example.

Yes, there are a lot of things mixed in to HTML5, some long-stable and some immature.  I don't think the living standard approach makes that better, I think it makes it worse.

> This isn't just a reflection of spec commits; it's spec commits and
> stability of what's in the document, and without strong stability
> indicators, it's pointless.

Yeah. The WHATWG HTML spec had explicit markers per-section for a while
indicating how stable each part was. Now that pretty much everything in
the spec is stable, I've taken those out in favour of localised warnings
where things are known to be in flux. But again, this has nothing to do
with snapshots for patent purposes or the way the W3C is doing them.

I'm confused, didn't you just say HTML5 is a mix of long-stable and highly immature things?

One could imagine having multiple "views" of the spec, with newer features
omitted from some. In practice this isn't viable because when you add new
features you often have to make pretty invasive changes to the core model,
and so maintaining multiple branches becomes hellish. (I experienced this
when I was editing both the WHATWG and W3C versions of the specs.)

Yes, which is why I think stable versioning, with side specs for separable longer-term efforts and integration when the features are stabilizing and getting deployed across browsers, is the right way to go.  Similar, say, to Chrome's release staging.  :)

> Sooner or later, we'll reach a stable "v1" inflection point around Web
> Audio, and I'd expect implementers to use that as a bar - but additional
> features will be added, and changes will be made, and of course I'd want
> implementers (and developers, for that matter) in the future looking at
> that most of the time.

Why "most"? When would you ever want them implementing or using the old,
now known-to-be-wrong, stuff?

When the new feature set is not stable, or if that new feature set is not implemented across browsers, or when changes to old behavior is not implemented and deployed across browsers.