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

John, friends

I fear we may have few choices on how to proceed.  I am sure I will get corrected, but I see
A) adopt an existing CP and fix from there (many bugs would need filing)
B) do nothing, take what's in the spec now, which does not address 152 at all
C) write an entirely new CP in the few hours remaining today
D) adopt Ian's new text by amicable consensus and file bugs on the remaining issues

Note that E, write a CP against Ian's (or others') changes, is not possible.  CPs have to be against the spec., as I understand.

I think D is proposed. A and B are unacceptable, I think, and C infeasible. The bugs against D are, at the moment, few and minor (5 so far), and D represents a major advance from the status quo. We would also like LC comments against it.

Sent from my iPad

On Apr 22, 2011, at 11:01, John Foliot <jfoliot@stanford.edu> wrote:

> 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?).
> 
> I AM STRONGLY OPPOSED TO THIS PATH FORWARD. 
> 
> 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 <watsonm@netflix.com> 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)."
> (http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0251.html) 
> 
> 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.
> http://www.w3.org/2005/10/Process-20051014/tr#last-call 
> 
>

Received on Friday, 22 April 2011 19:07:07 UTC