Re: Normative references and stable documents

[adding Steve and Chaals]

On 10/9/2014 3:35 PM, Wayne Carr wrote:
>
> On 2014-10-09 12:02, Michael Champion (MS OPEN TECH) wrote:
>>
>> 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.
>>
>
> +1 We should figure out how to make this easy to do.

Yes, this is Issue-141 [1].  Let's hope that the task force takes this 
up quickly.  Thanks David S. for the thoughts.  Anyone have other ideas?

[1] http://www.w3.org/community/w3process/track/issues/141

>
>> 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.
>>
>
> +1 I think there's often agreement this is a good idea.  It would be a 
> good practice for WGs to adopt.  It could also be something WG 
> Charters require.  Both of the first 2 are things we should let slip.

I had thought we had an open issue to address this, but I cannot find 
it.  Does anyone recall where that went?

>
>> 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?
>>
>
> Moving to incubating specs in CGs before a WG can result in developing 
> initial specs without broad consensus, and maybe with no consensus at 
> all - just what a Chair decides.  You can wind up with key decisions 
> made where all participants are not treated equally and by the time it 
> gets to a WG it could be in implementation and difficult to shift 
> course.  An alternative to that is to have some basic rules in CGs 
> through use of a Charter. There is a Charter template with rules like 
> that at: http://www.w3.org/community/about/ on the right Charter 
> Templates which leads to 
> http://www.w3.org/community/council/wiki/Templates/CG_Charter .  There 
> are 2 CG/BGs in the process of very quickly moving to WGs with specs 
> where earlier versions of that Charter template were used.  (Second 
> Screen Presentation CG <http://www.w3.org/community/webscreens/> and 
> Automotive and Web Platform BG 
> <http://www.w3.org/community/autowebplatform/> ).  Requiring basic 
> fairness in those groups didn't slow them down at all.  They can make 
> decisions in a very lightweight way, but there are process rules in 
> place to deal with problems if they arise.

I think that Wayne is correct in his analysis.  Perhaps instead of a 
formal change in the process we need a Best Practices document which 
would advice how CGs could work in a way that facilitates moving to the 
REC track.

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