Discuss escalation of bugs to tracker issues

Clarke: deadline Jan 14TH need to be escalated in order not to be dropped... any clarification on that?

<glenn> i don't believe it means they will be dropped if not escalated; rather, they (bugs) are subject to resolution by the editor

<Clarke> JanL: add discussion on adaptive streaming emails

Kaz: announcement from paul cotton yesterday - talk with Mike Smith - how to deal with comments

Mike will explained details on this call

Mike5: Paste in a URL

<Mike5> http://dev.w3.org/html5/decision-policy/decision-policy-v2.html

<Mike5> http://dev.w3.org/html5/decision-policy/decision-policy-v2.html#basic

Mike5: current decision policy in the working group
... two points - the flowchart - step raise bug, editors response, this is how it was envisioned
... after response - review response and then decide if you are satisfied or not - if satisfied, close the bug - if not, then "escalate"
... right to take that issue to next level of appeal - in this case, you have different people who are responsible for resolution at diff points in the process

bugs in Bugzilla, editor of the spec is responsible, --- if you disagree - chairs are the "court of appeals"

Mike5: meant to kickin when you have reached a point of disagreement that is otherwise unresolvable

thanyou

Mike5: as part of the timeline that the chair announced, they said if editor had not resolved by 31st, you have an option of escalating them automatically regardless of whether you had received a resolution
... it is an option, not a requirement. and another thing - no bug is ever dropped - will be resolved regardless
... remains in the same state that it is in now - waiting for further review by editor - or waiting for the editor to ask questions of bug commenter
... in my assessment, none have reached an point of impass with hixie
... Hixie - can be three weeks before he can get around to commenting - in some things we have offloaded - but he is working on a lot of stuff
... do not think it is the case that he has ignored bugs - proceeding naturally or normally -
... risk of escalating bugs - if you take a bug and ask it into a working group issue, you are asking Hixie to stop working on those bugs
... suggest that is not the best thing to happen at this particular point in time
... another thing to keep in mind, what we are trying to do is not necessarily get stuff into the spec, it is to get stuff implemented in browsers -
... get browser mfg working on the use cases and some indication that they are not completely opposed to implementing a particular proposed feature
... escalating means additional 2 months process - to getting resolved
... numerous steps 2-3-4 weeks with time to review - and at a minimum that is 2 months of work from escalating to when you have a chance of getting a decision from the working group

<glenn> escalating (making a bug a wg issue) is best done only after editor has resolved the bug in a manner not acceptable by the submitter; note that a closed bug may be reopened, so one may go through multiple rounds with the editor before choosing to escalate to issue;

clarke: sonds like you are suggesting not escalating - but consequences - this has been characterized as a deadline

Mike5: not suggesting what you do... you do still have - if you decide to - to escalate - if you think that will help resolve sooner rather than later

BobLund: question - any bug there is still discussion with editor - bug is still considered open - it will stay and be worked on

Mike5: absolutely
... using bugzilla as last call counter
... no comment every submitted in bug tracker ever gets dropped on the floor

<glenn> Mike5: all registered bugs (in bugzilla) will eventually be resolved

Mike5: value proposition for escalation, working group - must fix during next last call round - cannot go to CR without these bugs being resolved

Mark Vickers: good advise, personally pleased with feedback and handling, don't want to short circuit

January 14th date - make sure we do the things we are supposed to do

Clarke: objective of this group is to get the bugs addressed, and not escalating will perhaps get this done more efficiently
... we should look at each bug, but for those awaiting response from editor, we should let them follow their natural process and not escalate
... hearing nothing, that is the recomendation - suggest you each look at the bugs and see if that is the case

<Zakim> Mike, you wanted to say thanks for having me on and gotta drop off for another call and please contact me by e-mail if you have other specific questions

<Mike5> mike@w3.org

Mike5: contact me by email if you have additional questions

Clarke: next agenda - updated charter statement

Any comments or wait until next week when we have a statement to discuss

Adaptive streaming

<JanL> http://www.w3.org/2011/webtv/wiki/MPTF/ADR_Minimal_Control_Model_Proposal

