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 💖
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 💖
BigIntare both proposals. You can find the full list of proposals on GitHub.
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.
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.
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.
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.
There were a few constants between all the days:
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.
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.
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.