76. The W3C and Standardizing the Web

Chris: So, the W3C effectively enables the website that I load in Safari to also work in or lays the groundwork, I guess, let me know if this is correct, for the websites I load in Safari to also work the same in Firefox or Chrome or Brave or whatever browser we are using?

Tobie: Absolutely. So, the whole point of the standardization effort is to be able to build software using different technologies. So, different browsers are built differently and can actually render the same web page in the same way for the end user. So the standardization is the piece that makes it possible for me to build a website and you to see that website as I intended it to be perceived regardless of what browser you are using, what device you are on, et cetera.

Chris: Yeah. that makes sense. I remember back in the, maybe I'm dating myself, back in the '90s using the web, there were often these little logos or buttons on the bottom of a web-page that would be like, "Works best in Internet Explorer 4," or something like that. And now you don't see those.

Tobie: Right. So you always have this tension between wanting to provide new APIs to do new things on the browser, right?

Chris: Right, you always want to innovate, yeah. Create something new and better for the user.

Tobie: Right, which makes sense. And at the same time, if everyone does that with basically no consultation, no one actually talks to each other, then you end up with a very fragmented web which is what you had a long time ago, but we are seeing some of this again today. It is not uncommon now to see our software, sorry, websites, web applications that only work well in Chrome. You even see sometimes like, "Works best in Chrome," or comments of that nature on websites again. So, there is sort of tension between innovation on one hand and wanting to be able to share documents across lots of different browsers on the other. It is a tension that will never be resolved, right-

Chris: Yeah, okay.

Tobie: ... This is always something that as developers, we have to be careful about if we don't want to sort of run into the same kind of problems that we did when things were not standardized and Internet Explorer decided to stop innovating because it had won all the market shares-

Chris: Yeah.

Tobie: ... And we ended up in this really bad place for a number of years where there was no innovation on the web at all. It was-

Chris: Yeah.

Tobie: ... We were just waiting basically for Mozilla to come along and create competition again.

Chris: Personally, I'm actually just running into this right now on a project I'm working with using web push notifications. We have in this web application, a little message that comes up if you open it in Safari that says, "Hey, it doesn't work in Safari, you got to switch over to Chrome," or I think Firefox for the web push notifications to work in this demo application.

Tobie: Yep. It is not solved, will never be solved. Yeah.

Chris: But it seems nice though, that it is kind of the best of both worlds, we need innovation, I want innovation as a developer, but also as a web user, but then I also want at some point the good innovations or the best innovations to be standardized so that they can become normal and used by everyone, not just super technical people or people who are running Safari technology preview or one of the Chrome Canary additions.

Tobie: Yeah. So we are getting there. I mean, the browser vendors have put on a number of tools and processes and practices to make it easier to, for example, ship experimental APIs to a subset of their users that would sign up for that. So they you could actually test and iterate over the APIs, see if it fulfills the actual real need of the developers, but not ship it through the whole world at the same time. So then you don't have to sort of standardize it-

Chris: Yeah.

Tobie: ... Because that is the other aspect of the web that is interesting. The web is still on version one, right-

Chris: Yeah.

Tobie: ... There is no different versions like you have for even languages. I mean, PHP has different versions and you can't run something on five that also runs on three. Well, guess what, that is not true of for web, right?

Chris: Yeah.

Tobie: A website that was built two decades ago runs pretty much okay on the browser today.

Chris: Right, yeah.

Tobie: At least you can get to the content. Maybe you won't have all of the bells and whistles, but you can get to the content-

Chris: Yeah.

Tobie: ... So, there's this really strong ethos in the standard bodies that if something has been pushed in the web and is widely adopted, you can't take it out. So, that makes iterating over new APIs kind of a difficult thing to do.

Chris: And you need to say, I'm not just building this thing and throwing it out there, but I'm building this thing and we as a group agree that this is an important thing that will persist. And we are all going to agree to maintain its functionality-

Tobie: Exactly.

Chris: ... As a developer advocate I create fun demos all the time and I use the marquee tag as an HTML tag-

Tobie: Yeah.

Chris: ... In a demo. And I think it still works in most browsers, but when I went on the Mozilla developer network sites or pages to look at that, it explicitly says like, "Hey, the marquee tag is deprecated. That is not supported anymore in browsers." Even though it still does work, but that's one of the few examples of something being taken out. But like you said, for the most part, everything still works.

Tobie: It is a funny tangent actually, the marquee tag is now implemented, I think in the browsers that still support it as a CSS animation.

