Revised Patterns for Participation in Standards Committees
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…
Be an active listener. Allen’s guidance was to speak up only if you are sure you have something valuable to say, and I wholly agree that it’s time well spent for a newcomer to focus on listening and observing during one’s first meetings. However, I think it’s worth revising this guideline to convey that it’s absolutely, 100% ok to ask questions and get clarification if there’s something you don’t understand (at the appropriate time, of course). In order to ask questions, you have to really listen to what’s being said — both technically and contextually, and this is a great way to get a real feel for the group, too.
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 explicit about your objective. If you’re trying to get a new feature implemented, come prepared with the clearly defined problem you’re trying to solve and any pertinent use cases. If your solution is well-formed enough, write the tests for it, too. Remember that, depending on where the language is in its lifecycle, real problems are going to be far more compelling than theoretical ones. As Allen notes, “Development of a language standard is not a green-field development activity… A language standards committee exists to solve problems that arise from the current state of the language.” So if your objective is to evolve a language a certain way — so it can be implemented on the blockchain, say — you’ll have to be patient! Conversely, if you’ve met your goals, it’s ok to move on to other things. Be purposeful.
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.