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?).

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 18:01:55 UTC