Chris: Oh, okay.

Tobie: So it's like they removed all of the code that actually did the marquee tag originally, right-

Chris: Yep.

Tobie: ... And it's now basically just a way to have a dev with a subset of CSS animations already built into it-

Chris: Yeah, yeah.

Tobie: ... Which is kind of funny, right?

Chris: Yeah. It's just fantastic sugar. Yeah.

Tobie: And to tell you to what length browser vendors and standards people will actually go to make sure that we don't break the web.

Chris: Yeah, totally. Well, so let's talk about the standardization process a little bit, at least in that, we kind of alluded to or you alluded to the fact that these are kind of very big and weighty decisions that are made to make what maybe seem trivial or small changes. So can you talk a little bit about the standardization process, I guess, and the weight and how most people think... Or maybe the lay person, maybe you are getting into development with things like, "Oh, we have bold as a CSS style or a font weight," changing that to something else seems trivial and small, like I could write code that does that pretty easily, but when you talk about bringing that into a standardization process and all the steps that have to happen and all the conversations that happen, it's much different than just like, "Oh, this trivial is small like change of a string." Talk about that process. What happens in a standardization process? How does it get kicked off or start not specifically for the W3C, but just generally for standards bodies?

Tobie: Right. So, the W3C works in a way that is actually fairly similar to how, for example, a large open source project would work at this point. So it's fairly different from what you can imagine from other standard bodies, which are more structured or have governments involved or the OSI or things like that-

Chris: Yeah.

Tobie: ... So it's still a very... I mean, the people that are doing the work are very technical. It is very technical work. So what generally happens is, either it is new tech that is being brought to a standardization working group that needs to be standardized, or it is old tech that exists in the browsers and that hasn't really ever been standardized and that we are still catching up to try to spec. So, it is kind of you have these two different scenarios. The other way that things could happen also is you have an idea, you bring it to a working group and you start specking out how you would want that idea to work. And then you bring the browser vendors and check wisdom if the suggestions you have make sense, and if they would be okay to implement it, given how it's been written down.

Chris: And then I assume there is probably also some convincing of them. Like if Google comes and says, "Hey, we want to add web push notification functionality so that a website can for good or bad pop up push notifications on my desktop browser," I assume you are going to want to get the people that build Safari and the people that build Firefox and other browsers to say, yes, we will support that also.

Tobie: Yeah. So there is an important factor you have to take into account, is for something to become a W3C recommendation, it has to have a least two different rendering engines. So basically two different browser engines that have a different code base have implemented successfully that specification. That is the point at which it becomes a recommendation. And the reason for that is you don't want to build a specification and recommend that specification for others, if it is actually not implementable and not interoperable. So the two things that you have to make sure when you write a spec is A, everyone reads the spec and understands what it says in the spec the same way and are able to build it on the architecture that they have. And then secondly, that when they do the outcome for the web developer is the same on both browsers.

Chris: Right. Yeah.

Tobie: Can it be implemented and is it interoperable? Those are the two questions. And if you answer yes, for these two questions, and you can answer that question only when you have two browsers that have done both, then at that time you can actually say that this is a recommendation. So, it's considered a finished standard to some degree.

Chris: Okay. Are there future states of this-

Tobie: No. That is the ultimate state.

Chris: Okay. Okay.

Tobie: In practice a number of groups today have adopted what are called living standards, where basically the process is a bit different. The standard is there to reflect the reality of the implementations-

Chris: Okay.

Tobie: ... And so nothing makes it into the standard that is not widely implemented. So it's kind of like they are constantly in recommendation status if you will-

Chris: Yeah.

Tobie: ... But they are getting modified.

Chris: It is interesting. My really only exposure to something similar to this has been through the TC39 process, which is really how JavaScript is, or ECMAScript maybe is the right way to call it and say it, is developed, or new features are added to that. And the stages they have, I think are proposal, draft, and then candidate and finished. It is interesting just to see how different organizations have needs for kind of different stages going through them-

Tobie: Right.

Chris: ... And obviously simpler is better, but some need more apparently to actually get something fully finished and kind of agreed upon by many different kind of competing parties.

Tobie: Yeah. TC39 is quite similar to W3C and WHATWG, which is another group that sits also in this space. So, they will have all of these different SDOs in that language/web development area, have sort of very similar processes. Sometimes they have different names for it, but in general, it is quite close-

Chris: Yeah.

Tobie: ... If you are working effectively with TC39, it will not take you a lot of time to work effectively with W3C, for example-

