- From: David (Standards) Singer <singer@apple.com>
- Date: Thu, 11 Sep 2014 17:12:55 -0700
- To: Sam Ruby <rubys@intertwingly.net>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, Philippe Le Hegaret <plh@w3.org>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-w3process@w3.org" <public-w3process@w3.org>
I really appreciate the sleuthing that you all did here. Thank you much!! On Sep 11, 2014, at 17:00 , Sam Ruby <rubys@intertwingly.net> wrote: > On 09/11/2014 06:04 PM, Michael Champion (MS OPEN TECH) wrote: >>> this sort of thing happens a lot. It's the nature of the process... >> >> Thanks for steering this thread in a more actionable direction. I >> think most people in the AB and the Process CG agree that W3C needs to >> get more agile. The "waterfall" model that seems to have guided the >> traditional W3C process assumed that the spec was correct and >> implementations should follow it. We're trying to move toward a more >> modern conception of tight feedback loops between requirements, specs, >> implementations, documentation, and broad community requirements. We're >> not there yet. >> >> The "living standard" model (at least earlier in the history of >> WHATWG, and as I understood it) posited that what the implementations in >> some sense defined real standard and the spec should evolve to describe >> that reality. I personally think that was a useful way to look at the >> situation in say the 2007-2012 timeframe. But going forward, such a >> perspective gives most of the decision making power to browser >> implementers when ideally other communities -- most notably, real >> website / web app developers, not to mention the accessibility, >> internationalization, security, etc. specialists -- need to have a seat >> at the table as well. >> >> It would be great to get specific bug reports on what in the process >> document, or the way it is implemented by WGs and the W3C staff, is >> broken but fixable. A post-mortem on the Web Performance experience >> might be a valuable source of such bug reports. But we should also be >> thinking about situations such as responsive images >> (http://arstechnica.com/information-technology/2014/09/how-a-new-html-element-will-make-the-web-faster/) >> where neither WHATWG nor W3C come out looking pristine. > > Back when I went to college, I took both macro and micro economics. There are many cases where it is helpful to look at the problem at multiple levels, and I suggest that this is one of those times. > > At a macro level, I completely endorse your statements above. I don't speak for either IBM or the ASF, but I suspect that they would largely agree too. > > At a micro level, my first reaction is to ask why a bug report wasn't opened on this issue, and why there wasn't any objection to the relevant CfC's. The answers can be found by looking at the transition requests (sorry for the members only links): > > https://lists.w3.org/Archives/Member/chairs/2012JulSep/0020.html > https://lists.w3.org/Archives/Member/chairs/2013OctDec/0056.html > https://lists.w3.org/Archives/Member/chairs/2013OctDec/0071.html > https://lists.w3.org/Archives/Member/chairs/2013OctDec/0098.html > https://lists.w3.org/Archives/Member/chairs/2013OctDec/0174.html > > None of these have a bugzilla link. In fact, one of the questions raised was how to open bugs: > > http://lists.w3.org/Archives/Public/public-web-perf/2013Aug/0109.html > > Drafts of the document suggests comments should be sent as emails to the list: > > http://www.w3.org/TR/2012/CR-performance-timeline-20120726/ > > As to the CfC, the following emails were what was cited as the decisions to advance: > > http://lists.w3.org/Archives/Public/public-web-perf/2012Jul/0030.html > http://lists.w3.org/Archives/Public/public-web-perf/2013Jul/0039.html > > Both were telecon minutes. > > In an absolute sense, the process was followed in that (a) comments were sent to the list, (b) that the members of the Working Group could have followed the minutes and (c) could have alerted their respective Advisory Council representatives to raise an objection at the appropriate time. > > But in a very real sense, tracking comments via mailing lists and determining consensus via teleconferences aren't ideal. The former tends to be error prone (as clearly is the case here), and the latter isn't as inclusive of people with different schedules and/or work mode preferences. > > So while I again endorse Mike's broad brush picture, ensuring that bugs are tracked via a bug tracker and calls for consensus are sent to the mailing lists are simple and effective changes that could be put into place immediately. > > - Sam Ruby > >> ________________________________________ >> From: Boris Zbarsky <bzbarsky@mit.edu> >> Sent: Thursday, September 11, 2014 7:17 AM >> To: Philippe Le Hegaret >> Cc: public-w3process@w3.org >> Subject: Re: publishing new WD of URL spec >> >> On 9/11/14, 10:06 AM, Philippe Le Hegaret wrote: >>> ie good idea but we'll push it for v2: >> >> For what it's worth, this is pretty much a perfect illustration of >> what's wrong with the W3C process and its versioning from my point of >> view... An implementor comes to the WG saying the spec is not >> web-compatible, during the time period that is supposed to be for >> implementor feedback, and the decision is to freeze the spec as-is and >> push off making it web-compatible to a nebulous v2. >> >> To be clear, I'm not trying to call out the webperf working group in >> particular here; this sort of thing happens a lot. It's the nature of >> the process... >> >>> I raised the issue to make sure it stays in our radar and get resolved >>> once and for all: >>> http://www.w3.org/2010/webperf/track/issues/18 >> >> Thank you! >> >> -Boris >> >> >> > David Singer Manager, Software Standards, Apple Inc.
Received on Friday, 12 September 2014 00:13:47 UTC