See also: IRC log
<olivier> trackbot, start meeting
<trackbot> Date: 19 December 2011
<scribe> scribe: kinetik
<chrislowis> Scribe: kinetik
<quinnirill> what was the voip address again?
<olivier> zakim@voip.w3.org
<quinnirill> oyea, thanks
<quinnirill> Alistair: can you hear me? :D
<Alistair> No
<Alistair> :-/
<olivier> nope
<quinnirill> meh -.-
<Alistair> Shout a little louder.
<quinnirill> reinstalled voip a few minutes ago
<Alistair> Ah. Can you hear us OK?
<Alistair> :)
<scribe> agenda: http://lists.w3.org/Archives/Public/public-audio/2011OctDec/0150.html
<olivier> hmm no
olivier: process-wise there are two steps. can either make some modifications, republish, and then go to last call.
<chrislowis> olivier: yes.
olivier: want to get to a point
where we're happy with the state of the draft(s)
... then we can go to last call (which is really a first call).
idea is to solicit feedback from outside the group.
... likely will not get a lot of feedback until last call,
usually have multiple last calls
... try to solicit feedback early, interact with webrtc, html5,
other groups to get early review.
shepazu: supports this approach 100%
olivier: continue work on
requirements & use cases to produce a record of what
decisions were taken and why
... starting from two mature proposals, but still need
rationale for what is being produced
shepazu: should not imagine this
is the final version of the API, this is the first version,
will have requests for more features down the track
... track the feature requests, architecture should provide
ability to be extended for later versions
<Alistair> http://www.w3.org/2011/audio/wiki/Requirements
Alistair: started working on
requirements (link above)
... need to discuss testing
shepazu: w3c putting together test infrastructure
Alistair: testing low latency playback of sound is very difficult to automate
shepazu: not all tests must be
automated, but automate what we can
... think about how tests fit into implementers test frameworks
to avoid duplication of effort
... allows implementers to incorporate these tests, and will
encourage implementers to contribute tests back
... different categories of specification: must, should, may,
must not, and should not
... normative vs informative; example code, implementation
notes, background explanation are all informative
... normative (must, should, may, etc.) can be softened, only
essential items are covered by royalty free
... if spec says you must do something a certain way, and is
covered by patent, then royalty free license for patent is
given
... if spec says should do something a certain way, that does
not provide royalty free commitment
... maximum patent safeness = use must everywhere possible
<chrislowis> +q
Alistair: merging basic examples (http://www.w3.org/2011/audio/wiki/Basic-Examples) and use cases (http://www.w3.org/2011/audio/wiki/Use-Cases)
<scribe> ACTION: shepazu to set up new requirements page for history purposes [recorded in http://www.w3.org/2011/12/19-audio-minutes.html#action01]
<trackbot> Created ACTION-8 - Set up new requirements page for history purposes [on Doug Schepers - due 2011-12-26].
Alistair: divide up work and get everyone working on something over a week
chrislowis: what level do
requirements need to be written at? e.g. for two different
approaches to reverb effect (in each spec), so how do we write
requirement to cover both specs?
... both APIs can do same things, but go about it in different
ways.
Alistair: (example) would say "must be able to do reverb", "should be able to do impulse reverb"
shepazu: will be debating
requirements, so write requirement as must (if it's required)
or should (if it'd be nice). 'should' will probably not make
v1.
... 'must have reverb', 'should have impulse reverb', 'may do
it this way or that'.
olivier: wiki has history, edits
are signed, so use wiki to write requirements, and invite
discussion on mailing list.
... link requirements to use cases
... requirements won't solve approach of which API is
preferable, but will make it possible to see which requirements
conflict and then can decide which requirement to kill or how
to compromise
... crogers wanted to backport requirements from his spec
chrislowis: interested in working on this, will talk to crogers about where he can help
Alistair: asking if there is one requirements document that will unify approach
shepazu: and in the darkness bind
them
... this document is for what our API should do, not inclusive
of webrtc/etc.
<Alistair> lol
olivier: question of whether to
have the f2f at NAMM
... Google invited f2f to be hosted at Venice Beach Google
office, or if preference is to host in Anaheim (where NAMM is),
Google may assist with financing conference room
... recommend going with Venice Beach office as it may be
easier to organize
... not too far from Anaheim
shepazu: agrees
... easier to organize, plus wifi will be available, avoids
being distracted from NAMM
olivier: need to decide on a
date, near date of NAMM but not during
... maybe best just after; 23-24th January
shepazu: two days for f2f
Alistair: so much to do, could fill a week
olivier: one day too little, a
week difficult for people to attend
... will go back to Google with planned dates
<Alistair> http://www.doodle.com/grdv8dmy7gf2dqpc
<olivier> ACTION: Olivier to get back to Crogers and Google, make sure they can host us in Venice Beach Google office on 23-24 Jan 2012 [recorded in http://www.w3.org/2011/12/19-audio-minutes.html#action02]
<trackbot> Created ACTION-9 - Get back to Crogers and Google, make sure they can host us in Venice Beach Google office on 23-24 Jan 2012 [on Olivier Thereaux - due 2011-12-26].
<olivier> +1
Alistair: roc and crogers
available Jan 9th, so let's have next call then
... will continue working on requirements, anyone who wants to
help please email, also available for phone calls
olivier: send an email to the list after making changes to get attention and solicit feedback
shepazu: w3c discussing idea of
having a test manager/test editor, who is responsible for
testing
... may be the spec editor, but idea is to divide work
Alistair: sounds good, let's discuss next call and find a volunteer
shepazu: tradionally driven by implementers wanting particular features in spec, so providing tests for that feature
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Venice Beach/Venice Beach Google office/ Succeeded: s/near/near date of/ Found Scribe: kinetik Inferring ScribeNick: kinetik Found Scribe: kinetik Inferring ScribeNick: kinetik WARNING: No "Present: ... " found! Possibly Present: Alistair Doug_Schepers F1LT3R_ IPcaller MikeSmith P1 P10 P16 Ronny audio chrislowis foolip inserted joined kinetik olivier paul_irish quinnirill shepazu trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-audio/2011OctDec/0150.html Found Date: 19 Dec 2011 Guessing minutes URL: http://www.w3.org/2011/12/19-audio-minutes.html People with action items: olivier shepazu[End of scribe.perl diagnostic output]