- From: Jeff Jaffe <jeff@w3.org>
- Date: Mon, 13 Oct 2014 08:22:13 -0400
- To: Olle Olsson <olleo@sics.se>, public-w3process@w3.org
- Message-ID: <543BC3F5.9040806@w3.org>
On 10/13/2014 6:15 AM, Olle Olsson wrote: > Interesting discussion, but it could profit from clear policy > statements about where W3C is on the spectrum: > "living standard" < --- > "canonical stable standard" > > The WHATWG policy can perhaps be represented by their definition at: > https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F > where the evolution of specifications is said to be sort of > progressing in tandem with what browser vendors are implementing. > > The W3C policy is implicitly specified by how the process document > describes the life-cycle of standards. The objective of work on a > specification is to arrive at a final stable standard specification at > a specified date. Later there might be need to evolve a new improved > version of that thing, also aiming at a final stable specification. > > There is definitely some kind of rationale for how WHATWG chooses to > work, not the least because it was itself a browser vendor initiative > (created by a very small number of browser vendors). And we do see > some rapid evolution in the web technology space, at least if we look > at what is built upon the foundation of what the new HTML will provide. > > A challenge for W3C is that the defined process should not only cover > the "HTML family" of technologies (in a broad sense, rapidly > evolving), but also technologies that are evolving at a slower speed. > So what W3C approach to handling specification evolution can be > optimal for *all* kinds of web technology specifications? This is part of why I blogged recently both about OpenStand, and where agility can be improved [1]. [1] http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/ > > We have also encountered the "forking" problem. Is W3C forking WHATWG > specifications? Well, yes, if HTML5 is regarded as a fork of the > WHATWG HTML "living standard" specification. But similarly, when W3C > standards are elevated to ISO standards, we could also see that as a > fork, this time a fork handled by an organization (ISO) that is "slow" > compared to the originating originating organization (W3C). Is this > good, or it it bad? > > Are we trying to find fixes to the discrepancies between the WHATWG > way of working, and the W3C process? Is the objective to make the gap > between WHATWG and W3C smaller? Or is it to make value-adding > improvements to the W3C process, good for all specification > development work, even if this does not make any difference to the > current ideological debate between the two organizations? > > The flame wars seen on the mailing lists during the last month are > incomprehensible to the world at large (who are actually depending on > web technology constructed on the basis of widely supported > specifications). > > Let us hope that we leave the flame wars behind, and see more > constructive proposals for improved ways of working, but it would be > good if these are based on a clear W3C policy and "living standards vs > stable standards". > > /olle > > On 2014-10-09 21: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. >> >> 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. >> > > > -- > ------------------------------------------------------------------ > Olle Olssonolleo@sics.se Tel: +46 8 633 15 19 Fax: +46 8 751 72 30 > [Svenska W3C-kontoret:olleo@w3.org] > SICS [Swedish Institute of Computer Science] > Box 1263 > SE - 164 29 Kista > Sweden > ------------------------------------------------------------------ >
Received on Monday, 13 October 2014 12:22:21 UTC