A few weeks ago I had the opportunity to attend TC39, the ECMA technical committee that defines the ECMAScript specification, for the first time. As a first-timer, the experience wasn't what I expected and I want to share what it was like being there. I'd like to share that experience with y'all 💖
What the heck is TC39
TC39 is a Technical Committee (hence TC) under ECMA International that defines the ECMAScript standard – better known as JavaScript. There's a pretty good article outlining what the differences between the two are over on FreeCodeCamp.
tl;dr: TC39 builds the specification that browser engines implement that lets you run JavaScript.
Terminology
I wanted to build a tiny list of terminology because there is a lot of words that are commonly used in the meetings. Trying to interpret the terminology while also keeping up with the discussions was a challenge. Going into the meeting, I knew none of the terminology. Over three days I ended up catching on. In the rest of this article, I'll be using some of these terms – I wanted to put them up front so y'all will be able to refer to them 💖
-
Proposal: A proposal is a suggested addition to ECMAScript. For example,
import()andBigIntare both proposals. You can find the full list of proposals on GitHub. - Stages: The mechanism that TC39 uses to advance proposals. I would argue this is a consensus mechanism, though others may disagree. You can find the entire staging process in the process document.
- Plenary: The part of the meeting in which proposals are being discussed. Effectively, when everyone is in the room discussing proposals.
- Normative: Typically brought up in the context of "normative changes", when something is normative it's a requirement in the spec that's not reflected correctly. A "normative change" is a change that is intended to resolve such an issue. Basically, they're bugs in the spec. See @allenwb's comment on this post for more context!
- Delegate: An individual representing a member (members are corporate entities) of ECMA International.
- Invited Expert: Someone who is invited by the Secretariat General (a role currently held by Istvan Sebestyen – you can see the job description here) or a member or of TC39 (as far as I can tell?) as a domain expert. They are not delegates themselves.
Expectation vs. Reality
What were my expectations going in?
In the context of the plenary session, I was expecting was an extremely high barrier in terms of a computer science education and in terms of understanding how specifications work. That is not my background, so I was... nervous about that expectation.
As an extension of that expectation, I was confident that I wasn't going to be able to contribute to the meeting much at all – I was expecting to observe the meeting to figure out if there was a path to meaningful contributions for me.
How did my expectations stack up to reality?
In reality, the technical barrier was a lot lower than my expectations. There was a lot I didn't understand, but that mostly seemed to stem from not being familiar with the specification and how certain parts of it work – less of a "you're not coming from a computer-science background" and more of a "you're not familiar with this specific context." I know I can catch up on context, but I don't think I can reasonably catch up on a comp-sci degree.
This isn't to say that a computer science background wouldn't be helpful (it absolutely would), but I'm not feeling left out because I don't have one. There is a tremendous amount of work that can be done with other skills. Technical writing, reviewing, contributor onboarding, and even experience with JavaScript as a developer of any level are all traits that are appreciated in the meetings and in work on GitHub.
Additionally, I was surprised that there were multiple paths to non-trivial contributions that weren't just technical contributions. Just like any good open-source project, TC39 seemed to value non-code contributions. I now realize how... silly my expectation of not being able to contribute was because the vast majority of the work done in TC39 isn't actually about writing code. There is absolutely code written (see, for example, the Realms proposal, which has a shim, examples, and other bits of code) but an immense amount of the work seems to be writing docs, building consensus, and other work to help surface both the specification and the processes via which the specification are built.
I was incredibly happy to be able to assist with meeting minutes – of which there were roughly two dozen pages written on each of the three days. As someone with ADHD, it was awesome to be able to follow along with the discussion by typing out what I was hearing (this personally helps me commit information to memory more easily) and work with 1-2 other people at a time on getting content into the minutes as a team. Additionally, there were several points when I hit a limit of being able to focus on the discussions, and I was able to spin out at those points and focus on something else. Everyone who was working on the minutes was incredibly friendly, and I felt like that contribution was valued – something I'd 100% not expected out of the first meeting.
Timeline
TC39 meetings span three days. I'm not sure what the plan usually is, but this meeting was Tuesday, Wednesday, and Thursday. I assume they intentionally put it in the middle of the week so delegates can travel and attend on their work-week, rather than forcing them to travel over the weekends.
Let's dig into what each day looked like in terms of what happened in plenary and planned activities.
Day 1:
- Plenary session:
- Started with What seemed to me to be boilerplate kickoff presentations (some metrics reporting about the spec
- Some high level "normative" presentations
- Advancement of a few non-controversial proposals through the stages
- After plenary, there was a first-timers meetup, led by Aki Rose Braun – one of the TC39 co-chairs.
- I found it helpful to identify who else was also at the meeting for the first time (a few people from Netflix, IBM, GitHub, and of course myself from Microsoft).
- This meetup provided a space for me to get the vast majority of my questions answered!
Day 2:
- Plenary session:
- Discussions of the more meaty/controversial proposals started.
- Multiple people told me this would be how it went on Day 1.
- The proposals discussed were all at various stages – 1, 2, and 3.
- I'd not expected this much diversity in the levels of maturity of each proposal, but it was exciting to see how the conversations were slightly different at each stage.
- One of the biggest takeaways from this experience was that certain types of concerns only come up at certain stages, and some concerns can be ignored until a proposal reaches a given stage.
- One or two discussions went into overtime and had additional time allotted to them later so we could continue working through the other proposals.
- Discussions of the more meaty/controversial proposals started.
- Ended with a dinner for the entire attending membership (and invited experts) of TC39.
Day 3:
- Plenary session:
- Almost identical in structure to Day 2.
- Major difference that I noticed in this meeting – not sure if this is standard practice – was that the the proposals for features that typically get a lot of attention from the broader JavaScript ecosystem were on Day 3, as opposed to the features that get less widespread attention.
- Ended with the Modern JavaScript: /runtimes/ meetup that was organized by Myles Borins.
There were a few constants between all the days:
- Breakfast and lunch were provided by the venue each day.
- There was about an hour for lunch, and several 5-15 minute breaks throughout the day.
- Individuals – myself included – dropped out often to attend meetings or complete their normal work that they needed to do. Plenty of space was available to do this, and it wasn't looked down upon at all.
- Each night, some tangent of attendees ended up going out to grab dinner as a group whether or not there was something officially planned.
Something I'd not expected in any way was the hallway track – during lunches, breaks, and at the dinners I attended, I had many excellent discussions with people who I'd not met before. Everyone was incredibly warm and welcoming – probably more so because I was a first-time attendee.
Also worth noting that this specific meeting was graciously hosted in the Google NYC offices, thanks to Myles Borins and the cast of JavaScript Googlers in NYC.
Takeaways
Even though I'd come in with few expectations, the entire experience broke the mold that I thought it would fit in.
Every single delegate that I talked to was extremely encouraging of new participants, absolutely following the same structure and practices that I've come to expect from open-source projects – straying from how I'd assumed standards bodies operated in general. My unique personal background was valued. I was warmly welcomed and gently encouraged to contribute however I felt comfortable. The kind of non-technical work that I end up doing – documentation, first-timer onboarding, and context building – is something the group is looking to do more of.
One of the threads that were brought up each day in various ways was engagement with the broader JavaScript community – not as a question, but more as a value. Much as my assumptions about standards bodies were challenged by work that's already been completed around encouraging new delegates and their participation, I'm extraordinarily happy to see that the individuals who represent TC39's membership care about this and are holding it more like a core value and less as "something we should probably do", as I assumed.
Overall, the experience was different than anything else I've ever done in terms of technology and community. I fairly confident I'm going to continue participating as a delegate, and see how I can meaningfully contribute to processes, community, and the spec itself.
Top comments (21)
This is really great. Gone untended to, these sort of things tend to only cater to power users who have been there many times before. That's where you wind up forgetting about 90% of the users who will be interacting with the technology.
Yup, 100%. I'll be honest, I expected standards bodies to be extremely elitist and effectively have an implicit caste system where the opinions of people who have been attending for 10+ years would be the most valid and would override anyone else's opinions.
I've never been more happy to be so entirely wrong. Everyone on the committee was very engaged with the suite of new participants (there were at least 6 of us who were first-timers) and I get any sense of elitism at all. They actually valued the fresh perspectives because they understood the burden of knowledge and appreciate the fresh context from practitioners.
Welcome to TC39 and thanks for sharing your experience.
Regarding "normative". Generally, when we say "normative" in TC39 we mean something that is an actual requirement expressed in a specification. These can be big like "Promises are part of all ECMAScript implementations". To tiny, such as the ordering of specific actions within a single specification algorithm.
Most of the text in TC39's specifications is normative and most of the work of TC39 ultimately leads to decisions about new normative requirements. This includes all of the proposals going through the staged process. Deciding upon normative requirements is so fundamental it is seldom mentioned in that context.
When "normative changes" are explicitly discussed at meetings, this is usually about some very minor change to the specification of some larger feature that is already in the specification. Like swapping the order of algorithm steps or adding (or removing) a required error check. Often such changes are specification bug fixes. Sometimes they are are needed to bring the specification into alignment with what implementations actually have implemented. Regardless, they require TC39 consensus because in some way they change a requirement that will have an observable (put usually minor) impact on implementations and in rare cases could impact real world code.
Ah, thank you for the additional context Allen!
This... makes sense in the context that it was brought up within the meeting. Coming from a place of still trying to grasp the context of "grammar" in the spec: can normative changes happen around grammar as well, or if changes to grammar would be a different kind of change?
Also: I've added a link to your comment and updated the post to reflect the context you've shared. Thank you for taking the time to explain! ❤️
Sure, as "normative" applies to anything that is an actual requirement and the grammar defines the syntax that an implementation is required to recognize.
But while normative grammar issues have occurred in the past, I would expect small bug-fix level normative changes to the grammar to now be quite rare.
Thanks, Tierney, for sharing. I'm just curious:
Thanks for the kind words Eugene! 🙏
To answer your questions:
TC39 meets every 2 months in a location somewhere in the world. For example, this meeting was in NYC (low barrier for me since I live in NYC), but the next one will be in Berlin immediately following JSConf EU.
There are actually a significantly larger number than 63 that you can see – those 63 have just made their membership in the GitHub organization public (GitHub defaults to private, and many developers in general don't know that there's even a toggle for this). There about 3x that many members of the org.
My rough estimate is that there were 50-75 people in the meeting. The meeting spans three days and some people were only able to attend for a day or two, so it's hard for me to assert exactly how many people were there without looking at the attendance sheet.
So the "TC" part is important – it stands for Technical Committee, which is a part of how ECMA International (the body which TC39 is under) is structured. The answer to your question is incredibly simple, as far as I know – TC39 was the 39th TC/TG 😁
You can find a list of all (current?) TCs on the ECMA International website. You might notice a few others that cover areas you recognize, like TC49 and TC52.
Oh nice, this is something new to me. Thanks for sharing!
Thanks for the detailed reply!
Thanks for sharing Tierney!
Really happy to hear about your experience, seems like it's indeed more welcoming than looks on the outside.
Couple of questions :
Thanks for the questions, Liran ❤️
To answer them:
They were deeply technical but not in a way that I couldn't follow. It was honestly similar to a classroom style presentation, except where everyone wants you to understand and succeed – and one where you can use the Internet to figure out what the heck people are saying. I opened up Google and the spec often when there was a word I didn't understand, and if I couldn't find an answer I just asked someone once we were out of the actual presentation.
The in-person meetings are every two months.
Thanks!
Looking forward to more of your updates from these meetings.
Thanks for the write up Tierney. Nice to get an insider's view of these meetings.
No problem! If there's anything in particular you're interested in about TC39, I'd be happy to try to capture the answers and share them in future posts 💖
Great post! Very well explained! Thanks.
Thank you! 🙏
Awesome post! I’m glad you had a great experience, thanks for sharing
Thank you, and no problem! Hopefully this post gives others a bit more insight into what TC39 is like <3
Thanks for the writeup 👏👏👏
No problem, Simeon! ❤️
Did you take some pics you can probably share ?