This gist is meant to help me compile "tips" for getting involved in the standards process. It will be used as a source of material for a talk I'm giving at LXJS in a couple days. The tips are meant to be somewhat tactical, i.e. provide concrete advice for first-timers, and not general sweeping statements about how standards bodies work in the abstract.
If you have any additional tips, please leave them in a comment or email them to me at [email protected], and they'll hopefully make it into my presentation.
As with all new communities you're joining, you'll get better results if you lurk first, both in IRC and on the relevant mailing lists. You'll get to know who's active in what area; what kind of topics are on the group's radar; which issues are contentious; and even basic stuff like how to write emails (prefer plain text, never top-quote).
Don't bust onto the mailing list, multi-page spec in hand, telling us about this amazing new API that we really should add to the standard. Instead, outline the problem you have. You need to get agreement that this is a problem, and that it cannot be solved with existing technology, and that implementers are interested in solving it. Only then it is solution time.
(Derived from advice from the WHATWG FAQ.)
You're working within the web platform, so any solution must respect the existing platform. This can range from its security model, to the fact that APIs are exposed in JavaScript, to the idea that we do not want to introduce data races via multithreading primitives.
As an example, some people recently have been doing some great work reimagining streams in the Node.js space. But when I tried to help them flesh out their proposal into something that we could bring into the browser, they said "No, I don't like objects having to have prototypes and constructors; we should just use object literals for streams." This just doesn't work. Our APIs in JavaScript and on the web, regardless of your personal preferences, are going to use a constructor with a prototype. We're not going to give our APIs multiple-personality disorder just to satisfy your style of writing code; for better or for worse, the standard library has a way of working that you need to be able to work within if you want to contribute to it. It's like coding style: I hate comma-first, but if I'm contributing to a project which uses it, I'm not going to insist that my pull request be comma-last.
If a decision has been made, and all the implementers are on board, it's very unlikely you're going to come up with a super-brilliant argument that dissuades them. Instead, you'll just waste everyone's time as they patiently explain to you arguments that have already been made, and why the decision we've arrived at is the prevalent practice. Save your energy for battling new bad ideas.
Example: ES6 and the web platform have settled on promises as their async primitive, after years of stumbling through horrible async APIs with onerror, onsuccess, onresult, whatever. This is great! Now we need to build on this bedrock. Insisting that your async APIs should be Node.js-style callbacks is not going to be helpful; you're re-treading a battle that was already fought, and just not contributing productively.
The web platform sucks, and everyone knows it. It has tons of historical warts, which we can't fix because the web depends on it. Don't blame us for DOM0, or with, or defaultValue vs. value! In general, don't blame us for the existence of sucky APIs. We can't remove them, and we have to integrate with them. The only thing we can do is move away from them when adding new features.
The web had a deeply confused childhood, derived from multiple competing browser vendors doing whatever they pleased, and others copying them, including their bugs. We're in a better place now, but we still have to build on top of the existing platform; we can't start over.
(Derived from the WHATWG IRC channel topic)
The first and foremost valuable lesson from my experience herding the CommonJS modules specification, and from reading† on the topics of persuasion, philosophy, and even just basic friendship: summarize.
Always follow up on feedback first with a summary of all the feedback you have received so far. Take the time to understand how this feedback makes sense in the mind of your interlocutors before attempting to summarize. If you can’t understand, refrain from commenting—ask earnest questions until you understand.
Focus first on what is already universally agreed upon. This will help prevent retreading old, dead issues. More often than not, you will find yourself in “violent agreement” with the group, allies circling like snarling wolves.
Then break the group into camps. Identify pools of consensus. Everyone should know where everyone else stands on points of disagreement, and have an opportunity to note whether they have been understood and when they have changed their minds and allegiances.
Then, analyze each of the schools of thought. Look for logical inconsistencies and incoherence. If there are “bugs” in the school of thought, point them out and ask the supporters whether they are convinced that there is an inconsistency. They will either respond by reformulating, convince you that they are in fact consistent, or switch camps.
At some point, the only remaining camps will be coherent, mutually exclusive in some way, and ultimately boil down to a difference in values. This is where the long pause happens, and usually results either in a schism or compromise. Which outcome is better depends on the circumstances, but schisms and compromise are usually better than stagnation. Multiple branches of exploration are sometimes better than dogmatic solidarity to a common cause.
When it comes down to a value judgement, call a vote. Strive for unanimity before moving on.
In this process you will have opportunities to identify stake-holders. Respect these people and their votes. Welcome them, regardless of their level of experience. There will always be valuable feedback, and in an open setting, a lot of people will weigh in their opinions, and some of those opinions will be founded on knowledge or experience that you need to pay attention to, but the stake holders drive consensus and you should focus on tracking where they stand and breaking rifts.
The one factor that determines the pace of innovation is how quickly everyone can teach and learn, and then take the lessons to their communities.
Passion is important. No effort at standardization or consensus will or should survive without it. If you are not passionate about bringing people onto the same page, they may not belong on the same page. But with passion comes certain perils. At some point, you will take something personally. You will probably fail to recognize when this happens. You will probably forget everything you know about non-violent communication when this happens. You will make a mistake. The damage will be infectious. At this point, you cannot do anything to regain control of the situation. You may have to withdraw from the conversation to control the damage.
So, invert the control. If someone in your community makes a social mistake and starts taking things personally, use the formula! In public: summarize what they believe and tell them you understand their point of view. In private, tell them you understand how they feel and that you do not take their actions personally. If you respect their opinion, knowledge, experience, or just their enthusiasm and potential (and you probably should), they might be able to return to the conversation productively.
† Bertrand Russel talks about arguing with alternative schools of thought in this way, “On the Value of Skepticism”. Several books on relationships emphasize the point, and in particular, @izs recently recommended “Nonviolent Communication” by Rosenberg.