I worked for Google as a developer advocate for Google Cloud Platform.

Been participating in T C 39 for just over three years.

My name is Michel Sabah.

If I work in Apple on the JavaScript core engine been attending T C 39 since 2015.

Maybe my name is Mark Miller.

I started on T C 39 in 2007 while I was a Google.

About two years ago, I left to form a goer.

Eh?

Quiches.

A block train.

Start up where we're going to be running JavaScript on Blockchain on.

And I've been doing a lot of work to make the language better able to support more disciplined and more secure programming.

I'm AKI Braun.

Um, I work at people.

I work at Braintree at PayPal.

Um, I have been on the committee since 2017 and I have been co chair.

This will be my second year.

Hi, I'm Rob Palmer.

I work for Bloomberg, where I lead the Java script, infrastructure and tooling team.

I've been on the committee since 2000 and 18 and just this week, I became one of four coaches like AKI here.

Hi.

My name's Shane car.

I've been on Sisi 39 since 2018.

I am, uh I'm working at Google on the internationalization engineering team.

Um, and I leave the lead the internationalization subcommittee for T C 39 focusing on making job scripts.

Ah, language.

That's very friendly for for international first applications.

And hi, I'm Justin Original.

I also work for Google.

Uh, I work on the AMP project, and I'm one of the core maintainers on Babel.

How so many impressive people in the room?

Um so the first question that pretty much a lot of people have asked is what is the organization behind T c 39 what actually is t c 39?

Any one of you can answer that, I'm sure.

Very well.

Um Okay, So T C 39 is the 39th technical committee of ECMO International.

Expert International is a standards body.

Um, they are who publishes the MUS Crypt standard once a year, which you may think about, you know, yes.

2015 changed a lot of things.

Sure, but every year now it gets published.

3 16 17 yesterday, 20 will be published in July.

Yeah, yeah.

Um, so we gotta is, uh, organization made up of member organizations is a standards body that large corporations, small companies and nonprofits and universities can all join.

And once ah, organization has joined Acma, they can send delegates.

That's what we all are delegates to Ah, to technical committees.

I don't know if that actually explains what's behind.

Ah, he's very Internet.

That answers.

That answers the question pretty well.

Um, so I'm sure you get a lot of features, requests and features that are proposed everything.

How does a feature move through the committee through the proposal process?

Um, we have a stage process in the documentation of stage one through stage.

For there is a stage zero.

Um, computer scientists, we don't know how to count.

We start counting it zero instead of one.

Um, but a stage zero stage one is this is an idea that that someone thinks would be good to add to the language in stage One proposal basically says the committee think this is worthwhile to consider adding the language.

Stage two is now in the step where you're gonna look.

Att spec Tex s o.

How you specify it.

You define semantics and things like that.

Stage three is where it's implemented.

Bye.

Least two imitations and implantation doesn't necessarily have to be, for example, the engine jobs convention site of a browser.

It could be, for example, of Babel in implementation.

It could also be there's ah, embedded engine called excess.

Um, it could be in that engine as well and stage for it's in the language stage for synonymous with its in the standard.

And we say something stage for until it's producing that standard.

So their Stage four proposals that would be part of the 2020 years 2020 um, and after 20 twenties out we won't call them stage, for they're just in the language.

That's basically the process to go through.

It's typically done by a champion that's going to take it or champions.

There could be more than one person, more than one delegate that's going to take it through.

That whole process, there's some debating on is this.

The stages is something that we think is worthwhile are people use it.

What use cases.

Also, the semantics of this Mannix mesh well with the rest of language.

So on and so forth.

So that's basically the process that we go through to put something in the language.

So, uh, for a wee consistently say, it's worth noting that, um, our standard for whether or not we're gonna tackle something in the first place isn't Is this new, uh, syntax or a P I something that we want to add?

It's Is there a problem that we're going to solve, which I think is ah, maybe a different approach than a lot of people assume that we make to making changes.

Language?

It's it's we's.

We identify problems that need solving, and from there we decide how we're going to do that.

So I first heard about optional chaining, which I think is stage for now.

Now, Um, I first heard about that, I think when it was stage zero, which was, like, three ish years ago or something 2016.

And so is that typical for something to take that long to go through Stage zero to stage.

For how long does something typically take?

Years?

Um, so I was actually one of the co champions on optional chaining.

Thank you.

The actually saw their Google internal documents suggesting optional chaining back in, like, 2012.

Uh, the fact that we have on Lee finally produced the spec tax for it and tried to go to the staging process.

Starting in, like, 2016 or so, Um, the I think there was a little bit of infighting About what?

The scope of what we wanted to do with optional changing And how far like the optional nous of the chain is, um, where ends whether or not should be undefined there?

No.

Um, so that took a little bit of time, extra time in order to work through.

Um, but then once we actually add, like, a concrete idea, we knew all the solution to it.

It only took, um, maybe three meetings to go from the stage to stage three and then the stage for, um So once we actually have agreement about overdoing, it's pretty quick, but it's getting that initial idea hammered out that took forever.

Yeah, and I just had to that really quickly.

So as Justin mentioned, we meet multiple times a year.

So we have six meetings a year every other month.

Um, generally a future.

If it goes for stage advance in advancement only goes one stage per meeting.

Um, and so in theory, and this is not generally in practice, but kind of the fastest you could go through the whole process.

Um, would be, like, eight months.

Um, has anything ever gone in eight months?

