How to Win Friends and Influence Standards Bodies


Published on

# How to Make Friends and Influence Standards Bodies

The greatest strength of the web is its openness. But not everyone appreciates how we arrived at the open web of today. A recent trend has cast standards bodies as bureaucracies that never accomplish anything of substance, while the heroic community innovates and implements “from scratch.”

Reality is much less black-and-white: sandboxes like Node.js have received much from the web platform and language that spawned them, and have a lot to contribute back. Standards bodies are composed of implementers and community members willing to engage, not ivory tower philosophers handing down bad, never-tested APIs from on high. And real gains could be made for both sides—with some effort.

This talk is part stories, and part lessons; it’s meant both to teach, and to open the floodgates for collaboration. You’ll hear about ways in which community input has had great impact on the standards process for the better, as in the case of web audio or adding promises to ES6. But you’ll also be taught communication and coalition-building skills that, from what I see, are sorely needed by many community members. How can you get involved and shape the future of the web and JavaScript platforms in a direction that will help everyone? Who are the key players and processes that they follow?

Finally, together we’ll brainstorm on and identify some key areas where your expertise and hard-learned lessons could help the web platform toward future solutions for problems it’s encountered.

Published in: Technology, Design
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Consider: somehow, we've managed to create a system where you canboot up your computer,connect to any other arbitrary computer,download executable code onto your machine,and run that executable code in a safe, sandboxed way that you are sure will never harm your computer.You can run anything from document readers to trading systems to hardware-accelerated 3D games,and they will work no matter what CPU architecture or form factor your device uses.
  • I’m referring, of course, to the web.I’d say this is a feat way up there with few others in human history. In fact, the one accomplishment that I would compare this to most, is the moon landing.
  • This picture represents the culmination of many, many hours of work as a species. As does, I claim, the last one.Consider what it took to build the web platform we work on today.The amount of cooperation between disparate parties;the bedrock that had to be laid down first;the giants whose shoulders we stood on, to get to this point.Consider the people whose entire job is to build these systems, so that on top of them we can achieve our goals. We call those people “standards bodies.”And yet…
  • People don’t seem to appreciate this accomplishment.Worse, their antagonism seems to be based on some serious misunderstandings of what exactly standards bodies are, and what they do.I’ve spent the last year diving into their world, and I’m back here to report.To really understand the genesis of the modern web platform, and of the standards bodies behind it, we have to go back…
  • To 2004, to be precise.Think back to 2004, and what the web was like back then. Something new was all the rage. Does anyone remember what it was? Anyone?
  • It was XML.From 1999, when HTML 4 was finalized, through 2004, the W3C had been pushing XML everywhere.XHTML, SVG, SMIL, XForms, XLink, MathML, and XML Events were our future.But there was concern that these weren’t actually solving any problems…
  • Ian Hickson, of OP-erah software, in 1994.
  • All this came to a head at this W3C workshop in San Jose.Mozilla and OP-erahjointly proposed a set of design principles, and requested a vote whether the W3C should extend HTML and the DOM to support web applications.It was defeated, 8 yes to 14 no.
  • Realizing that the W3C had lost its way, Mozilla, OP-erah, and Apple formed the Web Hypertext Application Technology Working Group, or the WHATWG.The WHATWG is open to anyone, and is composed largely of implementers and other concerned individuals working to make the web a better place for web applications.This is where the majority of web standards work is done today. It’s done in the open, over IRC and on public mailing lists, with increasing movement toward GitHub. The people who write standards are the same as the ones who implement them. And the process is open to anyone.
  • This is a major misconception some people seem to have.That talk last year made it really clear that the speaker didn’t actually understand what standards bodies were in the modern web era.His example of something better than standards bodies was how the source map spec was created: via a Google Doc shared between a few people at each browser vendor. Guess what… that’s exactly how standards bodies work!From Hannah’s talk earlier: “The decisions are made by people who show up; the code is written by people who write code.” Same thing with specs; same thing with the web platform!
  • More generally, how it works is that the web community, or perhaps the implementers on behalf of the web community, identify a problem:A missing piece of functionality in the platform;Something that’s harder than it should be;Something that is not interoperable across browsers;something like that.They then convince implementers that this is a real, high-priority problem. This is important, because if the implementers don’t care, nothing’s going to get done! If you write a bunch of specs that the browser vendors think are irrelevant, they’ll ignore you, and we have 2004 all over again.Then they try to come up with a solution to the problem, debating aspects of it and nailing it down in spec language.
  • This is the part that can feel like it drags on. Why haven’t we just specced the damn <picture> element already?The process is there for a reason, namelyMaking sure the problem in question is actually solved, and that all browser vendors are on board with a solution, is criticalThe work that needs to be done is in proportion to the level of fidelity required by an interoperable spec; it’s not just gratuitous.This goes back to our moon landing parallel: it’s not easy to make something that can be implemented across the entire platform!Getting general agreement, and in particular consensus from browser vendors, means getting a lot of people to agree.But the concerns people raise are mostly useful input into the process.If you’re building things for just one platform, say Node, and you don’t need interoperability, you can just make dictatorial decisions and commit them to master.But if you want something to work on the entire web, you need to get buy-in from the people that make the web work. That’s why we have standards bodies.
  • One innovation in the standards process that I want to highlight is the idea of a living standard.The easiest way to think about this is to first consider the model that came before. HTML1, HTML2, HTML3, HTML4… it’s not like browsers actually implemented four separate versions of HTML. Instead, they just implemented HTML, as of the latest draft, but also with some extensions and modifications for compatibility or to give their users new features.The idea is to bring this process to the standards themselves. They should be continually updated as feedback comes in, new features are agreed upon, or bugs in old features are discovered. There’s no point in producing outdated, versioned snapshots, brought down from Standards Mountain to remain forever locked into obsolescence as browsers quickly pass them by.This has been a large success, giving us the HTML Living Standard instead of HTML. Pieces of this are starting to make its way into the Ecma TC39 standards process for JavaScript, although for language design the number of interlocking features makes it harder.
  • So, we have this process, which sounds… surprisingly reasonable. And I say it’s open to anyone.How does that work? Can I just show up on the mailing list and IRC, and start writing specs?Well, largely yes! But … I’d like to give you some tips first, from my dive this last year into these standards bodies. Hard-won knowledge from the trenches, as it were.
  • 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;how annoying it is to read super-long messagesand 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 is it solution time.
  • You're working within the web platform, so any solution must respect the existing platform.This can range fromits security model,to the fact that APIs are exposed in JavaScript,to the idea that we do not want to introduce data races by APIs that require multithreading.Example: Node.js streams, “I don’t like objects having prototypes and constructors.”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.
  • The single best technique for actually getting things done is to find like-minded people to work together with.You want a number of people to work through a solution together, anticipating objections and working through them.Ideally your coalition should include at least one implementer, or at the very least one expert in the field who writes specs all the time.When it’s time to propose your idea to a larger group, it’ll help to not be the lone voice arguing against apathy, or against opposition.
  • A lot of dumb things are proposed. Or things that are suboptimal. Or even just bikeshed colors you don’t like.But you only have a limited amount of political and social capital. You don’t want to be seen as excessively argumentative; people will just flip the “bozo bit” on you, and ignore your future arguments and contributions.Save your energy for things that really matter. The web might not get 100% perfect APIs---perfect according to you, of course---and that needs to be OK. Introducing a constant stream of negativity into the process when these come along just makes it impossible for you to be taken seriously when you do have legitimate concerns.
  • 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.Example: we’ve settled on IndexedDB as our database solution; saying that it’s a crap API (which it is) and trying to bully people into throwing it out and building a new API is not productive.Another example: on es-discuss right now, one guy has actually started two parallel threads where he is retreading the consensus on arrow functions and on default parameters. He clearly hasn’t read any of the meeting notes or previous threads on the subject, yet feels entitled to have people hear his opinion on how these features should work (which is different from how they’re specced to work). Don’t be that guy.
  • (WHATWG channel topic)APIs that seem odd, illogical or poorly designed often make a lot more sense when you have an understanding oftheir historical context or of the applicable design constraints:portability,backwards compatibility,conformance to other related standards,considerations for how browsers are implemented,etc.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.
  • I talked more about this at my JSConf EU talk. If you can get a working implementation of your proposal up and running and used by many developers, you’ll be in a stronger position to say that it’s a good solution.Examples of this in the past include Sizzle for querySelector, jQuery in general for some newer DOM APIs, SASS for CSS hierarchy, Promises/A+ for promises, and Angular for custom elements
  • The best part of conferences is the ability to get to know the people you know only from the internet. This makes everything better; you get a sense of who these people are, and gain sympathy with them. Arguments evaporate. Coalitions are born. Understandings are reached.People who watched Mikeal’s talk last year from afar felt offended that he was saying “fuck them.” Whereas on the afterparty boat, I was able to have a deep conversation where we really understood each others’ perspectives.If you can make it out to a TC39 meeting, or a conference where one of the relevant spec writers are presenting, or even just offer to buy them lunch---admittedly easier if you live in San Francisco---you’ll get some great advantages.This is two sided. We need to seek out implementers and spec writers, but they also need to come to our conferences; but then, we should invite them. I’m investigating this. In the meantime, do what you can, because this makes a big difference.
  • Various promise implementers, Promises/A+, to the DOM, to ES6.This is my favorite example, because it exemplifies a lot of those tactics.In fact I gave a whole talk about the process we went through in Promises/A+ at JSConf US.But I’ll just call out how we made the last step, to get promises into ES6, whereas previously they were planned for the DOM and then ES7.I took three days vacation, got on a bus down to Boston, and sat and listened and participated in the September TC39 meeting, finally presenting the spec our coalition had built on the third day. Everything went right, and it was accepted.
  • W3C TAG, the governing architectural body, was doing a review of the web audio API. One developer, Janessa Det, who’d worked with web audio and presented a couple related conference talks, was able to give her feedback, which was added to the TAGs to dramatically improve the API surface.
  • James Greene
  • Rick Waldron
  • Myself and Yehuda Katz, intermediating for many others who were … less tactful
  • Continue this great enterprise
  • How to Win Friends and Influence Standards Bodies

    1. 1. how to win friends and influence standards bodies
    2. 2. “Fuck these guys”
    3. 3. 2004
    4. 4. <2004/>
    5. 5. “The W3C had so far failed to address a need in the web community: there is no language for web applications.”
    6. 6. W3C Workshop on Web Applications and Compound Documents
    7. 7. implementers + interested community members = standards bodies
    8. 8. standards; how do they work?
    9. 9. solutions are hard
    10. 10. living standards
    11. 11. getting involved
    12. 12. lurk first
    13. 13. solution time is later
    14. 14. understand the constraints
    15. 15. build small coalitions
    16. 16. pick your battles
    17. 17. concede defeat; don’t retread
    18. 18. leave your sense of logic at the door (objects in rear-view mirror are more complicated than they appear)
    19. 19. prolyfill
    20. 20. be present
    21. 21. success stories
    22. 22. promises
    23. 23. web audio feedback via the TAG
    24. 24. adding the error to window.onerror
    25. 25. new es6 built-in methods
    26. 26. es6 module improvements
    27. 27. what’s next
    28. 28. streams
    29. 29. packaged apps
    30. 30. es7
    31. 31. #extendthewebforward