- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 21 Feb 2009 10:32:35 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: www-archive@w3.org
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 http://www.w3.org/2005/10/Process-20051014/tr.html#last-call 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: http://www.w3.org/html/wg/tracker/issues/open 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 them: http://www.w3.org/html/wg/tracker/issues/raised > 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 ones. 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: http://groups.google.com/group/mozilla.dev.platform/msg/a298577d55dbcfe4 - Sam Ruby
Received on Saturday, 21 February 2009 15:33:24 UTC