I don't know if it's gone that fast, but I have seen proposals, for example, that air for very verily, clearly defined, um, features that come in a stage two because they've come with a really, really clear use case.

The spec text has already written.

It is not controversial that this is something that we need.

Um, I'm spacing on the exact when I know that a delegate make Samuel had a couple catch went through very quickly up.

She'll catch just I'm a bit puzzled by the process.

Implication there.

I don't remember anything s so to speak, coming in his stage to just that it rapidly advanced stage.

There's a few examples from the internationalization point of view where we bring things directly in its stage two, which sort of subways for how to proposals work on internationalization.

So we have a subcommittee where we were we review internationalization Pacific features.

This is things in the insult object.

So Intel number for Mitt until date format until cool later.

Those kinds of things, and we review you know, the those proposals and check the use cases and check the implements ability of them before we bring them to the full committee.

So we frequently have proposals that come directly and at stage two because we've already done a lot of this vetting before we bring them to the larger committee.

Um, and you know, it means that sometimes we can have proposals that go through the process faster, be because of that, um, for prefer intell.

I find that the biggest bottleneck for us is getting the implementations, because in the internationalization AP, eyes tends to be to tend to have a lot of dependencies and are more difficult to implement sometimes because you know, they very greatly from, you know, language to language and, um, region to region.

Um, so So we tend to have a lot of proposals that gets stuck in stage three, um, and then say it's age three for a year or more before the browsers have all have have implanted them.

Um, whereas whereas I know a lot of other proposals to get stuck in stage one, stage two.

And one thing I was just gonna add really quickly is there is somewhat of an ambiguity in the stage.

Is, um And so the conversation that Mark and I were having right now is actually a very healthy debate that can often happen around like there is the reality of how things go through.

But then our understanding of how that applies to the stages convey Ari.

And so it is not uncommon were a group of people who like being pedantic.

It is not uncommon that during a meeting we may actually stop and discuss the process and ensure that we're being fair to the process that we're following all the criteria in I at least like to think that it is, to an extent, a living thing.

And we want to be flexible, and we want to have a process that creates a great language.

Um, so, you know, even just this past week, I think probably almost 1/3 of the committee time in the three meetings that we had were discussing a variety of different process changes that were exploring, um, for a number of different reasons, including potentially introducing Maur remote work that we could do arm or ways of meeting in between meetings because one of the things that can't happen, um, for good or for bad.

Um, if you bring something for stage advancement and someone points out something that you hadn't thought of between the two meetings something and get delayed for two months, which is why things can take three or four years.

So we're actively trying to think of different working modes that we can use to minimize the possibility of that happening.

So speaking of all of this process, and you mentioned the actual implementation part, uh, how does the implementation process work?

And how do you actually know that things are being implemented correctly?

You can use my mike if it doesn't work.

And so one of the key criteria, or actually landing in this speck and getting it into stage four is that we have conformance tests.

So the main project for that is that test 262 um, and that has a number of maintainers broke, moved on a lot of work on that I'm Oh, yeah, a ton.

A ton of work there with Leo Vulture in particular contributing.

And so having that all implementations go through should be our percent compliant with that.

Ideally, I think you can see a lot of the stats that this store still while I wait to go there.

Oh, yeah, there was a project.

Oh, you can You can see them for yourself at test 262 dot report, it's ah website that shows each of the engines and how many tests what their compliance looks like on and all of you in the room can help with this as well, because whenever a feature is released, it normally comes out in browsers in early versions like canary versions.

Maybe it's behind a flag.

So if you enable these in your browser's on, then try to make their If you find any issues, you find any bugs.

Or maybe you just got feedback.

Maybe you like it.

Maybe you don't Please do it.

Please do provide that feedback A.

Ll.

The proposals have a repo on get tub so you can raise an issue there.

And that's always massively appreciated.

Wait, You see, a lot of people are reporting riel life things.

There we can file an issue on the brains of bug trackers as well.

So you say, Please, please do try an experiment in heaven.

Our organization is T C 39 on Get hub and you can see every proposal we're talking about and, uh, the agendas for every meeting we're doing and a few other things.

So it's the easiest way to actually participate in the process back to the implementations during stage tree.

That's where these augmentations are being done.

And quite often, we quite often it's often the case that we find that we're under specified about certain semantics.

And so implementation a will do something.

One way implementation be will do something slightly different.

And it's during that that process, either using test to 60 or the test that those invitations right to validate their own imitation.

We find there are some discrepancies, and we work through those discrepancies and unify things, and we're going through a proposal now where there's a little unification around that.

But that occasionally happens, and that's why we have that implantation stage or stages primary focus on implantation that we make sure that we're compliant with each other.

We compared with each other as well as compliant with respect, says I always like to talk about weaknesses as well.

A strength A test 262 is an amazing piece of work, but it's important.

Understand that it consists of very, very detailed unit tests that go through the spec kind of in order and try to make sure touch everything in the speck individually is a unit test.

What it is not is an integration test.

Languages have lots and lots of non local and non orthogonal interaction between features, and we have repeatedly seen non conformance that was not detected by Test 262 at the non orthogonal interaction of different language features.

So going forward, one of the things that that I was very much like to see, uh, is, uh, some creative thinking on how to bring more integration test to testing the language on how to do that without a combinatorial explosion.

I think it's an interesting problem.

So are these repose that you've all mentioned is that the best way to interact with the committee?

Are there other ways that individual developers can get involved outside of being a delicate from their company?

here so many ways you can get involved.