Revised Patterns for Participation in Standards Committees

Jory Burson
Aug 13, 2018 · 6 min read
Image for post
Image for post
Image from Annual report of the Bureau of ethnology to the secretary of the Smithsonian Institution (1881)

I recently reread Allen Wirfs-Brock’s paper, Programming Language Standardization: Patterns for Participation, while preparing for an upcoming talk. Allen’s 20+ years of experience in language standards development, research and documentation is extremely valuable to the JavaScript community and can’t be understated. The paper is an academic approach to guidelines and patterns for those getting started in standards work; in order to make it a bit more actionable and modernize the language for our community, I’ve updated his guidelines below, along with some helpful tips to improve your standards-committee experience.

The nature of technical standards committees is such that users, implementers, and vendors are in the same room, often with conflicting needs or interests. Alex Russell does a fantastic job illustrating these tensions in web driven standards organizations in his two part series, Effective Standards Work. It’s important to remember that ultimately we’re all trying to “ship the right thing” — the challenge lies in gaining consensus about what that “right thing” is, and doing so in an inclusive and respectful way. These guidelines are about encouraging social activities that facilitate a professional (and personally rewarding) standards development process.

Seek First to Understand…

Do your research. This applies not only to specific proposals and ideas you may be interested in putting forward, but also to the organizations, individuals, and history of the group as a whole. Sometimes, this is easier said than done — documentation can be hard to find in a reflector or email group, or the people with real knowledge about something may have moved on. Ecma TC39 (and most all of the W3C working groups) have put a lot of this context online via GitHub, and are working to surface more organizational history for the community. If you stumble into an area where the history is not known, this could be a great opportunity to make a meaningful contribution by filling in the gap.

Meet your team. Allen advises “understanding the other players,” but I prefer to think of it as meeting and getting to know the rest of your new team. All technologies are products of their social environments, so the better you understand that social environment and can contribute positively to it, the more you help your cause. If you don’t know anyone else in the group, send and email and introduce yourself; share what brings you to the table. Invite someone to lunch or coffee. Attend or organize after-meeting events with your new peers. Get to know where they are coming from and what issues are most important to them. It’s easier to forge these connections in person — I highly recommend investing in a trip to attend one or more meetings a year if you can swing it.

…Then Be Understood

Be Open to Change. Standards work, despite its reputation, is not about competitive arguing (I like to say that TC39 is not about “competitive JavaScripting”). Any two people in the group may solve the same problem different ways, but that doesn’t automatically make one of them wrong. In strategizing ways to get your feature implemented, Allen recommends “Finding Allies,” Picking your Battles,” and having a “Back-Pocket Alternative.” Working with others to develop ideas enriches your understanding of the problem and language, and helps you develop a sensitivity to what issues other organizations will care about (and thus might impact your proposal’s chances of success). This also helps you avoid arguments and debates that don’t matter in the given context. Another important strategy: being open to being wrong, and being willing to say as much. After all, “Most ideas and designs aren’t good, and most of the ones we eventually accept don’t start good.”¹ Fostering an environment wherein it is safe to propose, discuss, advance or withdraw ideas is essential for healthy technical dialogue — which requires all parties be willing to change their minds.

Be a Contributor. Both Allen and Alex share that, historically, the older the group, the harder it is for new people and ideas to enter that group. Fortunately, there’s a definite culture shift within these groups to open up to new ideas and ways of working.

There are a lot of ways to start contributing to a standards effort that don’t involve writing technical proposals. In fact, this is often the most important and underserved area!

How you contribute to a standards effort should ultimately be a factor of your strengths, objectives, and the needs of the group. Here are some ways to be a great contributor and boost your credibility without writing new proposals:

  • Volunteer to take notes at meetings.
  • Organize or co-organize social events.
  • Help with meeting planning.
  • Contribute to other committee efforts, like writing documentation.
  • Read proposals and provide critical feedback or use cases for them.
  • Help edit or champion other proposals, or write tests for features or proposals.
  • Help identify “prior art” and/or missing voices — are there examples that can be pulled, or people who can be consulted to help move something forward?

Strive to Consensus. Most web standards committees use a consensus model for decision-making, and how consensus is measured can vary from group to group, but it generally means that a supermajority² of the group supports the decision and the remainder is willing to accept the decision. Disagreement and debate is OK, and needed, but it must be professional and respectful. At some point as a delegate, you’ll have to decide if you should actively oppose a decision, but this should be a rare occurrence. Not every proposal will make it into the final specification — in fact, most won’t, and that’s a good thing.

The guidelines above apply whether you’re brand-new to standards development and looking to find your footing, or you’re an existing participant and want to increase the success of your current efforts. Any organization, committee or team operating a joint open source software project could benefit from these guidelines directly or with modifications to make it more appropriate for your team. Happy standards-making!

¹ Alex Russell in “Threading the Needle
² The definition of supermajority varies by organization. It usually requires two-thirds or more of votes cast to pass an issue.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store