Skip to content

Instantly share code, notes, and snippets.

@domenic
Last active Sep 11, 2016
Embed
What would you like to do?
Tips for getting involved in the standards process

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 domenic@domenicdenicola.com, and they'll hopefully make it into my presentation.

The Tips

Lurk First

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).

Solution Time is Later

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.)

Understand the Constraints

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.

Concede Defeat, and Don't Retread

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.

Leave Your Sense of Logic at the Door

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)

@kriskowal
Copy link

kriskowal commented Oct 2, 2013

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.

@kriskowal
Copy link

kriskowal commented Oct 2, 2013

I talked a bit about the criteria for a valuable standard in my jsconf.eu talk in 2010

@allenwb
Copy link

allenwb commented Oct 2, 2013

"Pick your battles" You position won't always prevail. Don't expend all of your political/social capital on things that really aren't all that important to you.

@sideshowbarker
Copy link

sideshowbarker commented Oct 2, 2013

Maybe there's stuff in http://www.w3.org/TR/html-design-principles/ you could mine. e.g.,

Avoid Needless Complexity

In proposing solutions to problems and in discussing solutions proposed by other peoples, favor simple solutions over complex ones. Simpler solutions are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand.

Focus on Solving Real Problems

In proposing solutions to problems and in discussing solutions proposed by other peoples, favor pragmatic solutions to problems that web content faces today, rather than abstract architectures that don't address any actual existing need.

@junov
Copy link

junov commented Oct 2, 2013

The title "Leave Your Sense of Logic at the Door" is a bit too cynical me thinks. The reality is that things actually are logical when you have the full picture.

I would chose to express this point something like this:
Objects in rear-view mirror are more complicated than they appear. APIs that seem odd, illogical or poorly designed often make a lot more sense when you have an understanding of their historical context and/or of the applicable design constraints, such as portability, backwards compatibility, conformance to other related standards, considerations for how browsers are implemented, etc.

@kriskowal
Copy link

kriskowal commented Oct 2, 2013

Agreeing with @junov, you probably mean “leave your indignation at the door”.

@jviereck
Copy link

jviereck commented Oct 2, 2013

This was partially already mentioned:

"Focus on Solving Real Problems" << That's a tip I was told as well: Start with "what is the use case you try to solve?" kind of question. Once you have answered it, outline a possible solution (if you have one) without going into too much details. Try to keep your email short and get to the point. Don't waist your time (and the one of others) writing a long email that gets rejected because of trivial thing (e.g. the idea was brought up before and got rejected).

@waxdoll
Copy link

waxdoll commented Aug 5, 2016

Agree with @kriskowal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment