- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Sep 2015 11:53:58 +0000
- To: public-media-capture-logs@w3.org
I agree this is multifaceted. I believe the chairs would be in the best position to take this topic onward (since this is OT for this specific issue now). Here are my thoughts: * abstract versioning Process-driven way would be to tie this to the Rec Track, and say that what gets in CR is considered v1. But this is often too late in practice. My hunch is this particular requirement for advancement should be central to the v1/vnext/extension decision: >* must document how adequate implementation experience will be demonstrated, * expectation settings I feel adding a "v2" or "feature request" label to such issues would solve this. * practical versioning If in WG's scope, chairs investigate if there are enough editorial resources, interested implementers, otherwise work in WICG or a dedicated CG first. * specific extensibility issue More clearly defined extension points would definitely help keep the extensions specs consistent. I kind of like the way how the [SW extensibility section][1]) gives concise and concrete guidance to extension spec authors with boilerplate IDL and prose. This helps keep multiple extension specs consistent among themselves. I feel the Constrainable Pattern section is not as clear in this regard. [1]: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#extensibility -- GitHub Notif of comment by anssiko See https://github.com/w3c/mediacapture-main/issues/236#issuecomment-143722735
Received on Monday, 28 September 2015 11:54:07 UTC