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

Sam,
Thank you for your informative comment pointing out the macro and micro implications of this thread. Comment inline below.

> -----Original Message-----
> From: Sam Ruby [mailto:rubys@intertwingly.net]
> Sent: Thursday, September 11, 2014 5:01 PM
> To: Michael Champion (MS OPEN TECH); Boris Zbarsky; Philippe Le Hegaret
> Cc: public-w3process@w3.org
> Subject: 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.
[SZ] First are you suggesting that the Process should require the use of an issue/bug tracking mechanism or that this should be a best practice?  

Second, are you suggesting that the Process should require the use of Calls for Consensus to determine WG positions or that this should be a best practice? 
> 
> - 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 09:16:18 UTC