Chris: I got you. Yeah.

Tobie: ... It's quite similar. What is interesting that W3C and WHATWG have that others don't is there is a very important distinction between an organization that is standardizing a language versus an organization that is standardizing something that ends up sort of as-is in the hands of lay people. Because that makes a huge difference, consider that if you change something to the Java language, it will not make a difference at all to people using the web to buy goods, for example, or learn about the news, right-

Chris: Right, right.

Tobie: ... People that visit the web do not know what language is used behind it and nor do they care, nor does it matter to them. However, imagine suddenly if you standardized that paragraphs are shown the wrong way round, right?

Chris: Yeah, yeah.

Tobie: Or something like that. This directly affects end users.

Chris: Yeah.

Tobie: And as a result, the process at W3C and WHATWG includes that not only in using a framework to actually think about that, which is called the priority of constituencies, which basically says that whenever there is a disagreement about something, you will have to take into consideration first and foremost, how this will impact the end user. And once you do that, you will be able to consider how it impacts web developers-

Chris: Okay.

Tobie: ... And then once you do that, you will be able to consider how it impacts implementers of the spec, so browser vendors. And once you do that, you will be able to see how it impacts the editors actually writing the specs.

Chris: Okay.

Tobie: And only once you have done all of that, can you consider actual technical purity arguments.

Chris: Okay. Wow.

Tobie: So it has this really, really interesting framework, which actually I think is a really important framework that I would like to see more adoption of, or similar models for open source, because it really takes care of all of the different players and all of the different people that are impacted by the software and understands breadth of the impact. Because if you change something today and it impacts the way people consume the web, you are impacting billions of people. So, when you are actually writing a spec, you have to have that in mind-

Chris: Yeah.

Tobie: ... Because when you are talking about accessibility, for example, for billions of people, at the level of billions of people, people that have trouble accessing the web, for example, because they are legally blind or have eyesight issues or cognitive issues or lots of different issues, when you are talking about that scale, you are affecting millions of people. So, these decisions at that level are super important. And so that's why there's more process and more outside stakeholders involved in an organization like W3C than you will see in TC39, because at the end of the day, JavaScript affects people that are implementing JavaScript and no one else.

Chris: I like that hierarchy. It seems like it would make a lot of discussions about open source contributions, pull request discussions, for instance, new features, bug fixes, things like that. It seems like it would make the discussions simpler, almost automatic in many ways as opposed to like, "I think you should change your code to do this, or I think you should change the style of your... Use semicolons or don't use semicolons."

Tobie: Right. Absolutely. And yes, I think it's one of the most interesting, useful tools that have come out of W3C and WHATWG in the standardization process-

Chris: Yeah.

Tobie: ... And there was not one discussion when someone doesn't bring that tool up and say, "Well, okay. So, let's figure out who do we have to consider in this conversation. And how it impacts different people." And it really helps to make decisions.

Chris: So, I want to chat about the spec editing process and the tools-

Tobie: Absolutely.

Chris: ... These small, simple tools that you have created and maintain for that. But before we get there, I just wanted to make sure it is clear to people, there are two acronyms that we have been talking about, W3C, and WHATWG, can you say what the full name of those two things are?

Tobie: So, W3C stands for World Wide Web Consortium.

Chris: Okay.

Tobie: So, it's the three W's of World Wide Web and the C is for Consortium. And WHATWG stands for Web Hypertext Application Technology Working Group. There's a whole history between W3C and WHATWG that we will not get into-

Chris: Okay.

Tobie: ... But it's sort of there's been lots of disagreement and in-fighting over the years between essentially pragmatic factions and more theoretical purist factions. And we actually really recently arrived at some form of agreement between these two factions.

Chris: Yeah. It does feel esoteric and kind of like academic or theoretical and so I think a lot of developers depend on the W3C or the standards that these bodies have created, but very often don't know what happened in the sausage factory, what happened to produce these standards-

Tobie: Absolutely.

Chris: ... And it was not so simple. And so one of those steps is spec editing, it is creating a spec and then kind of iteratively and collaboratively editing that spec. Can you talk about that process a little bit, and then the application that you maintain to support that?

Tobie: So, the way specifications were designed a long time ago was basically using word documents. Sort of collaborating on word documents over a decade ago-

Chris: And then just emailing them?

