Re: Issue-152 (multitrack-media-resources): Call for Consensus

On 04/22/2011 02:27 PM, Sam Ruby wrote:
> I'll respond in more length when I get back to my desk, but my purpose
> in enumerating the default way forward was to solicit objections.
> You say that we have two proposals in all but name and form; if you
> address both then we will call for consensus on that proposal and give a
> (brief) opportunity for counter proposals to be revised.
> If no Change Proposals are received today, the issue will be closed
> without prejudice

The only thing I really want to add at this time is that the 
requirements for a Change Proposal are here:

I specifically want to point out the requirement that we have "A set of 
edit instructions, specific enough that they can be applied without 
ambiguity."  We are NOT looking for a sketch.  We are NOT willing to 
accept proposals that contain the text "or something of equivalent
functionality".  We ARE looking for specific, workable technical text.

I'll remind everybody that The original call for proposals went out 
January 18th[1].  The call for Alternate or Counter Proposals went out 
February 22nd[2].  Our original plan[3] was to start a survey on April 
1st.  Based on requests[4], we have already granted a significant 

I would NOT encourage anybody to assume that we would be willing to 
grant an additional extension at this time.

- Sam Ruby


> /Connected by DROID on Verizon Wireless/
> -----Original message-----
>     *From: *John Foliot <>*
>     To: *'Sam Ruby' <>,*
>     Cc: *'HTML Accessibility Task Force' <>*
>     Sent: *Fri, Apr 22, 2011 18:03:19 GMT+00:00*
>     Subject: *RE: Issue-152 (multitrack-media-resources): Call for Consensus
>     Sam Ruby wrote:
>      >
>      > Related to both #1 and #2 above, Ian has expressed a desire to
>     withdraw
>      > his proposal if all other proposals are withdrawn[2].
>      >
>      > First: this proposal, as written, is no longer relevant. Silvia
>      > enumerated 5 additions that have yet to be incorporated and
>     nothing in
>      > that proposal from over a month ago is helpful in evaluating
>     objections
>      > to doing so.
>      >
>      > And second: as described above, Ian withdrawing his proposal does not
>      > mean that it does not have supporters. In fact, it appears that
>      > everything in that proposal (as it has subsequently evolved in SVN if
>      > not in the proposal itself) has consensus. The only thing over which
>      > there are known differences at this point are five proposed additions
>      > which have not yet been incorporated.
>     And herein lies the rub.
>     We have essentially 2 proposals that for the most part are almost
>     identical: Ian's proposal ("as evolved in SVN"), and the a11yTF
>     sub-groups
>     proposal, which is Ian's proposal ("as evolved in SVN") PLUS 5
>     additional
>     items. All 5 of these items were discussed heavily both via the W3C
>     mailing list, as well as during the numerous hours of conference
>     calls we
>     undertook over the past few weeks.
>     So while the chairs may not have 2 distinct & formal "Change
>     Proposals" in
>     front of them, there are in fact 2 proposals to contemplate: the
>     [MediaControler] proposal AND the [MediaControler + 5] proposal.
>      >
>      > At the present time, it is these five additions that we need to
>      > evaluate, not the original Change Proposals. Typically, when people
>      > propose specific additions, we give people time to evaluate those
>      > additions and to propose alternatives. It is not clear to me that
>      > adequate time has been allowed for this to occur.
>     Typically, when 2 or more Change Proposals emerge for an issue, the
>     Chairs
>     issue a Straw Poll for objections, allow a sufficient amount of time for
>     the Straw Poll to be processed, and then the Chairs evaluate the results
>     looking for weakest objections.
>     The absolute last thing I would want to see happen here is that the
>     Chairs
>     delay progress on this Issue at this point. We have had Issue 152 on the
>     table for a very long time, we sought and were granted an extension
>     on the
>     deadline for Change Proposals (with a fingers-crossed optimism that we
>     would reach consensus and not need to be more formal than that), and to
>     now suggest that someone might come forward requiring a long amount of
>     time to 'study' the 2 proposals we have today (which are more in
>     alignment
>     than out) suggests a certain amount of naivety - I would venture to
>     state
>     that anyone with an opinion on this topic has been actively involved in
>     the discussions already and so an "adequate" amount of time could be
>     measured in days, not weeks.
>      >
>      > Put another way, if these additions were made and were to be met with
>      > objections by members of the working group, the chairs would
>     likely ask
>      > that they be reverted until consensus has been found.
>      >From a purely procedural, consensus perspective, this is correct.
>     However they could also be added to the Draft Spec based upon the
>     results
>     of a "Straw Poll for Issue 152" that the Chairs could issue forthwith
>     (based upon 1 or more Change Proposals submitted by your deadline of
>     today), bugs could be filed against their inclusion, and barring
>     resolution of those bugs they could be escalated to Issues and the
>     entire
>     process that comes with those actions. All of that however would (per
>     your timeline and process) happen *after* Last Call (May 22).
>      >
>      > Based on all of the the above, it is my (personal, non-binding)
>      > recommendation that we simply allow Ian to withdraw his proposal; we
>      > ask
>      > Ian to update the W3C draft, preferably today, to include the API
>      > changes that he has been shepherding; and ask that bug reports be
>      > opened
>      > on these additions (Sylvia would you be willing to do this?).
>     What it amounts to is that the Spec text going into Last Call is
>     deficient
>     in the 5 aspects that the sub-team have reach consensus on in our
>     meetings
>     - the text is incomplete from our (certainly *my*) perspective.
>     During the
>     media sub-team's most recent teleconference, I specifically and
>     deliberately polled the attendees on these 5 items - one at a time, and
>     all 5 items received positive consensus support for inclusion with *NO*
>     dissenting opinion on any of the 5.
>     Ian (and others) who may be opposed to adding these 5 items to the Draft
>     Spec have been invited to participate in our discussions - I personally
>     sent an invitation to Ian to join us during the accelerated and
>     intensive
>     discussions we undertook over the past 3 weeks - he (and others who may
>     have a stake in the discussions) declined to participate. It is also
>     worth
>     noting that we had 2 relatively new members to the Task Force (Mark
>     Watson/Netflix and Bob Lund/Cable Labs) make time in their schedules to
>     participate in these calls.
>     Sam, as I explained to you on the allyTF call yesterday, we have 2
>     proposals which I classified as "4a and 4b" then, and what I have
>     classified in this note as [MediaControler] proposal and the
>     [MediaControler + 5] proposal.
>     *IF* Ian was willing to withdraw his proposal and adopt spec
>     language that
>     meets the consensus requirements of the media sub-team [MediaControler +
>     5] proposal, and the larger Working Group then proceeded to move forward
>     with bugs being filed against those 5 additions (to have them
>     modified or
>     removed), then I think we could find some common ground and avoid
>     some of
>     the more onerous procedural steps that the ChangeProposal/StrawPoll
>     process imposes.
>     *HOWEVER* if Ian is unwilling to withdraw his proposal and only move
>     forward with Spec text that he likes (ignoring the 5 additions the media
>     sub-group have requested), then you have 2 proposals on the table,
>     and we
>     need to go down the Straw Poll road.
>     It would be my personal preference that Ian agree to what the sub-team's
>     consensus process has brought forth, and that any objections to the
>     addition of these items to the Spec be dealt with as bugs after the
>     fact.
>     Put another way, I would rather see them *in* the spec at this time,
>     rather than *out* - which, when you evaluate the 2 positions under
>     discussion here is basically where we are at.
>      >
>      > That being said, we previously gave until today for people to produce
>      > Alternate or Counter Proposals, and we plan to keep to that. If we do
>      > not receive such today, we will treat all proposals as withdrawn and
>      > close issue 152 without prejudice as requested.
>     Sam, you have essentially 2 proposal before you now that are Change
>     Proposals in everything but name and structure: everyone involved in
>     this
>     Issue has been more invested in working through the technical
>     discussions
>     around this than focused in the process of formally writing up positions
>     as "Change Proposals". At this point in time, it seems that the ball
>     is in
>     Ian's and the Chairs' court - if Ian is willing to incorporate the
>     requested 5 items into the Spec Text as requested by the media sub-team
>     now, then the Chairs can proceed without a Straw Poll. If he is
>     unwilling
>     to do so, then the Straw Poll for Issue 152 route appears the way
>     forward.
>      > If we do receive a
>      > proposal, and don't hear otherwise, then we will presume that Ian's
>      > offer to withdraw his proposal as being rescinded, and we will
>     proceed
>      > to evaluate the two proposals. If those who prefer to not include
>      > these
>      > additions at this time wish to request a brief period of time (as
>     in a
>      > few days) to update their proposal, such a request will likely be
>      > granted.
>     Depending on the outcome of Ian's response, should you require a
>     formalized Change Proposal then I would request the weekend to prepare
>     that document (and/or seek assistance with its authoring). I will be
>     monitoring this discussion throughout the day, and will advise my
>     intentions at the end of the business day (~18:00 PDT).
>      >
>      > The operational affect of opening bugs and closing the issue without
>      > prejudice is that these additions can still make last call if
>     resolved
>      > without objection. And the issue itself can be reopened at any
>     time --
>      > albeit as a last call issue -- simply by providing a Change Proposal.
>     Yes, and this is the problem. It would be my desire that going into Last
>     Call the consensus-driven requests of the media sub-team be included in
>     the Specification Text.
>     On Friday, April 22, 2011 9:36 AM Mark Watson wrote:
>      >
>      > I don't mean to force anything and maybe I am mis-understanding
>     the HTML
>      > WG process (which is anything but simple), but I think we should
>     avoid
>     the
>      > situation where the multi-track solution goes out for LC with a
>     significant
>      > requirement not addressed (and btw, this requirement has been
>     there from
>      > the beginning and is properly addressed in Change Proposals 2 & 3)."
>     (
>     I don't think Mark is wrong here, he seems to me to have a clear
>     grasp of
>     W3C process(*), and I too echo his concerns. I would much prefer we go
>     into Last Call with "too much" rather than "not enough".
>     JF
>     (*) Purpose: A Working Group's Last Call announcement is a signal that:
>     - the Working Group believes that it has satisfied its relevant
>     technical
>     requirements (e.g., of the charter or requirements document) in the
>     Working Draft;
>     - the Working Group believes that it has satisfied significant
>     dependencies with other groups;
>     - other groups SHOULD review the document to confirm that these
>     dependencies have been satisfied.
>     In general, a Last Call announcement is also a signal that the Working
>     Group is planning to advance the technical report to later maturity
>     levels.

Received on Friday, 22 April 2011 19:55:36 UTC