- From: Mark Watson <watsonm@netflix.com>
- Date: Thu, 21 Apr 2011 09:40:04 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Ian Hickson <ian@hixie.ch>
- CC: Sam Ruby <rubys@intertwingly.net>, "public-html-a11y@w3.org Task Force" <public-html-a11y@w3.org>
On Apr 20, 2011, at 7:43 PM, Silvia Pfeiffer wrote: > I would personally think that we can resolve the 5 changes through the > bug tracker and that they are not substantial to be solved before LC. > They are "part of the plumbing" as John put it so nicely. But it is > indeed a good question whether turning the 5 changes into bugs would > be agreeable with other members of the group. I disagree that the "track kind" is "part of the plumbing". Whether you can, or cannot, discover the types of tracks available from a script makes the difference (for me at least) as to whether this multi-track support is useful or not. I would at least like to hear Ian's opinion on the "track kind" issue before agreeing that it can be dealt with as a bug, with the associated possibility that multi-track support goes into the LC draft without this feature. It's there for text tracks and I don't see any difference in rationale when considering audio and video tracks. ...Mark > > Cheers, > Silvia. > > > On Thu, Apr 21, 2011 at 12:28 PM, Sam Ruby <rubys@intertwingly.net> wrote: >> On 04/20/2011 09:00 PM, Silvia Pfeiffer wrote: >>> >>> We appreciate the extra time provided to us by the chairs to further >>> discuss the submitted four change proposals and come to an agreement. >>> There have indeed been lengthy discussions during the provided time >>> frame and we have made great progress. >> >> Something to consider: think about what you could do if you had until May >> 14th...[1] >> >>> The group has come to a consensus on which proposal to support. While >>> some of our feedback on that change proposal has already been taken on >>> board, there is still a list of 5 outstanding changes that need to be >>> addressed for the specification text to be complete. >> >> One way to proceed is to see if that number can be reduced between now and >> Friday, and then to have a survey on the remaining items (asking for >> objections to INCLUDING and objections to EXCLUDING each change). The >> results of the decision will affect what goes out in the Last Call. The >> standard for revisiting the decision would be New Information or a Formal >> Objection. >> >> Another way to proceed is to open bug reports on each and continue to work >> on them until May 14th. Changes over which there is WG consensus can be >> made during that time. Changes that reduce consensus can be reverted[2]. >> >> With the second approach, it still will be possible to raise issues and have >> these issues resolved in time for HTML5 (as in CR, PR, and Rec). What you >> gain if you go this way is a few more weeks to find WG wide consensus. What >> you lose is the opportunity to get these changes into the spec in time for >> Last Call over objections should the chairs find that there to be stronger >> objections to EXCLUDING these changes than there is to INCLUDING these >> changes. >> >> At this point, the issue has been raised and Change Proposals have been >> written so the only way we will decide to close this issue and proceed with >> bugs is if we have Amicable Consensus to do so. If anybody objects to such >> an approach, we will go with a survey. >> >> - Sam Ruby >> >> [1] http://lists.w3.org/Archives/Public/public-html/2011Mar/0759.html >> [2] http://lists.w3.org/Archives/Public/public-html/2010Sep/0125.html >> >> > >
Received on Thursday, 21 April 2011 16:40:33 UTC