Tobie: Yeah. And so bit by bit people started building dedicated tools to do spec editing. So there's a number of those that have been built over the years. I mean, you have to understand that a specification is essentially a really large document with a huge amount of text that is cross-referenced. Imagine you explain, how to do a marquee tag somewhere and that marquee tag, when you explain it and well, now it's pointing to how do you do a CSS animation and how you do this other thing. And so you start having this massive amount of cross-referencing all over the place, that you have to understand and track because let's say that you move a specification to a recommendation status. And it's based on a number of other specifications that are not ready at all, and where there's a ton of disagreement. You are not going to be able to move the one that you are working on to wide adoption, if it is standing on not solid ground.

Chris: Right. Yeah. There's this dependency tree, kind of.

Tobie: Exactly. So to sort of simplify this, people started building their own tools, essentially... They are essentially... At the end of the day, what it looks like is sort of markdown or some kind of weird markup, was a ton of tool to do cross-referencing of APIs, of protocols, of CSS properties, of all of the different kinds of things that you find in the spec world. And so I helped move a lot of this work to GitHub when GitHub started being a thing now close to a decade ago. And to start sort of using processes for building specs and WHATWG group did that independently on their side roughly the same time. To start editing specs on GitHub, rather than what was used before, which was SVN or CVS, CVS for real-

Chris: Yeah.

Tobie: ... So, really old versioning systems. And sort of really benefit from the same kind of culture that you find in open source development, where you have power requires, where you can make comments on those, where you can work on this thing together.

Chris: Yeah. Have conversations about a large body of text or even make comments on individual lines.

Tobie: Absolutely. Right. And I mean, a lot of specs is actually written in pseudo-code, you have algorithms that are just written in language, but the language has specified so clearly that you are close to being able to run it. It's really close to code, a lot of it-

Chris: Yeah.

Tobie: ... So this whole spec editing process, because of the way these tools are designed, it made it really difficult to sort of see what exactly was coming in. Either you would be working off of the built version of that tool and so it was basically a full blown up HTML documents with lots of tags all over the place. So, it was really hard to read. Or you were working off of the actual, underlying sort of marked down language-

Chris: Yeah.

Tobie: ... And you didn't have any sense of whether the connections were working properly and if things were actually the way you wanted them to be. And a number of years back, I started working for Google as the editor of the Web IDL spec. And the Web IDL spec is a specification that describes the language that is used to specify web APIs.

Chris: Okay, we are meta-

Tobie: Totally. And it does something really interesting and impressive. It defines JavaScript's bindings for that language. And so whenever you see in a specification, this weird thing that is describing what the API looks like, which is called Web IDL, the benefit of doing it that way is a browser vendor can basically copy paste that code into their code base and it generates all of the bindings from JavaScript to C++, or whatever underlying language they are using without having to write a single line of code. It creates all of the interfaces, it creates everything, but that language has to be the scribe. And you have no idea how complex that spec is and how hard it is. And I never started a project in my life where I felt so out of place and out of touch with what my role was and what it was supposed to do. It was really difficult, really scary-

Chris: Wow.

Tobie: ... And it was really complicated-

Chris: Yeah.

Tobie: ... Basically you had to have a super good understanding of everything that was in the ECMAScript spec, which is a huge document, super complicated. In order to be basically able to rewrite all of the dumb APIs or in terms of the underlying algorithms and definitions that were in the ECMAScript spec. So very difficult. It took me quite a while to get onboard to feel comfortable with it, but quickly in this process, I realized that whenever pull requests were coming from people that were contributing to it and that were more senior than I, knew the spec way better, I just literally had no idea what they were changing or how it related to the rest of the spec. I mean, the document is huge, I think it's 80,000 words-

Chris: Yeah. Yeah.

Tobie: ... So, I needed the tool to do that, to understand what fit and so I figured if I can actually find a way to build that spec automatically and have an update in the diff, an HTML diff-

Chris: Yeah.

Tobie: ... So I can just see, what does it change to the outcome? Not what does it change to the underlying source code, that would be extremely useful. And so I kind of looked whether I could build that and it turned out that there was a number of services that already existed. So, the editing software that was used, which was an open source project, had a service that existed for it. You could basically just send your source code via an HTTP request and get a build back. So that was the thing-

Chris: Okay. Yeah.

Tobie: ... W3C had a HTML diff that existed for some other project that was also a service. And I was like, "Wow, I can actually just build this thing really easily, basically relying on these different services." And so I was sort of, my coding itch was scratching and so I pulled some Node code together and over a couple of days, build sort of a prototype for this, shipped it and it was great. It would basically just very simple, do all of the work whenever there was a new pull request, it would just build everything in the back. And then just at the bottom of the pull request, it would add a link to the page that was done, the build version and do a diff of it. And that was tremendously useful and very quickly, everyone came to me and said, "Well, can I have this for my own spec, please?"

