Coordination
I'm really happy to see this thread. The past attempts to establish better communications and coordination between the W3C and Ecma/TC39 have had only limited success. I think one cause has been a lack of understanding of goals, plans, progress, and processes among the general population of participants in the two groups.
I have a couple specific suggestions on how to improve this:
-
At every TPAC there should be an invited presentation by a representative of TC39 updating the W3C community on TC39/ECMAScript news, recent work, and future plans.
-
The W3C should proactively invite and encourage TC39 participants to attend and participate at TPACs as if they were active W3C participants.
-
At some regular interval (annually, bi-annually) there should be a formal joint meeting between the TAG and core TC39 members. This is arguably less important now that we have good cross-membership in the two groups but I think it is still be important to try to establish an official communcations path and shared vision at that level.
I realize that this mailing list probably isn't the best one for submitting these suggestions, but this is where we having the conversation and I think the push for coordination improvements needs to start at the grass roots level.
Thanks,
Allen Wirfs-Brock Project Editor, Language Specification
Le 12/04/2013 14:10, Alex Russell a ?crit :
From the DOM side, I don't know that there's enough F2F contact to say that "DOM authors need to be aware of X" from the TC39 side will ever fly without some big checkbox in their lifecycle that says "has been reviewed for idomatic API practice [yes|no]".
This assumes that APIs come to life at the W3C and that when the first
draft appears on the W3C side, there is still time to gather feedback
and modify the API. This is true for some APIs, false for others. Every
major vendor has recent examples of unilateral initiatives that were
first implemented in a web browser then brought to the W3C. I see
setImmediate for Microsoft, a bunch of FirefoxOS "WebAPIs" for Mozilla,
Audio/File APIs on the Chrome side, etc.
Rick Waldron wrote:
As far as "outreach", in my own experience whenever I've offered feedback directly to DOM API authors, I'm frequently met with responses such as "that's not consistent with the platform [/end]".
I've also sent my share of API feedback and been met with sometimes no responses at all which I personally interpreted as "it's shipped or close enough to; it's too late to make an API change now". Of course, that's my interpretation :-)
If we want a useful "API idiomacy review" process, this process has to start at a time it's still possible to change the API. One solution is for all vendors to submit an API to the W3C (or at least public-script-coord) before shipping it. I'm doubtful this will ever happen, but I'd be happy to read if major browsers representative said here that they're committed to never ship before the API has been reviewed for idiomacy. Another solution requires the review to happen "internally" within the organization implementing an API, that is a group [1] would discuss with the different vendors at times they're drafting an API.
My main point here is that APIs being idiomatic will require more than just coordination between TC39 and the W3C. It will require an effort from implementors to share the APIs they're drafting before they ship it/bring it to standardisation. Also note that if a review process happens in the context of a unilateral initiative, what to do of the outcome of the review is up to the unilateral actor.
[1] I don't like the idea of this review process to be restricted to TC39 as being part of it is pay-to-play. Web devs have relevant feedback to share regarding JS APIs (duh!) and not necessarily the money to . Due to their fantastic API work, I wish the Node.js folks would also participate to this discussion. Unfortunate some vocal folks in the Node.js community have shown so much aversion towards standard bodies :-/
On Sat, Apr 13, 2013 at 11:35 AM, David Bruant <bruant.d at gmail.com> wrote:
I've also sent my share of API feedback and been met with sometimes no responses at all which I personally interpreted as "it's shipped or close enough to; it's too late to make an API change now". Of course, that's my interpretation :-)
Whenever that happens feel free to bug me about it. If a WG does not response to feedback they are violating the W3C Process and it's pretty trivial to escalate that. I'm happy to help out. WGs are required to address feedback and reply to it. Furthermore, if you disagree with their response you can raise a Formal Objection which will make it even harder for them. I try not to resort to www.w3.org/Consortium/Process much, but if a WG is a pain it can definitely help. (As you point out though, "sites rely on it" is a pretty strong argument. The constraints there are not different from TC39.)
If we want a useful "API idiomacy review" process, this process has to start at a time it's still possible to change the API. One solution is for all vendors to submit an API to the W3C (or at least public-script-coord) before shipping it. I'm doubtful this will ever happen, but I'd be happy to read if major browsers representative said here that they're committed to never ship before the API has been reviewed for idiomacy.
I'm certainly pushing for this at Mozilla. My impression thus far (I've only been here a couple of months) is that we have lacked resources for that with Firefox OS and were under severe time constraints. We are committed though to implementing the APIs that come out of the standardization process too and we'll do our best to migrate everyone towards those.
Anne van Kesteren wrote:
If we want a useful "API idiomacy review" process, this process has to start at a time it's still possible to change the API. One solution is for all vendors to submit an API to the W3C (or at least public-script-coord) before shipping it. I'm doubtful this will ever happen, but I'd be happy to read if major browsers representative said here that they're committed to never ship before the API has been reviewed for idiomacy.
I'm certainly pushing for this at Mozilla. My impression thus far (I've only been here a couple of months) is that we have lacked resources for that with Firefox OS and were under severe time constraints.
Anney: we did submit drafts for all APIs needed for Firefox OS. See the lists compiled at
brendaneich.com/2012/02/mobile-web-api-evolution (2012, based on work starting in fall 2011 well before anything "shipped")
and
brendaneich.com/2013/03/mwc-2013-firefox-os-and-more-web-api-evolution (2013, and we still haven't "shipped" yet note well)
Were you unaware of this, or did you have in mind other APIs we shipped that didn't have drafts in progress? There may have been a few around telephony, this was the proximate cause of the SysApps WG being chartered, but on the up side these APIs really are only for the dialer or a few other "system apps", and neither needed nor wanted by other apps.
Brendan Eich wrote:
Anney
(Sorry for the typo!)
On Sat, Apr 13, 2013 at 7:14 PM, Brendan Eich <brendan at mozilla.com> wrote:
Anney: we did submit drafts for all APIs needed for Firefox OS. See the lists compiled at
brendaneich.com/2012/02/mobile-web-api-evolution (2012, based on work starting in fall 2011 well before anything "shipped")
and
brendaneich.com/2013/03/mwc-2013-firefox-os-and-more-web-api-evolution (2013, and we still haven't "shipped" yet note well)
Were you unaware of this, or did you have in mind other APIs we shipped that didn't have drafts in progress? There may have been a few around telephony, this was the proximate cause of the SysApps WG being chartered, but on the up side these APIs really are only for the dialer or a few other "system apps", and neither needed nor wanted by other apps.
Apologies for the ambiguity. I meant pushing for an "API idiomacy review" process.
Anne van Kesteren wrote:
Apologies for the ambiguity. I meant pushing for an "API idiomacy review" process.
Thanks -- on that front, recent API work (DAP, WebApps, SysApps) has been about par for the course, from what I've seen. In other words, a mixed bag ranging from nicely-idiomatic or good-enough, all the way to we're-sorry-and-we-will-do-better-next-time ;-). And since nothing has progressed beyond LC yet AFAIK, there may still be time to fix things.
But as I wrote privately, I don't think we can firehose all the new APIs through public-script-coord and get good API review results. We could go API by API in a more focused forum or meeting-like setting, with public-script-coord hosting the notices for upcoming reviews, progress updates, and review conclusions. Thoughts?
But as I wrote privately, I don't think we can firehose all the new APIs through public-script-coord and get good API review results. We could go API by API in a more focused forum or meeting-like setting, with public-script-coord hosting the notices for upcoming reviews, progress updates, and review conclusions. Thoughts?
In principle, github would offer the means for review input from the public (those who are meant to be using those APIs later on).
It might be too firehosey (everybody on the web submitting tiny yet mutually exclusive suggestions), but perhaps a protocol of "serious reviews only, quality before quantity, please" could be established? Or a filter by proven-to-be-useful contributions?
Claus
PS. I would permit public-script-coord to archive my messages, but I refuse to support an archive that doesn't even try to obfuscate email addresses. Hence they won't appear there:-(
On Sat, Apr 13, 2013 at 12:41 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
Apologies for the ambiguity. I meant pushing for an "API idiomacy review" process.
I've just asked for the same in Blink: groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/blink-dev/UYFU8uCTIZs. (I'll definitely be manually reviewing anything we get an "Intent to Implement" statement about.)
On Apr 15, 2013, at 6:00 AM, Arthur Barstow wrote:
On 4/15/13 5:02 AM, ext Robin Berjon wrote:
Note that next week there's a four-day meeting in San Jose involving HTML, WebApps, WebAppSec, and Web Crypto (at least). It's a bit short notice, but maybe we can experiment that there?
I suspect it is too late to add new participants for WebApps' April 25-26 meeting but I can check if there is interest (logistics www.w3.org/wiki/Webapps/April2013Meeting).
Earlier today I added WebApps <->TC39 coordination as an agenda topic www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics. We should be able to accommodate remote voice calls and we will use W3C's #webapps channel.
Personally, I'm in Europe speaking at a conference next week. However, I'll circulate this note to the TC39 members mailing list to see who might be available.
On Apr 15, 2013, at 2:02 AM, Robin Berjon wrote:
I heartily agree with the sentiment in these three proposals, but I'm not sure that they're the best approach.
To begin with, I can't formally speak on behalf of all the API-making groups but I would be very surprised if they weren't enthusiastic at the prospect of hosting a session dedicated to TC39 discussion. I think that you can consider yourselves permanently invited.
The reason I bring this up, is that TC39 didn't go away with a lot of warm and fuzzies the only time we co-located a TC39 meeting with a TPAC (I believe it was 2009). It just wasn't clear where we fit in and how to engage with various W3C groups. Some of this is no doubt simply a matter of cultural and process differences but the end result was that TC39, as a group, didn't seem to really have a place there and within TC39 there hasn't been much interest in trying this again.
So I think a standing invitation probably isn't enough. There really needs to be some proactive out-reach coming from the perspective that ECMAScript is one of the major cross-cutting web platform technologies and hence TC39 to be a real partner various W3C working groups.
The parts I'm not sure about are about having a TPAC session and coordinating with the TAG. There aren't really any properly plenary sessions at TPAC anymore (at least there haven't been in the past two years), so this may not be optimal. We could reserve a dedicated "Talk with TC39" breakout session every year. I don't know if that's enough, but it could be a start.
I see. The only time I attended a TPAC it still had plenary sessions. So how does the W3C generally communicate plans, priorities, information, etc. that cross-cut various working groups?
In general though, I think that holding such a session would be more efficient as part of the meeting of one of the larger API groups, typically WebApps. Things that get communicated to WebApps and decided there are likely to make their way to other groups relatively quickly. And I believe that might be more efficient than talking to the TAG. Even though things might change now that the TAG's make-up has evolved, I would expect API-making groups to listen to WebApps more readily than they'd listen to the TAG.
I'll take your word for it as I don't really understand the working culture of W3C groups. My TAG suggestion comes form a longer term planning perspective. In TC39 we are already working on some aspects of "ECMAScript 7" even though "ECMAScript 6" won't be a standard until Dec. 2014. Are the things we are planning the things that W3C groups are likely to need at the end of this decade? We have our opinions, but it would seem some coordination with long term W3C planning would be appropriate.
So to reformulate your three proposals:
At every TPAC there should be a presentation by TC39 to the W3C community, either in a dedicated breakout session or to WebApps.
W3C proactively invites participation from TC39 members in TPAC (we can handle the details offline).
WebApps has a second meeting (not at TPAC) every year, and it would be a good idea to catch up there as well.
I can't unilaterally speak for TC39, but these sound like good first steps to me.
On Fri, Apr 12, 2013 at 4:15 PM, Brendan Eich <brendan at secure.meer.net> wrote:
I wish I could. The problem is 1) there's many drafts www.w3.org/TR/#tr_Javascript_APIs (not complete), 2) many different lists because the W3C likes to operate that way and 3) the people developing the API don't always care about the API as much as just getting this new platform bit exposed and then move on. There's no sense of shared responsibility. I don't see an immediate way of making that better.
Some of us are looking into A) just going through the specifications and giving concrete actionable feedback, B) figuring out what high-level advice to give, C) IDL that more strongly encourages idiomatic JavaScript.
Another problem we have I think (related to 3 above) is that we don't have sufficient primitives so everyone ends up inventing their own variant. We have futures now, but we don't really have streams, the event API is due for an upgrade, the event loop should probably be exposed to script in some fashion. And resources to work on that kind of overhaul are scarce.
-- annevankesteren.nl