JanL: post link on draft we are working on - touch on - see if there is a conclusion
... first to touch on, feedback from Jason (Disney), question usability from a - not talking - SD HD, not using the minimum bandwidth to control the profile

Jason: maximum more important than minimum, quality tied to minimum

JanL: go into the quality aspect, the use cases, CT1 sets a specific target

CT1

CT2, we are not talking about bandwidth, we are talking about reprsentation

JanL: higher lower quality should be addressing CT2

Clarke: i think - you point Jan - in case of max bandwidth, obvious the appropriate response is to send less data
... in case of minimum, we need to be more specific in suggested response
... what is the expected action?

JanL: I am not clear - and touches on another area - diff application - maximum and minimum i expect my application to use - which is another issue

BobLund: so in response, Clarke, it is adaptive bitrate, it is the user agent decision, so the answer is you exceed the maximum, signal to the user agent to only select from a lower bitrate
... Even if resources suggest higher
... if we specify a min, resource has no recourse except to treat as a network error - max makes sense to me, min not so much

Mark_Watson: happy for minimum to be removed

JanL: haven't identified who in the task force "i need it, and for this purpose" --- no one has pointed to a "i need it for this purpose"

Clarke: give people a week, and if no one responses by then, we drop it
... do this from the minutes

JanL: CT1 requirement states overall bandwidth usage - what does that mean? adaptive only or whole browser?
... my impression we were speaking only of adaptive streaming, so suggest reword to clarify
... architecture for overall bandwidth management is much more complex

Jason: i agree, and focus on version 1, a "hint" of what the maximum should be

JanL: TCP/IP socket, clear means of managing the socket

Jason: is intent to limit the bandwidth to that cap, or suggest which bandwidth it should be picking?
... does it need to be more explicit - to describe - to be clear it is either the set of bitrates or the bandwidth of the tcp connection?

Clarke: more the level, a hint to the user agent on the bandwidth - between you and Jan propose some language

JanL: suggestion limit adaptive bitrate streaming bandwidth

Jason: rephrase in the control parameters -

JanL: you do this?

Jason: okay

JanL: one more
... puzzled with CT2 - want a means of selecting only HD level, but don't see control parameters for that use case
... remove CT2 or add controls - old discussion - but to have this use case, we need to specify the control parameter

Clarke: touches on your first point
... 1) parameter that allows us to specify that and then the response wouldbe what bob suggested, if you can meet this, return error message "i can't maintain level you required"

JanL: HD level, HLS, MPEG DASH, there is a reprsentation for HD, not bandwidth, it is a representation, convey to UA an HD level quality

Clarke: do we believe in the requirements, CT2 - people support, and then how do we convey that requirement

JanL: I vote leave it (CT2) and we address it

Jason: HD Level is combination of bitrate and resolution -
... trying to capture HD as a bandwidth thing does not directly correlate - bitrate quality and resolution quality give you the "HD Feel"

JanL: HD for me is a representation, not a matrix of bandwidth - i understand different resolution, different factors, but a means of conveying to the UA I want an HD representation
... we have reprsentation changes call back - we have errors with manifest not being able to parse - all i am missing is how the representation is being selected

JanL: Mark_Watson, you are questioning CT2

Mark_Watson: that kind of control to the web page, language independent of the manifest

or if under the covers by the UA, giving the user control, something the UA should be responsible for - two approaches to handle CT2 in model 1

JanL: what is the second model,

Mark_Watson: language for constraint to be expressed independent of manifest

Mark_Watson (?): user agent that knows what is available, so should give the user what is available -

janl: list from UA representations in their own language, and then i can set - maximum quality using this representation

Mark_Watson: manifest independent language for quality levels
... UA exposes in a non-browser/adaptive streaming specific manner

Mark: haven't investigating media queries - different choices in source elements

<JanL> is this the media queries?

<JanL> http://www.w3.org/TR/css3-mediaqueries/

Bob_Lund: expressing preferences - not media queries - constraints to the UA - independent of each other - i think

Clarke: we can continue this on the reflector and have it as an item for the agenda next week

JanL: buffer size question - but defer to the next phone conference

<Clarke> Thanks for scribing, John