Chris: Okay.

Tobie: And this is when you get the sense of, oh, I have built something here that is useful for others.

Chris: Yeah. That's cool. And I think that's-

Tobie: Right?

Chris: ... Yeah, that is very often we all have the same problems probably more than I ever realized. And so it is fun to create little things that solve problems. And then you have this realization that like, "Oh my gosh, other people are similar to me. They have the same problem." Yeah, totally. I totally agree. I have kind of followed or gone on the same path as a tinkerer and software developer.

Tobie: Right. I think we all have.

Chris: So, how did you generalize or how did you then kind of make this personal tool usable by others, usable by people kind of in a way that didn't become your full time job, maintaining it, making it work? Because I think very often, that's actually the hurdle that I get stuck at is like, "Oh, I have created this little thing for myself that is helpful to automate something, but sharing it with other people requires kind of polishing some of the rough spots," maybe writing some documentation, maybe fixing the UI to be more intuitive. Yeah. So, what went into making it useful for others?

Tobie: So I think I was kind of lucky because there was a ton of constraints that I could not do much about and that really limited my ability to fall in the trap of polishing stuff for ages. The first one was, there was basically no UI. The only UI I had access to was I can either add a comment to the pull request or I can modify the body of the text of the pull request and add something at the bottom-

Chris: Yep.

Tobie: ... So that basically means your UI, the maximum you can do is a link.

Chris: Well, isn't the UI also kind of the rendered document and the diff?

Tobie: Yeah. Okay. That is a fair point. I did-

Chris: Or maybe that is an artifact. Yeah.

Tobie: ... I mean, I did write a small piece of JavaScript code that lets you sort of navigate through the diff, kind of easily from diff to diff, but it's not the best piece of software in the world, but does the job.But yeah, those were essentially artifacts of the build tools anyway, right?

Chris: Yeah. Right.

Tobie: So, the only thing that I did there is add a bit of a configuration that you could store on GitHub to configure how exactly you wanted your bill to be rounded for your specific spec. And so I was constrained by UI being, you can't do a lot in a few links at the bottom of a body of texts on GitHub. GitHub APIs doesn't let you do that much. I certainly didn't want to be in the business of maintaining a database also because it's not something I know how to do well. So what I wanted was something that was stateless like know UI and also something that I wouldn't have to maintain long term, and that was super, super simple. So that's why it was like a microservice architecture. And also because those microservices existed, those services existed. So it was just essentially writing glue code. The only thing I really added was an S3 instance to basically cache and host the outputs because my prototype had no caching. It would rerender every time-

Chris: Okay, okay.

Tobie: ... So that was kind of costly.

Chris: Yeah, yeah. Okay.

Tobie: So, S3 caching and that was frankly trivial to set up on the S3 front except for the permissions, which I'm not going to get into that-

Chris: Yeah.

Tobie: ... But for me the key point and I'm not saying that because I'm actually on the podcast, that is a Heroku Salesforce podcast-

Chris: Yeah.

Tobie: ... To me, the key was Heroku actually made the whole maintenance set up of that thing, sort of a fire and forget thing. I have moved on from spec editing for what? Three, four years at this point-

Chris: Okay.

Tobie: ... And these apps still run and still power pretty much all of the spec editing that is happening in those standard bodies.

Chris: Oh, wow.

Tobie: So this is something that people have been asking for, for example, right?

Chris: Right. And so there's two tools, right? There's Specref and there's PR Preview.

Tobie: That's right.

Chris: Can you just briefly explain what is kind of the small, simple problem or the small, simple thing that each one does?

Tobie: Yeah, absolutely. So, Specref is basically in memory database that is built from JSON files that stores all of the references to other specs and other standards-

Chris: Okay.

Tobie: ... So, I don't even know how many it has, probably 30,000 or something like that. 30,000 I think.

Chris: It says 45,416 references and counting right now on specref.org.

Tobie: Oh, wow. So, see, there are more than I thought they were because a lot of it is automated. It actually pulls the data from different data sources, different standard bodies and sort of mashes them into a single JSON format that is used by every spec in the web field to reference other specs. So if you see at the bottom of a spec references to other standards, it's using that tool-

Chris: Okay.

