Here’s what you can expect to find:
- a list of all attendees
- an account of all substantive comments, annotated with speaker name
- a summary of every discussion’s resolution (or lack thereof)
- links to supplementary materials
All this is curated to omit the occasional “rat hole,” approved by the delegates themselves, and published to the web within days of the meeting. Much of this is thanks to Rick Waldron, who spent the past seven years attending meetings, taking notes, and formalizing the process. Today, Rick is stepping down from this role, so we’re reflecting on his achievements.
What does it matter?
“That’s nice,” you might be thinking, “but I have bugs to fix.” The details of programming language design may seem a little abstract to the typical web developer, but we all benefit from the clarity the practice brings.
The committee makes dozens of decisions in each meeting, including changes to the language specification and to the developing proposals. As the specification editors and proposal champions enact those decisions, they rely on the notes to be sure nothing falls through the cracks. Participants sometimes question why established features have a certain behavior: “Is this intentional, or is it a spec bug?” The notes can put such doubts to rest.
The people who implement the language don’t have perfect recall, and they aren’t always present in the first place. For Adam Klein, looking up the notes is a central part of updating V8 (the engine that powers Chrome and Node.js). Caitlin Potter finds them particularly important when working on bleeding-edge features for V8 and Safari. “Invaluable” is the word Henry Zhu used to describe the notes’ importance to their work maintaining Babel. And while introducing ES6 in Firefox, Andy Wingo relied on the notes to understand which features were stable enough to work on.
Finally, the notes help everyone appreciate the malleability of the language. It’s easy to take our programming language for granted, but the notes demonstrate how it’s actually the product of human hands. Modules are a great example: it took a lot of iteration to land on the syntax we know and love today. This discussion from the November 2012 meeting shows just one step of that iteration, chronicling the uncertainty in the design of something that today feels so solid.
Building a Standard Workflow
It wasn’t always this transparent, though. Way back in 2012, a few members would post brief summaries to the es-discuss mailing list. The summaries lacked consistency, and they didn’t necessarily capture the full depth of each discussion. There were also complaints that that list was intimidating for newcomers.
In May of that year, Rick attended his first meeting as a representative of the OpenJS Foundation (formerly the jQuery Foundation). He volunteered to take notes that day, and he’s been improving the process ever since. He enhanced the level of detail, providing what delegates have referred to as a “play by play” of each discussion. He expanded the format to document the attendees, to allow for linking from the web, and to attribute each comment to the person speaking. He began publishing the notes to his own repository, to Ecma directly, and later to TC39’s new account on GitHub.com. Rick also created tools that transform the notes into a full-fledged website.
Rick’s colleagues took notice, and they wanted access in real time! He moved from his text editor to Etherpad to accommodate them. When demand exceeded that app’s resources, he moved to Google Docs. Rick invited all the attendees to review and correct his work, observing a week-long grace period prior to publication.
The timing of all this couldn’t have been better. ES6 was the largest revision to the language yet, and it was just beginning to solidify. Coordination between authors, implementers, and test writers was essential. Allen Wirfs-Brock, the editor of the ES6 specification, had this to say:
Rick’s notes became invaluable to me for the final three years of ES6 development. Going through those notes and making the necessary changes became a standard part of my workflow.
People sometimes assume that clerical work is mundane. The evolution of this practice and its benefits to the ecosystem serve as a powerful counterexample.
The Next Draft
ECMAScript isn’t the only thing that’s changed over the past seven years. Implementations have come and gone. TC39 has grown in size and diversity. The features under consideration have become ever more complex.
These changes would be challenging enough for a humble scribe to tackle on their own, but Rick’s had even more demands on his attention. Between a promotion to “Director of Engineering” here at Bocoup and a promotion to “Dad” at home, keeping the notes has had to take a back seat. That’s why Rick’s been training folks to carry on the tradition. Already, they’ve been devising new strategies to distribute the load and motivate volunteers.
Keeping minutes for TC39 is a demanding job, but we know it’s critical for the advancement of the language. We thank Rick for all his hard work, and we send our best wishes to the delegates who are taking up the cause.