Re: Appointment of two co-editors for the web audio API spec

For those of you who might not know me particularly well, I'm a Developer
Advocate at Google working on the open web platform in Chrome.  I began
working on web browsers in 1993 when I co-authored the original Windows
version of NCSA Mosaic, went on to Microsoft to work on Internet Explorer
for fifteen years, and joined Google in 2010, first on GoogleTV and then on
Chrome.  I have a particular interest in enabling awesome user experiences
on the web platform, have a personal passion around music (I play piano and
keyboards, bass, guitar, and a little bit of
ukulele<http://youtu.be/p2HzZkd2A40>),
love building Web Audio demos <http://webaudiodemos.appspot.com/> and I've
lost count of the web standards working groups I've participated in, but am
current co-editor of the Web MIDI spec and member of the W3C Advisory Board.
I'm happy to be working together with my colleague Paul from Mozilla on
editing the Web Audio spec; I've spent the past year and a half working
closely with Chris Rogers, learning an immense amount about digital audio,
and I'm looking forward to collaboratively prioritizing the remaining
issues, working out solutions and getting the spec fleshed out, polished up
and deliver to the web.  Paul pretty much covered how we plan to go about
that, so I'll return you to your regularly scheduled programming.  :)
-Chris


On Tue, Aug 27, 2013 at 6:48 AM, Paul Adenot <padenot@mozilla.com> wrote:

> Hi everyone,
>
> I am a developer at Mozilla, working mostly on various modules that
> interact with audio and video, such as media elements, WebAudio, WebRTC,
> from user or author-facing features, to the interaction with OS-level
> API. I've always been interested in audio software development, probably
> because I've been using them for so long, as a musician. I'm also doing
> demoscene and (very) amateur video-game development in my spare time,
> most of the time working on the audio side of things.
>
> I strongly believe that as editors, our role should be to write down
> what has been decided in the group (that is, to not _author_ the spec
> ourself, _edit_ it), and I hope to continue to have fruitful discussion
> with anybody who wants to be involved in making this spec go forward.
>
> In the short term I'm planning to start the job by trying to get the
> number of open spec bugs to something lower than 140, with an emphasis
> on minimizing the spec holes, so another implementer can come
> along and write a whole new implementation without looking at Gecko,
> Blink or WebKit's code. Most of the time this will mean making
> uncontroversial amendments to the spec (stating on paper what everybody
> thinks, use, and have implemented), and reflecting in the spec decisions
> that have been made, but not written down.
>
> In the mid-term, I think we could try to consolidate and improve the
> test suite [1]. I believe that this will be beneficial for both
> implementers and users of the WebAudio API. Blink/Webkit and Gecko have
> both decent test suites (and we should borrow from both of them, if
> allowed), but I hope real-world users of the WebAudio API will be able
> to contribute tests, or ideas of tests as well.
>
> Cheers,
> Paul.
>
> [1]:  https://github.com/w3c/web-platform-tests/tree/master/webaudio
>
>