Tobie: ... And it is used also elsewhere for testing purposes. If you want to connect a task to a spec, it is also relying on that database. So it is really focused on that. And then PR Preview is really the tool that basically builds the spec from your pull request. And does a diff against master of your repository and compares them.

Chris: Yeah. I get you.

Tobie: What I really like about them, yeah, it is the fire and forget and that they were really built was all very little resources in line and not wanting to make things complicated and wanting to make things sustainable and maintainable in the long term. Which is why you have these really weird sort of this architectural choices, like the in memory database. I mean, I knew that the standards would not grow to more than 100 to 200k. I looked at how big of a memory footprint that was, I looked at what Heroku was offering in terms of memory footprint for apps-

Chris: Right, yeah.

Tobie: It was just like, "Oh, I can hold." I can't remember what the number was, but like a million or the number of entries that could hold in memory was massively bigger than what we would ever have. And so that was an easy choice. It just build some from JSON files every time it reloads, so once a day, I think. And that works, it's super fast as a result. There're no connection problems. You can't overload the database. I mean, so many problems just disappear.

Chris: Yeah, I agree. I start building apps I'm like, "Okay, time to add a database."

Tobie: Right.

Chris: And it's like, "Okay, now there is this whole another layer of complexity that I have added in." I mean, in general, just managing state is-

Tobie: Exactly.

Chris: ... A complex thing. Yeah.

Tobie: And the cool thing is I'm basically using that JSON file and GitHub as a CRUD for... And I don't need to handle... There were 40, 50 contributors to the repository-

Chris: Yep.

Tobie: ... And they just add stuff, right?

Chris: Yep.

Tobie: ... And they also use the scheduler to run a script every hour that basically goes and fetch the latest spec from ISO, W3C, WHATWG, ECMA, all of them at this point-

Chris: IETF.

Tobie: ... Yeah. There is a bunch of them. I think C++ uses it for its Spackle. So, it has all of their issues in there. And so there's really, a lot of references in that database and it is done hourly and again, it works.

Chris: Yeah. Great. So this is all really cool Tobie, do you have anything else, maybe some parting words that you would like to share with software developers maybe interested in standards, bodies or things like that, the process of building software or building specs for software developers before finish up?

Tobie: Yeah. So I think if I could leave you with two parting thought. One would be around software development. One of the things that I really learnt and loved about building these really tiny tools is really using basic tools and actually engineering the right solution to the specific problems that you are facing, rather than relying on a huge framework that you have to learn and then use in a particular way and sort of rely on all of this, sometimes cruft that is not necessarily adapted to the precise thing that you are trying to do.

Chris: Yes.

Tobie: So for me that was a huge lesson. It's actually a lesson that I learned in part at Facebook when I was an engineer there, because it's a company that was really, really focused on cutting through the chase and finding the right solution for the job and not bothering with industry best practices or things like that, but really what is the solution that you need, build that. So, I'm glad I could put it in practice for these at last. The other thing is we have talked a lot about standard bodies. I remember when I was a developer, they felt like ivory towers, far away, unreachable, complex-

Chris: I agree with that.

Tobie: ... And sometimes frankly, they are and that is a failing on our part that people that are actually writing those specs and doing that work, but what you have to understand is as weird as it sounds, when you look at all of the corporations that are involved with those, these organizations are critically understaffed and the number of people that actually understand the complexity of the web platform and are able to effectively contribute as editors of specs are tiny, tiny. The bus factor of all of this is really, really, really big, right?

Chris: Yeah.

Tobie: And so a lot of the time people would love to have more help, would love to get more input from developers and they just have little time to actually do that. So now that a lot of the work has moved to GitHub, part of the point of doing that was to make it more accessible to developers-

Chris: Yeah, it makes sense.

Tobie: ... So if you want to get involved, sort of figuring out what specs actually touch on the things that you know and care about in the web and seeing the activity that is going on in those specs and making comments or opening issues there, I think that is an effective way to gently start tiptoeing into it, but what shocked though, because that is kind of how I started a long time ago and at some point I ended up editing a spec about speculating, as I said before. So it is a rabbit hole.

Chris: Yeah. It can get deep, you can get sucked in and I'm sure when someone within the organizations notices your interests, they are like, "Oh, I want to bring this person in and help us and increase our capacity."

Tobie: Yeah. Absolutely.

Chris: So, that's cool. Thanks Tobie for joining us. I really appreciate it. I learned a ton here, so appreciate you sharing a little bit of your wisdom here with us.

Tobie: Well, thank you so much. It was a pleasure being here. Thank you so much for having me.