Re: Process lessons from Web Performance? Re: publishing new WD of URL spec

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

Received on Friday, 12 September 2014 00:01:28 UTC