One of the great things about running events is that, from time to time, you get the opportunity to invite people you admire to speak. For me, that is the case with Jory Burson, who will be one of the day 2 keynotes at jsMobileConf in Boston this October 25-26.

Jory is the standards liaison and former COO of Bocoup, a well-known web platform consultancy out of Boston. I first had the opportunity to meet Jory about seven years ago when I attended one of Bocoup's training courses. As I got to know her over the years, I saw her rise to leadership roles both within Bocoup and within Bocoup's advocacy work as their representative at Ecma International, the JS Foundation, W3C, MDN Product Advisory Board.

Jory will be discussing JavaScript's standardization efforts in Ecma TC39 at jsMobileConf, so I thought this was a good opportunity to discuss her background, how she got involved with web standards, and some of the work she's involved in within TC39.

Q: You have a bit of a unique background. Your bio says that you had jobs like teaching media literacy at Oklahoma State, managing restaurants and even raising cows. How did that background lead you to Bocoup and a focus on developer advocacy and open source?

I do have a strange background considering my role. That’s true of a lot of people in web development, and I think it’s a really good thing. We’re building tools, products & services for a LOT of different people, and coming at those challenges from a diversity of experiences, perspectives and thinking just makes the experience sooo much better. To new developers, I’d like to say you never know when or where your life experiences are going to come in handy - please don’t erase or minimize that part of who you are as you go on your path!

I was very active in 4-H & FFA growing up - I showed pigs, cows, horses, and absolutely loved it. I made a ton of friends from all over; we helped each other take care of animals, learn, and compete as a team. This experience is definitely the root of my desire to be part of and contribute to a community.

There were a couple of summers, starting in about 1997, I would come in from the midday heat and go online to play this game about showing horses. You had to make a web page about these fictional horses, and people voted on it. It was really silly but I liked it. The better your page looked, and the better you could tell stories about these fake horses, the better you did.

I think a lot of us came to this field because some other passion or interest brought us here, and over time you learn to think of the platform as a tool rather than an entertainment device. I don’t know when I realized that exactly, but in journalism school I started thinking about how much our communications mediums were controlling our experiences, directly and indirectly. I wanted to be able subvert that, and I wanted to be able to express my own stories, but I didn’t understand enough about how it all worked. So I went to graduate school and studied communications.

My thesis work was on media literacy, which is how we produce, consume, access, and analyze messages and mediums. What I learned in the course of that study has helped me immensely in the years since, especially when it comes to connecting practice and theory. When I became a full-time faculty member I got to put a lot of those ideas together for undergraduates, helping them understand and work with the constraints of the web and other media. My main class was Electronic Communication - the students had to make a web page and blog, cover different kinds of stories, and embed all that media on their sites.

My partner got a job at a startup in Boston in 2011, so we made our big move from Oklahoma. I joined Bocoup to help run and grow a developer training business - my classroom experience and non-traditional background ended up being a great fit both culturally and for the role. Bocoup wasn’t put off by it at all - they really appreciate and celebrate different backgrounds, and encourage you to keep exploring what interests you. So I have them to thank for where I am today, too.

Q: Your talk at jsMobileConf focuses on standardization around JavaScript, which seems to have a long and complicated history dominated by politics of Microsoft and Netscape in the early years. Noticeably, there was a 10 year gap in published standards from 1999 to 2009. How do you think this complicated history impacts the current state of the language standard, if at all? Does politics still have as strong an impact on the process?

History absolutely matters. The first few editions of the language were about direct market competition - Netscape/Sun were looking to publish a JavaScript standard as a defensive strategy against Microsoft. Microsoft was looking to maintain its dominant position by pushing VBScript and JScript - they joined to keep things out of the language. ES1-ES3 codified pre-existing, shared bits between JavaScript and JScript, but a lot of the features and grammar questions remained contentious.

Today, the market has changed and the companies participating in TC39 have different business interests in the language than they did back then. They may still be competitors, but this isn’t really where they’re directly competing, and they’re here to help protect and invest in the web platform which supports their actual, competitive products.

The first JavaScript standard was published in less than a year, which is lightning fast for a consensus standard. The next two versions of the standard were also published fairly quickly. Then we entered two long periods of slow or no progress. A lot of turnover happened on the committee at that time, and a lot of developers started picking up things like ActionScript and Silverlight instead.

Today the committee has committed to a yearly release cycle, because we need and want to be responsive to the needs of developers and the changing landscape of the web. It’s a lot more like an open source project in terms of how its developed. On the other hand, that’s a pretty rapid pace of change for developers and we know it can be overwhelming to feel like you need to stay 100% on top of it at every release. So there’s an equilibrium to strike.

There are politics at play in any cooperative human effort. Today’s TC39 politics are different. We’re tackling culture change, policy updates, opening up process - the challenging human stuff that also makes a big impact on the spec. There are still debates on features, but it’s in everyone’s interest to protect the grammar, make it more secure, make it understandable, and there’s a lot of alignment on that.

Q: Starting with the massive update of ES6, now called ES2015, the process changed to a system of more consistent yearly specification update. Can you share some of how the new process works? Does the change in process impact thinking around new language features?

This process is actually one of the big differences between most open source projects and open standards efforts, and I think it’s pretty great.

TC39 currently has in-person meetings every 2 months. Throughout the year, delegates and community members work on different feature proposals or issues, and during the meeting they present on their progress, lead discussion, ask for feedback etc. If appropriate, they might ask to graduate their proposal to the next stage (there are 4 stages). If there are no objections, then the proposal goes forward. Once a proposal reaches stage 4, that means it will be merged in and published as part of the next official version of the spec. Until then, the whole thing remains a draft spec.

At the November meeting, we feature-freeze. Nothing new gets in. Anything that was a stage 4 proposal before officially becomes part of the standard. The editors then get to work polishing the spec text, and in January we have a 90 day spec-text freeze for IPR clearance. In June, the Ecma General Assembly (the body of all delegates, not just those participating in TC39) votes to accept the standard as an “official” Ecma standard. So this coming November, the delegates will vote to accept the stage 4 proposals in to the new spec, and that will become ES2019.

Then the process begins anew!

The process does impact new features. For one, because it’s a yearly cycle, there’s less consequence if you don’t get something in - there’s always next year. On the other hand, that can lead to a lot of activity and pressure at the end of the year to get something finished. Another thing, that’s
maybe not such a popular point of view: the committee really has to be able to say “No” - what we keep out of the language is maybe more important than what gets in. I think this process makes it a bit more psychologically safe for people to say no, because we can more easily think of a No vote as “Next Option” or “Not No, but Not Now.”

Q: I imagine that anyone motivated to participate in a standards body has a tendency to be highly opinionated. How does the group manage to make sure everyone gets heard and has a chance to participate?

The nature of standards work requiresan opinion. What it doesn’t require
is for those opinions to be so tightly held that they can not be changed. People who are able to hold strong opinions loosely and debate constructively are good candidates for standards work.

One of the challenges we have is that the size of the group has grown substantially, and we have lots of people who fit that type but maybe not enough time to hear from them all on a given topic. During a meeting, we use a home grown tool Brian Terlson made to help queue questions on a given topic. So it helps keep people from talking over each other and interrupting.

We also make heavy use of GitHub for communication between meetings. There’s an internal reflector for meta notes, meeting planning and so on which stays pretty active year-round.

Come hear Jory's keynote, "Standardizing JavaScript" at jsMobileConf in Boston on October 25-26.