Host considerations

[annevk]

I'm wondering if there are specific steps we could take to improve the process around integrating new language feature proposals into hosts.

One thing that came up is that it might be useful to have a dedicated issue filed against whatwg/html for the various design decisions that need to be made so that we don't have to make such decisions as part of the pull request.

That could also be useful to do in the early stages, as some kind of downstream notification, so that if there are any important host considerations, they can be taken into account early on without late-stage surprises. The web platform in particular has many different types of agents, even agent clusters, all designed with their own goals in mind, and those goals and their design might not always be known or understood by all.

cc @littledan @domenic @codehag

[littledan]

A few thoughts:

• I like the idea of discussing things in issues in affected web spec repos. I think PRs have led to thorough reviews and assessment of multiple implementation support, but maybe issues would be more comfortable for earlier, more open design discussions.
• I've been unclear on at what point web spec folks would want a discussion of TC39 proposals in their repo. When design discussions are somewhat early/uncertain, I am not sure whether to file an issue, and have erred on the side of "not bothering people" until TC39 has somewhat made up its mind on going forward with an idea. I could see how this might sometimes be too late, though.
• I guess both HTML and WebIDL issues make sense, depending on what we're talking about, and maybe more in other cases. Overall, not all TC39 participants know how various web specs would be affected. Maybe a few of us in TC39 who are paying more attention to web specs could focus on explaining the interactions to the rest of this committee, so more can participate; this hasn't been a focus of ours so far. Anyway, it should be more accessible for TC39 participants to file an issue than write a PR.
• We've been trying to do TAG reviews as well. Initially, I was encouraging this when proposals were nearing Stage 3; now, my understanding is that the TAG is encouraging earlier design reviews as well, so we're starting to do that for certain proposals too.

Could I suggest we move this issue to either ecma262 or Reflector? This repo is used more for cross-referencing proposals, not for these kinds of meta-discussions.

[annevk]

Feel free to move this issue as you see fit. I would be okay with whatwg/html being a stable entry point for the "web platform" host so folks don't have to look around too much. Upon stage 2 approval seems like a pretty reasonable time to ask for broader input, from both the TAG and any hosts.

[littledan]

Note, at @kenchris 's suggestion, we've filed for a TAG review on the Stage 1 Records and Tuples proposal. https://github.com/w3ctag/design-reviews/issues/518

[syg]

• TAG reviews between 2-3 seems reasonable given the expected stability of proposals. Seems like web folks would like reviews requested as early as the TC39 champions feel something is stable enough?
• For minimizing surprises, entry to stage 2 seems like the right place to me for starting initial conversations with the various HTML/WebIDL/web platform stakeholders. I like the idea of setting a norm of having champions do a bit of due diligence and identifying upstream stakeholders as an entry criterion to stage 2. They wouldn't be required to engage or anything, just identify. As @littledan said, it also wouldn't expected that TC39 delegates know what's affected, but if it's part of the process they would at least know to reach out to folks who might. Again, like @littledan, sorry for proposing extra work for you! I'd also happy to help facilitate as I build up more familiarity with the other standards groups.

[leobalter]

I wonder what prevents people that can represent their groups and companies to participate in the TC39 discussions. By discussions I mean issue threads on GitHub and meetings (plenaries and the more frequent specific ones). If the TC39 process are insufficient channel, we should investigate what is wrong.

[littledan]

About the timing for TAG reviews: I see two different templates, for "early design reviews" and "specification reviews", at https://github.com/w3ctag/design-reviews/issues/new/choose . I imagine a "specification review" could make sense when a proposal is approaching Stage 3, and an "early design review" could make sense earlier. We filed for an early review for Records and Tuples at the TAG's encouragement while it was at Stage 1; this might make sense for other Stage 1 proposals if they're particularly cross-cutting, and if champions are interested in early input. I've also received criticism in the past that another TAG review, filed during Stage 2, was too late, and should've been filed earlier in the design process.

@leobalter I don't think TC39 plenary meetings need to be the one channel where people have technical conversations about TC39 proposals. That's why we do various kinds of outreach to different groups of developers. We also get together in smaller, special-purpose groups such as champion groups; people interested in particular host environments is similar.

[leobalter]

I hate the gaming of thumbs up emoji. I hope my opinion is not affected because of people cheering through comment reactions.

[annevk]

It probably makes sense to split TAG from this then as I suspect they have slightly different wishes and might also want to see a different set of proposals. Upon stage 2 it seems TC39 wants to see it happen and that seems like a useful point for hosts to help out with proposals that have host implications.

[leobalter]

I don't think TC39 plenary meetings need to be the one channel where people have technical conversations about TC39 proposals

I'm not saying if should be the one channel. I'm saying we also have other meetings and we have the threads on our many github repos. Here, the Reflector, each repo's, and possibly more.