• Revised Patterns for Participation in Standards Committees
• Jory Burson
• The Nuggets translation Project
• Permanent link to this article: github.com/xitu/gold-m…
• Translator: Luo Zhu
• Proofreader: KimYangOfCat, QQ1120637483

Image from bureau of Ethnology annual report submitted to the Secretary of the Smithsonian Institution (1881)

I recently reread Alan Wilfors Brock’s paper on standardization and Participation patterns in programming languages while preparing for the upcoming lecture. Allen has over 20 years of experience in programming language standards development, research, and documentation, which is extremely valuable to the JavaScript community and cannot be underestimated. This paper provides academic guidelines and models for those starting out in standards development; To make it more actionable and to provide modern language for our community, I have updated his guidelines below, along with some useful suggestions for improving your experience with standards committees.

The nature of technical standards committees is such that users, implementers and suppliers are all crammed into the same room, often with conflicting needs or interests. These tensions in a web-driven standards organization are well illustrated by Alex Russell in his series on effective Standards Working. It’s important for us to understand that at the end of the day everyone is trying to do the right thing — the challenge is to reach a consensus on what is the right thing to do and to do it in an inclusive and respectful way. These guidelines are about encouraging social activity and promoting professional (and personal) rewards in the standard setting process.

First seek to understand…

Be an active listener: Allen’s guide is to speak only when you’re sure you have something valuable to say. I totally agree that for a new person, the first meeting should focus on listening and observing. However, I think there needs to be a revision of this guideline so that if you don’t understand something, you can definitely ask questions and get an explanation (in due course). In order to ask questions, you have to really listen to what the other person is saying — both technically and contextually, which is also a great way to get into the group quickly.

Do your research: This applies not only to specific suggestions and ideas you might be interested in coming forward, but also to the organization, person, and history of the group as a whole. But sometimes knowing is easier than doing, feedback or documentation in an email can be hard to find, or the person who really knows something may have moved on. Ecma TC39 (and most W3C working groups) have put a lot of background material online through GitHub, and are working to present more of the organization’s history to the community. If you stumble upon a field whose history is unknown, this could be a good opportunity for you to make a meaningful contribution by filling in the gaps.

Get to know your team: Alan suggests getting to know other players, but I prefer to think of it as getting to know and get to know other people on your new team. All technology is a product of its social environment, so the more you understand that social environment and can make positive contributions to it, the better it will help your business. If you don’t know anyone else in the group, please send an email introducing yourself and sharing your thoughts. Invite a group member to a barbecue or starbucks. Attend or organize after-party activities with your new partner. Learn where they are coming from and which issues are most important to them. It’s easier to make these connections in person — I strongly recommend attending one or more meetings a year if you can.

. And be understood

Define your goals: If you want to implement a new feature, be prepared with a specific problem you want to solve and any associated use cases. If your solution is in good enough form, remember to write tests for it as well. Keep in mind that depending on where a language is in its life cycle, practical issues are more powerful than theoretical ones.

As Allen points out, “Language standard-setting is not a greenfield development activity…… The language Standards committee exists to solve problems arising from the current state of the language. So if your goal is to develop a language in some way — say, so that it can be done on a blockchain — you have to be patient. On the other hand, if you’ve achieved your goal, move on to something else. Be purposeful.

In software development, a greenfield project may be the development of a new system in a completely new environment, with no need to worry about integration with other systems, especially Legacy systems. What the author means here is that the formulation of language standards is burdened by history.

Be open to change: Standards work, despite its reputation, is not an argument about competition (I like to say that TC39 is not about “competitive JavaScripting”). Any two people in a group can solve the same problem in different ways, but it doesn’t automatically decide which one is right. When devising strategies to get your features implemented, Allen suggests finding Allies, choosing your battles and having a plan B. Collaborating with others to share ideas can improve your understanding of issues and language, and help you develop sensitivity to other organizations’ concerns (which may affect the chances of success of your proposal). This also helps you avoid arguments and debates that aren’t important in a particular context. Another important strategy: be open to your mistakes and be willing to speak up. After all, most ideas and designs are bad, and most of the ideas and designs we end up accepting are bad to begin with. 1 Creating an environment where ideas can be presented, discussed, advanced or withdrawn safely is critical to a healthy technology dialogue — it requires all parties to be willing to change their minds.

Be a contributor: Both Alan and Alex agree that, historically, the older the group, the harder it is for new people and new ideas to get in. Fortunately, among these groups, there is a definite cultural shift towards openness to new ideas and ways of working.

There are many ways to start contributing to standards work without having to write a technical proposal. In fact, this is often the most important and underserved area!

How you contribute to a standard effort should ultimately be a factor in your strengths, goals, and needs of the group. Here are some ways to become a great contributor and increase your credibility without having to write a new proposal.

• Meeting notes record volunteers.
• Organize or co-organize social activities.
• Help plan meetings.
• Contribute to other work of the committee, such as preparation of documentation.
• Read the proposal and provide key feedback or use cases.
• Help edit or support other proposals, or write tests for features and proposals.
• Help identify existing technologies and voices that are being ignored — are there examples to draw on, or someone to consult, to help move something forward?

Strive for consensus: Most WEB standards committees use a consensus model for decision-making. How consensus is measured varies from panel to panel, but generally means that a majority of the panel supports the decision and the rest are willing to accept it. Disagreement and debate are ok and needed, but they must be professional and respectful. At some point, as a representative, you have to decide whether you should actively oppose a decision, but that should be a rare situation. Not every proposal will make it into the final specification — in fact, most will not, which is a good thing.

The above principles apply whether you are a new standards-setting participant and want to find your footing, or if you are an existing participant and want to increase the success rate of your current work. Any organization, committee, or team running a joint open source software project can benefit directly from these guidelines, or modify them to better suit your team. Our goal is to have fun setting standards!

• 1: Alex Russell’s thread
• 2: Most definitions vary from organization to organization. It usually requires two-thirds or more votes to pass an issue.

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.