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

On Apr 22, 2011, at 12:05 PM, David Singer wrote:

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.

I don't agree that the first of the additions requested by the a11y task force is minor. In my view discoverability of in-band tracks is a major requirement and discovering the tracks is no use if you don't know what they are for.

(D) is perfectly acceptable to me if it can be confirmed that there are no objections in principle to the proposals of the a11y task force. But last I heard there was an in principle objection to W3C defining track kinds as proposed.

If necessary a formal CP for [MediaController + 5] could be created fairly quickly. But I hope that is not necessary and we can just agree that the 5 changes are in principle good ones and it's only details remaining to be worked out.

...Mark


Sent from my iPad

On Apr 22, 2011, at 11:01, John Foliot <jfoliot@stanford.edu<mailto: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<mailto: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