Re: Moving past last call for HTML5

Ian Hickson wrote:
> On Fri, 20 Feb 2009, Sam Ruby wrote:
>> You must have some history with Larry that I'm unaware of
> No history with Larry. History within the W3C with other people, though, 
> yes (such as the sXBL debacle I described).

Larry is not other W3C people.

I am not familiar with sXBL beyond what you have told me.  The only 
objective statements I recognize so far is that sXBL was a debacle and 
that you were intimately involved.  There are other hypothesis that fit 
both data points, ones that I care not to explore further.  This is a 
different workgroup with a different scope and different participants 
and different chairs.  My take is that I've worked with you at a low 
level across a period of years, met you, and observed this group.  I 
believe I can work with this group in general and with you in particular.

>> [...] and frankly the above is at odds with my previous understanding of 
>> how you operate (which I would have characterized as "fact based" rather 
>> than the more horse-trading approach I see described above).
> Unfortunately with purely subjective sections like the one under 
> discussion I'm not really sure it's possible to have a truly fact-based 
> approach. I'm very happy to be shown wrong on this of course.

I see a lot of subjective content in the spec.  Not just a little, but a 
lot.  And a process set up whereby one individual party "wins" every
controversial argument.

Now I see the very same individual argue that such an arrangement is not 
reasonable.  Specifically you said:

      I do _not_ think it would be reasonable for one party, for
      example Larry, to compromise on every issue, with another
      party "winning" every controversial argument.

I still need to digest this new input further.

>> I don't believe that the next release of HTML will be the last release 
>> of HTML.  This is true whether it be called 4.1 or 4.5 or 5.  I suspect 
>> it will be externally called 5 but with a feature set that you would be 
>> more comfortable calling 4.1.  I don't want to rathole on naming.
> Ok. The draft I'm interested in taking to last call is the one that has 
> the features that people are asking for and implementing, so that's what 
> I've been talking about. Does that change your advice on what I should do 
> by October or what your expected timetable is for dealing with the 
> currently known issues?

I'll respond to this question at the bottom of the email.

>> Given the rate of change, the inattention to heartbeat requirements, and 
>> the rather widespread perception that this group is not exactly open to 
>> input, I believe that this document has not gotten the attention it 
>> deserves.  Only after these items have been resolved will we start 
>> hearing about the real issues.
> Wow, if receiving thousands of pieces of separate feedback isn't what you 
> consider "hearing about the real issues", I can't imagine how much 
> feedback you're actually expecting!

Ye, you have thousands of pieces of feedback, much of it from a 
relatively small and homogeneous group of people, namely browser 
vendors.  There is absolutely nothing wrong with that; satisfying that 
core constituency first makes a product that an excellent candidate to 
be a First Published Working Draft of the W3C.

I'm also concerned about feedback that has "fallen through the cracks". 
  I've made a number of comments, one in particular multiple times, that 
has never been so much as acknowledged.  If it happens to me, it is 
likely happening to others.

Having one person own the issues list, and having the same person set up 
to win every controversial argument, is not consistent with the W3C 
notions of consensus.  It is an excellent way to bootstrap, but it won't 
take us across the finish line.

> Note that the expected result (and basically the point) of "last call" is 
> indeed to trigger a deeper review cycle. Does that help with your take on 
> the timetable? (That is, we only have to be done dealing with the issues 
> we know about to transition to Last Call; then we are expected to get more 
> feedback, and only once we've dealt with all of that new feedback -- the 
> "real issues" you speak of, I assume, are we expected to go to Candidate 
> Recommendation, the next stage in the process.)

Your take is different than how I read

First, my read of the Last Call itself:

* The announcement begins a review period that SHOULD last at least 
three weeks but MAY last longer
* Ordinarily, reviewers SHOULD NOT raise substantive technical issues 
about a technical report after the end of a Last Call review period
* Ideally, after a Last Call announcement, a Working Group receives only 
indications of support for the document

I read the above to mean that we should enter Last Call having done 
everything we know possible possible to ensure that Candidate 
Recommendation is only one month away, but be prepared for the 
possibility that it is three months.  I realize that we might not even 
make that, and I imagine that there are others that have done far worse, 
but still: that's three months, not three years.

As far as what we should do before Last Call:

* Working Groups SHOULD encourage early and wide review of the technical 
report, within and outside of W3C, especially from other Working Groups 
with dependencies on the technical report. Advisory Committee 
representatives SHOULD encourage review within their organizations as 
early as First Public Working Draft, i.e., before a Last Call announcement
* A Working Group SHOULD work with other groups prior to a Last Call 
announcement to reduce the risk of surprise at Last Call.
* Starting with the First Public Working Draft until the start of a Last 
Call review, a Working Group SHOULD formally address any substantive 
review comment about a technical report and SHOULD do so in a timely manner.

I read the above as significantly more than "hey it is out there, you 
know where to find me" and "I'll get back to you in the third quarter".

I have an opportunity to meet with the AC representatives next month in 
Boston, and I plan to avail myself of the opportunity.  I also have 
tentative plans to visit Microsoft in March.  And as discussed in this 
past week's call, I intend to be in the SF area at the time of the IETF 
meeting, and hope to meet with people there.

My plan is to ask everybody to provide their feedback to public-html. 
Before October.

>> I don't see any individual item beyond that which -- in isolation -- 
>> could not be addressed by October.
> That's good to hear. Is there somewhere to track progress on this? I don't 
> really know how to read the issue tracker page, and it would be helpful to 
> have metrics to see progress so that I can see whether we're on track or 
> not (similar to the graph of pending e-mails I have).

The issue list is still nowhere near as organized as I would like.

These are intended to be a list of issues where at least one person 
believes that they have presented a coherent proposal:

These are intended to be a list of issues where an issue has been raised 
but no proposal has been made, most without anybody assigned to work on 

> Cheers,

We are now at the bottom of the note.

How you proceed is up to you, but as you have asked for further advice, 
here is how I would proceed if I were in your position.  I would work to 
get the W3C issues list to near zero by the AC meeting, and by that I 
mean all of the open issues and a substantial down payment on the raised 

And unlike you, one of the first actions I would take is to address that 
obnoxious introduction.  It is right up front, it screams loudly "you 
suck and I don't want to hear from you or your kind" to many of the very 
same people I would like to see won over and contributing to this 
process.  I also read it as being highly defensive.  If you really feel 
that section is important, there is a way to achieve the results you 
want with panache and style and exuding confidence, and that would 
involve techniques such as damning with faint praise.  I sense that 
Larry would excel at such, if given the opportunity.

But if it were me, I think there is bigger fish to fry.  Back to how I 
would proceed.

April through July we would do a linear scan, week by week, section by 
section, through the document allowing people to identify portions of 
the text which are subjective, controversial, or unproven.  At which 
point the chairs would work with the group to determine consensus, and 
you would keep on top of the input as we go.  For my part (as co-chair), 
it would be my intent to leave a wide amount of room for editor's 
discretion, as much as the Work Group will permit.

Such a process would also suggest that a shift of focus from the issues 
list to bugzilla would be in order.

August and September we do a second scan, much more quickly this time.

This is extremely aggressive, and is in addition to all of the other 
issues you are working.  I discuss alternatives here:

- Sam Ruby

Received on Saturday, 21 February 2009 15:33:24 UTC