Brian Kardell: Okay. Hi, I'm Brian Kardell. I'm a developer advocate at Igalia.
Eric Meyer: And I'm Eric Meyer. I'm also a developer advocate at Igalia and would like to introduce two guests today. Guests, please introduce yourselves.
Will Bamberg: Hi, I'm Will Bamberg, I'm a technical writer and I work for an organization called Open Web Docs.
Estelle Weyl: Hi, my name's Estelle Weyl, I'm also a technical writer and a front-end engineer, and I also work at Open Web Docs.
Brian Kardell: Wow, what a coincidence. We got two guests from the same organization?
Eric Meyer: Yeah, weird. Actually, they're here today, of course, to talk about Open Web Docs, which some of our listeners may have heard of. We've certainly mentioned it on the podcast before. But yeah, we wanted to get more into what Open Web Docs is, and where it came from, and all that sort of thing, so let me just start with that. What is Open Web Docs?
Brian Kardell: And why is Open Web Docs?
Eric Meyer: Well, we're getting to that.
Estelle Weyl: I'll start with what is. We are a collective of technical writers of all former engineers that document the web platform. As the web is the biggest tech platform there is, it needs to be well documented, and that's what we do.
Eric Meyer: What would you say Open Docs is, Will?
Will Bamberg: I have multiple answers to this, unfortunately. But yeah, one is obviously what Estelle said. And in terms of the actual work that we do, a lot of that comes through writing, and reviewing, and maintaining web documentation on MDN and also for BCD, Browser Compact Data.
Eric Meyer: I was going to say, MDN and BCD standing for...
Will Bamberg: Well, MDN doesn't actually stand for anything anymore technically, but developer.mozilla.org. It uses down for Mozilla Developer Network, but whatever. Yeah, but I kind of think Open Web Docs is also a sort of a vehicle for safeguarding web documentation for making sure that the long-term health of web documentation is taken care of, and there are people who are going to continue to look after it, and maintain it, and extend it. And it's not just going to stop being looked after one day because somebody decided they couldn't afford to do it anymore. So that's another piece of it, I think. And I think another piece of it is that it's a sort of hub for different organizations you have an interest in there being good web documentation can collaborate and work together to advance these goals. So that includes web standards organizations, that includes browser developers, and it includes web developers, and it includes tech writers. And so we're at our best, I think. We're an organization that helps to bring those places together.
Eric Meyer: Okay. So you said Open Web Docs primarily works on MDN and BCD, which is what runs the compatibility tables at the bottom of all the MDN pages, right?
Estelle Weyl: And can I use.
Eric Meyer: But Open Web Docs is not actually part of Mozilla.
Estelle Weyl: We are a completely browser-agnostic, corporate-agnostic, open collective. So we are funded by a lot of organizations, both tech companies, and individuals, and governments, but we aren't wedded to any of them. So we don't write documentation for any specific organization, we write about all the specifications. Well, not all the specifications. There's more than 500 specifications. We write about a lot of them, but we basically make sure that every feature we know about is well documented. Even like browsers will write documentation when they release a new feature and then it might not be updated because it's no longer the focus of anyone's attention. Our collective basically looks through all the old documentation all the time, and when we see something, it's not like, 'Oh, this is not our priority.' Our priority is making sure that everything is up-to-date. So even if it's a feature that isn't on anyone's radar, if it gets on our radar, we'll update it and make sure that it's modern up to date and non-erroneous. We're very pedantic.
Eric Meyer: Being pedantic is probably an asset. Brian said, why is Open Web Docs, and that's a relevant question, why does Open Web Docs exist? Why does it have to exist?
Will Bamberg: Well, I think to represent the interests of a lot of different organizations, I suppose. So if you look at MDN, contributors to MDN include people who are employed by Mozilla to contribute to MDN, people who are employed by Google to contribute to MDN, Open Web Docs staff, people who are employed by the W3C and volunteers. And all those people are contributors to MDN and also maintainers of MDN as well. They get to review other people's PRs and collaborate on this shared project. So I think there's always an interest, for example, in browser developers to have good up-to-date documentation for the features they're just shipping now. And they're usually quite well set up to do that. So for example, like Mozilla when Firefox ships a new feature, they flag the features, a thing that needs docs and MDN, and that goes through to a team of people that's employed by Mozilla to maintain those docs and MDN. A similar thing happens with Google Chrome as well. And so feature that ship in new browsers, there's typically some kind of process associated with those browsers to update the docs. And that usually works quite well, but there's a lot of documentation that's not associated with that, and there's features that slip through the cracks or docs that become out of date or don't reflect current practices, and there's not really anybody to come and say that this stuff needs to be updated as well. And I think a lot of that stuff is what we take care of.
Eric Meyer: One of the questions I wanted to ask is how did each of you get started with Open Web Docs, and when was that, and what keeps you still there?
Will Bamberg: Well, I worked at Mozilla on MDN for a long time. The first attempt Mozilla made to get rid of the old XUL add-on stuff was an add-on SDK. And I started working at Mozilla to document that thing. And then I stayed at Mozilla after Mozilla decided they didn't want to do that anymore and they did web extensions instead, which was a kind of clone of the Chrome APIs for extensions. And that was the one that eventually took, and then I started working on MDN through that. So I have got a lot of history with MDN and web documentation, and when Mozilla laid off the Docs team in 2020, I was one of the people let go. And that was one of the things that were probably, I suppose the thing that caused Open Web Docs to be formed as an independent entity because there was a recognition that it was important to safeguard, well, web documentation to make sure that it wasn't just... You weren't going to wake up one day and find there was nobody being paid to document the web.
Eric Meyer: Which is basically what happened, right? So it was like, 'Well, MDN's still there, and people can still submit pull requests or whatever, but who's actually in charge?'
Will Bamberg: Right. And another piece of conversation that happened then I think was that the idea that really you have to pay people to maintain stuff. There's a lot of volunteers that do a lot of incredible work, but ultimately technical writing is a profession. You need professionals to do it, which means people need to be paid to do it, otherwise it's not going to happen in a reliable way. So anyway, so I actually went to work for the Matrix Foundation on the Matrix Foundation. And they're great. They're great people. But I sort of missed MDN because MDN is this platform that reaches so many people, and it's such a privilege to be able to do that, to be able to reach many people in Docs, and I couldn't really get free of it in that sense. And in the meantime, Open Web Docs had got set up and the first employee was Florian. And so after a little while of working on Matrix, Florian came and said, 'Do you want to come work on Open Web Docs?' And I said, 'Sure,' so that was how it happened for me.
Eric Meyer: And by Florian, you mean...
Will Bamberg: Florian Schultz, who's our beloved director.
Estelle Weyl: And founder.
Will Bamberg: And founder.
Eric Meyer: Yeah. Okay, Estelle, how about you?
Estelle Weyl: So I started writing web documentation back in 2007, I think, or 2006. And one of my first well-visited blog posts was the Firebug tutorial. So Firebug was the first dev tool for a browser. And when you went to firebug.org or whatever their site was, the tutorial on how to use Firebug actually linked to my blog. I had already gotten started writing documentation, but that definitely gave me a kick in the pants that it was just pure popularity. I didn't get paid for any of it, but I did also do BCD type stuff. I would test everything in browsers, so quirks mode, which is done PPK, and my blog would have browser features and browser support. So I just had tables and tables and tables of every feature that I would write about, I would test in every single browser. And none of that was automated. So I'm so glad that BCD Collector exists. I stopped doing it many years ago. But anyhow, I was working as a front end engineer, but kept documenting the web, and then I got a contract to work for MDN, so I was a contractor on MDN from 2018 to 2020. After that contract ended, I went back to being a front end engineer for William Sonoma as a contractor. I was their front end architect for CSS. The entire time I was there, I was learning about what people didn't know and how much stuff people didn't know. So when I heard about the fact that MDN, mostly Open Web Docs, was looking for a technical writer to work on MDN, I was like, 'Yay, I have all these examples.' I had been writing documents for two years or a year-and-a-half, and I was like, 'I really have all this other documentation that I really want to write, but I can't spend all my time writing documentation because I need to pay my mortgage,' so it was really fantastic. I applied for the job, got it, and have been there now for over three-and-a-half years, which I did note today. One thing that's really interesting is this is an open source collective where we are paid. It's a real job. And this is the longest job that I've had in tech, because when I worked at Yahoo, they had layoff0.s and I was in one of those rounds when I worked at a company called Instruct Logic, they went under. And before that, they had a layoff round. When I worked at Topspin, they had layoffs. So all of these tech companies that are funded by round A, round B, round Z, they have rounds of layoffs, and so you're changing people. But here, I think the work that we do is vital and we are actually able to keep our jobs so far for three-and-a-half. And in the case of Florian and Will, they're already at four years.
Brian Kardell: That's the risk with tying these things to private enterprise. You think that they'll always be around maybe even the ones that are long like... I don't know. I think that most people would have guessed that Microsoft would still make a web engine right now.
Will Bamberg: Right.
Brian Kardell: If you'd asked 15 years ago, if you'd asked 20 years ago, people would probably think that Opera would still be making an engine, I don't know. I remember one of the first things when I got into the web, I bought some Fortune 500 consultant's book about the web, and getting involved, and doing things with... who's going to control the future, and it was like foregone conclusion. Netscape, it's not even, 'Bill Gates lost, what a fool.' Now they're trying this desperate thing to develop an internet browser, but it's terrible, and they'll never get anywhere with that. I'm really floored that we have a separate entity whose job is like, 'We have the stated goal of supporting the documentation of the web. That is our goal.' Yeah, I think it's super. I was an advocate for creating it and I just went and looked up our announcement was from the same day as the official announcement announcing Open Web Docs January 25th, 2021. And Igalia, we are a small company compared to Google or Microsoft or whatever, but we've been a financial supporter since the beginning.
Will Bamberg: Yep.
Brian Kardell: Yeah, I'm really pleased that it was not even controversial, I can tell you. But everybody said yes, and then the next year everybody said yes again, and now it's just a part of our annual sponsorship.
Will Bamberg: I think we really appreciate it.
Estelle Weyl: Thank you.
Will Bamberg: The money and also just the support and recognition I think, which I think we feel from Igalia and our other support as well. Obviously the money is really important, but the recognition is important too.
Eric Meyer: So I'm curious, what are some cool things you've gotten to do while at Open Web Docs?
Estelle Weyl: I'm going to start with the part that's less interesting but more needed. I'm working on a project. There was a lot of documents that were missed over the years. So I'm not sure who exactly created it. I think it was the WebDX group created the Missing Baseline. It looks at the BCD, the browser compatibility data and checks to see what documents are missing from MDN.
Eric Meyer: 'Oh, so it looks in BCD and if it doesn't have an MDN URL as a reference-
Will Bamberg: Yeah.
Eric Meyer: ... you can get a list of all of those? Okay.
Estelle Weyl: Yes. So I went through all of the documents that were missing that were widely supported, which meant that all the browsers had been using them for over two years and recruited a volunteer to help out, and we wrote all the documents so all that missing documentation was documented. The second project was the new features that are in all browsers. So I went through at the end of February, found everything that was supported in all browsers that was missing documentation, wrote all those. The third part is the ones that got supported in March, and so far in April, I've not tackled those yet. So there's about 40. They're all ARIA element, HML element or HTML element internals, ARIA features, so I created a list of those that need to be documented, but that is an upcoming project.
Eric Meyer: That's pretty cool to have looked at, 'Here are all the things that nobody has ever written, these web platform features that exist and are supported, and in some cases have been supported for a very long time, but nobody ever actually wrote the documentation. Let's write the documentation.' That's the kind of thing that I would imagine would be a hard sell in an in-house group, right?
Estelle Weyl: Yes.
Eric Meyer: 'Well, I don't want to write about the really cool new stuff. I want to write about the stuff that we've supported for 10 years, but nobody ever got around to writing.' I can easily see someone saying, 'No, that's not going to make line go up. No.' But you have the ability to do that. That's awesome.
Estelle Weyl: It is. That's exactly it. Because we're not working on KPIs for some marketing model, we can attack what really is missing but doesn't bring in the revenue. And the fun thing is I learned some stuff because there were a lot of SVG features. So I learned a lot about these attributes and therefore the interfaces and the properties of the SVG APIs because what I also like to do is whenever I have a feature is create an example. So in the documents that we create, we try to always create an entry level example. So sometimes they're not real world. We do try to do real world, but sometimes if you ever needed to use this, you'd have a 2,000-line application. So let me just show you how you change a color with this feature. I'm not going to show you the entire feature, but here's this page that does show you this entire feature. That feature is included on this page. Here's the two lines that we used and the quick effect that this does. So that was not the most exciting, but it definitely made it so that there's way fewer broken links on MDN. So on MDN, if there's a link that's broken if a documentation doesn't exist and it should exist, the link is read with the squiggly underline, and the second you create the documentation, it turns blue with a solid underline. So it's not just a color that shows the differentiation. So exciting stuff that I get to do is I'm really into CSS. And I have been going through every single CSS specification and creating a module landing page. So most of them have module landing pages. So a spec we call a module, because it's not just a spec, because a feature might have level three, four, and five, so we call it module because it encompasses three, four, and five. So I've been able to go through the specifications and create module pages, create examples, and rework the guides or create new guides if guides are missing. One other thing we do, and that I love doing, though it can be frustrating, is reviewing PRs. So browser vendors will have a new feature and they will document it and we review it. OWD team reviews the PRs to make sure that everything is covered, that it's accurate, but also having been a web developer for so many years and also having taught web development and worked with new people in web development, I always take the perspective of either junior or mid-level or advanced developer depending on what the topic is. But I get to review these new features from that perspective, so I deep dive into these features like there's no tomorrow. Learn them inside and out and get to make sure that the documentation and the guides really are able to provide the information that a junior, mid-level, or senior front-end engineer would need to implement that feature. So I know everything there is to know now about anchor positioning and CSS carousels because I got to review those specs, so that's the funnest part of my job, but also the most frustrating because you know you want to get that PR out as soon as possible, but you know that you want it to be as accurate, as deep, and as pedantic as possible. So it's really hard to do, and it takes a lot of effort. Sometimes it feels like you're putting as much effort reviewing a PR as it might have taken to write it, because the last PR that I reviewed, I definitely spent a full 40 hours reviewing it and creating examples to help guide the original author to make a storyline that is easier for a mid-level engineer to fully implement. So there's the boring stuff that you feel really excited about because doing something that needs to be done, and then there's the hard, mentally most difficult parts because it's learning new stuff. That is my favorite part of the job. And then there's the CSS modules, which is just basically a reviewer crash course for me every single week when I get to do that, knowing that I'm helping people and fully understand what's going on, and basically being the liaison between the spec authors and the developers. And Eric and I wrote the book together and I wanted to subtitle it. We read the specifications so you don't have to. And that's really what I feel like I'm doing every day.
Eric Meyer: Well, what about you?
Will Bamberg: I guess I could talk about a couple of things. One is not actually documentation writing project as such as infrastructure. And this was a few years ago when I led a project to convert the source format for MDN from HTML into Markdown, which might seem boring, I don't know. Maybe it does. But not to me. So in the old days, MDN was a wiki. And people usually edited it using a WYSIWYG editor where you could type something that looked like kind of formatted text, and then it converted into something kind of like HTML, which is stored in a database. And you could also look at the raw HTML, which you quite often had to because the WYSIWYG editor had quirks and stuff. But in the back end of the database, it was all just HTML. And sometimes people would do things like paste stuff out of a document into the editor as HTML. It would have all this kind of extra cruft that the other document had in as formatting, which would then be in the HTML. So the HTML was soupy and that was how it was. And then in 2020, MDN moved to the content into GitHub, into Git repo. And so you just edited the HTML directly. And this kind of exposed this soupy HTML to everybody. And that was what everybody just had to use to write documentation on it, and it was bad. So we had a project to start using something else as a source format, and the something else was Markdown for reasons that I think were good reasons. But because Markdown is limited, Markdown doesn't support a whole lot of things you can do in HTML, you have to decide what to do with all these different things. So we had a project in which I would go and find all of the instances of particular HTML elements in the MDN source, and then we decide what to do with them. And the options would include, stop doing that thing, just don't use that bit of HTML anymore, or they'd be use raw HTML because you can always embed HTML inside Markdown that works, but it means then you have to edit HTML, which isn't very nice for people. Or you'd invent new bits of Markdown and extend Markdown in your own nefarious ways, which is usually the kind of last resort, but it's sometimes something you have to do. And what I liked about the project was the way we did it, mostly. So every time we had one of these choices to make, we'd do it all explicitly. So I'd file an issue, and I'd say, 'Here's this thing. We use description lists a lot in MDN. These are not supported in GitHub-flavored Markdown. What are we going to do about this?' And I'd say, 'Here are the main options we can have. If we want to extend it, here are some possible syntaxes we could use to extend it with,' and we'd have a super open discussion about it. And we invite a collaboration from Mozilla, and from the W3C, and all of the maintainers and volunteer community. And it felt like a really good process. And really often, we'd end up with something which I hadn't anticipated, which was better than any of the suggestions I'd made. And it also meant that by the time we got to a decision, we were pretty sure that most of the maintainers, who are the people who were actually going to have to work with the stuff were at least moderately satisfied with whatever we chose. So I guess it's proved the things we built then was a pretty solid foundation. And we're four years on from that now, just about. And it still seems like a solid foundation to have. And I think this also relates to stuff we said before about long-term health. This, for me, was a foundational thing that I wanted it to go on working for years and years in the future. And at the time we did it, it's like we're putting a lot of work into this project and nobody sees any difference. End user don't see any difference of this because this is all internal stuff. But for me, it was important that we had a foundation that the maintainers and the volunteer contributors could build on. So that was a good project.
Estelle Weyl: As a maintainer, I can definitely appreciate the fact that it's so much easier to maintain because it's easier to read and easier to write. And we don't have to argue about whether someone used the right element for something. We do have discussions about heading levels, and that's actually automated at this point. There's a bot that tells you that you aren't nesting correctly, but it saves so much discussion and so much time from the maintainer and from the writing perspective. So thank you very much for initiating that project.
Will Bamberg: Well, like I say, what I liked best about it was the actual process of how we reached consensus on these questions. What I've been doing lately, which I've enjoyed a lot, is working on web security documentation. So we ran a survey probably more than a year ago now about how web developers feel about web security and web security documentation, and it turns out they didn't feel good about it. And one of the things that developers found it hard to understand what kinds of security threats they were facing, and they found it hard to understand the documentation or to find documentation about it. And one of the things that came out of that was a community group called Delightfully SWAG, the Security Web Applications Guidelines, I think. And the purpose of that group is to develop guidelines for web developers about web security practices. And it's been great for me because I get to talk to people who are web security experts who have a vested interest in having better docs for this stuff. And so I get a lot of feedback on what kinds of things we can improve and what kinds of guidance we should be giving web developers. I guess, as I said before, I think sometimes Open Web Docs at its best is like a hub where we can connect up different people. And I think this is a thing that's been working really well in SWAG. So I've been working a lot with the Google security team who understand their problems with things like CSP adoption. And so we talk about how can we make this better for people? How can we make the docs better? How can we have better guidance? And also, actually the Mozilla security team as well for things like cross-site leaks where there's a lot to say, and there's not a lot of clear documentation about it. So it's been really interesting for me working in that group.
Eric Meyer: Any other groups you've been interested in working with of late?
Estelle Weyl: We work with WebDX and we are working on starting a new community group called the Docs Community Group. It doesn't have as good a name as SWAG, so maybe we should come up with something else. Do you want to talk about that a little bit, Will?
Will Bamberg: Yeah, like Estelle said, as well as SWAG, we've been working with a community group, WebDX, which I haven't been so much involved with. Florian has a lot, and they've been working a lot on baseline and browser compat, and this question of how do you represent groups of web platform features, I think, and how do you make slightly higher-level statements about support so you're not making the most granular statement possible about support, but you can talk about higher-level feature support. And so we've been involved in that. Florian's been involved with WebDX and has, again, found it a great forum for getting input from specification authors and browser developers.
Estelle Weyl: The great thing about the WebDX, I've been involved not as heavily as Florian is, it's basically a place where all the different browser vendors can come together and agree on something. So they actually got together and agreed on baseline. So they came together and basically said, 'How are we going to say something is usable by everyone? How are you going to say it's a new feature? How are you going to say it's an experimental feature?' So that's something that I know we've been talking about for years on MDN, which is when do you add the experimental feature and when do you remove it? Well, all the browser vendors got together within this WebDX umbrella, the DX standing for Developer Experience, because it's really important that the specification authors, the browser vendors, and the developers are all communicating in a language that all three groups understand.
Will Bamberg: And so I think partly as a result of our generally positive experiences with things like SWAG and WebDX, we've made a proposal for a community group in the W3C, which is about web documentation in general. And part of the idea of that is that it's this place where specification authors in particular, and browser engineers, and web developers can come and meet technical writers, not necessarily Open Web Docs technical writers, but we are going to be represented there. And Florian is one of the co-chairs of the group. And we hope it's going to be a place where we can collaborate and decide what sorts of projects need our attention and we can get feedback guidance on the work that we do.
Estelle Weyl: Part of the goal is to get the different specification authors, and technical writers, and browser vendors together to talk about documenting the web platform. So WebDX is more about the browser vendors and developer experience, but everything needs to be documented, and so this group would be more focused on documentation. That way if there's a new specification that comes out and they don't have documentation, hopefully they will have heard of this group. Obviously not yet because we haven't really been founded yet, we're just starting it now. But they could come to that group and say, 'Hey, can I get help documenting this?' Or technical writers can come, and they say, 'I've documented these feature, but I don't know...' I have all sorts of questions. Well, hopefully the spec authors will be there, or at least someone who knows the spec author for that particular spec and they can say, 'Hey, let me put you in contact.' So basically a Yenta, a matchmaker for spec authors, and technical writers, and browser vendors. And another idea for it is kind of like a documentation help desk, which is, if someone has a problem with their documentation or a problem explaining something that they can actually come to the group and get help from a technical writer to make it sound good. But also as technical writers, we have a lot of experience with the information architecture of a documentation site, and not that many people have that. So if someone can't afford a full-time technical writer, like any spec group can't afford a full-time technical writer, they just they could at least have a group of technical writers to bounce their ideas off of. So helping guide people who ask for guidance is another goal.
Brian Kardell: I am curious about how do you decide. This is a difficult thing reasonable people will disagree on. What is the thing that you should focus on? So do you just have a lot of freedom to focus? Do you get together and plan together? Do you draw straws somehow? How do you decide? When do you... Estelle mentioned some things about baseline, but things get documented before their baseline. When do you start expending efforts? If you get a single implementation, do you add it? Two, do you add it if it gets to CR in W3C sense? Yeah, when-
Estelle Weyl: We definitely do not wait until it gets to CR. So it gets... Generally a browser vendor, when they release a new feature, it's very proud of their new feature and wants to document it. So Google has a contract technical writer that writes documentation on new features being released in their browsers. Mozilla has technical writers that write documentation on new features that are released in Firefox. Microsoft, we worked with them on a progressive web app section of MDN because that's a bunch of features put together, all the features pretty well-supported. But as a technology, because it uses JavaScript, HTML, and CSS and iconography didn't fit neatly so we worked with them to do that. But in terms of new documentation, so we do not document anything that doesn't have any browser support, and we will actually remove features if there are no browsers that support them, because sometimes in the past, things have gotten in that didn't have browser support. When it only has one browser support, there's a little macro that says experimental, which basically puts a little thing at the top that says, 'Experimental. Check the browser compatibility data.' And then you now also have baseline at the top that shows a color and check marks or Xs, depending on whether the browser supports it. So browser vendors will usually implement right documentation if they're releasing something and they're proud of it. Our job is actually to review that and make sure that it's not vendor-specific, that documentation, because that documentation is unlikely to be revisited because there's so much documentation. I think there's over 11,000 pages on MDN as an example. It's unlikely. So if the browser vendor starts the guide with, 'Historically this happened and now we have new features that do this,' I'll be like, Let's get rid of the old and new language and just what would we be saying a year from now?
Will Bamberg: I think you also asked, Brian, about... Good question there. How do you choose what projects to work on? How do I decide I'm going to be working on security for the next few months, whatever, or how does Estelle decide what project she's going to take on? So we have a getter repository in which people can file proposals. So if somebody thinks something should be documented, they can file a proposal there and there's a kind of template you can fill out in which you say why you think it matters among other things. And we will consider those proposals. We also have a steering committee, which consists of people who fund us, but also people who don't fund us who are good sources of requirements, including people like representatives from the W3C and some kind of independent representatives who we expect are going to be helpful to us in finding useful things for us to do, and the steering committee can propose, and to some extent, is expected to propose projects for us to work on. I feel like this has not been working as well as it was. We have experimented with slightly more formal ways of doing this in which people in the steering committee get votes. And there are proposals that get made and then people vote and whoever gets the most votes, whichever proposals get the most votes are things which we decide to work on. We don't do that anymore. And I think the engagement we've had with the steering committee is not as good as it used to be. And I think in a lot of ways, the documentation community group, the W3C group is an attempt to improve the situation. I think one thing about the steering committee is it became... Although it is, it's not a closed group, I think it sort of became like a closed group, and it was not obvious to people that they could participate in it and I hope, and I think that the DOC-CG will be better for that. It'll be better at making connections to other organizations. And that's really our hope. It's a source of requirements for us. Because it's obviously important to us that we work on the right things and things that are important right?
Estelle Weyl: Being a subgroup of Open Web Docs, which is not necessarily the best-known group in the world, being a subgroup of the not-fairly-well-known group meant that we don't have as much input as we would like. But being a subgroup of the W3C, a working group of the W3C, that will just basically make many people aware. They might not be aware that we're focused right now mostly on doing documentation for MDN, but it will basically make people much more aware and hopefully we'll get much more input as to not necessarily being told what to work on, but coming, realizing what needs to be worked on. All three of us are former engineers. I still consider myself an engineer, a front-end engineer. So I have a sense that I'm connected to the community, knowing what areas are lacking in terms of documentation. But definitely the more voices we have, especially of people at the frontlines of specification writing and at the frontlines of developing for the web will provide us much better guidance. So we're looking forward to getting more input and hopefully more volunteers.
Brian Kardell: How do they do that?
Estelle Weyl: So let me give a few GitHub links. If you want to submit a project that you want Open Web Docs to work on, you would go to our GitHub page, which again is github.com/openwebdocs/projects, because that is the name of the repository. Actually, it's Project Singular. And then in the issue section, you can submit an issue. And when you submit a new issue, it says, 'OWD project proposal.' You can also get to the OWD project proposal from our website. But if you're a GitHub user, just go to Open Web Docs and realize that project is the name of the repo of interest to you. If you find an issue on MDN, there's a few different ways you can report it. If it's a general issue, you can go to GitHub. All of the content on MDN itself is in the content repo. If it's a BCD issue, it's in the BCD repo, Browser Compat Data issue. But the best or the simplest way, because it's not necessarily easy, is to go down to the bottom of any page, and there's a little box on that page and it says, 'View the page on GitHub.' And so you can view the page on ClickHub and click on issue right above the browser compatibility table, there's also a link directly to that browser compat issue. So on every single page that has a browser compatibility data table, you can click right above the table to file an issue with that, or you can directly edit or file an issue from that grid or that box at the bottom of the content of every content page.
Brian Kardell: I was just curious, my memory of when you wanted to learn about what was supported in the late '90s, you would go to the Netscape site. If you were looking in the early 2000s, maybe you were looking at a site that Microsoft had that had maintained by Microsoft people, and then at some point we had this Mozilla one that was MDN, and then I'm just curious, do you all remember somewhere around 2012/2014, there was move in the W3C web platform docs?
Will Bamberg: Yes, I remember that.
Estelle Weyl: Yes.
Will Bamberg: Yep.
Brian Kardell: It had a colorful W logo that was-
Will Bamberg: It was beautiful.
Brian Kardell: ... tiny logo, I thought. But I remember people like Microsoft donated a bunch of documentation from their suite, and the idea was like, 'Let's just get it not associated with a browser and put it in a neutral place.' And I think maybe part of the idea was, if we put it to W3C, maybe W3C will also have people work on it. It's curious to me, I remember being at TPAC and talking to somebody, maybe it was James Graham, I'm not sure, but I was saying, 'Why does Mozilla seem to want to not do that?' There's not a big push to do that. There's sort of these two things. And also, why is there not money separately for this? Everybody pays dues to W3C? Why couldn't part of that money be to do something like this, to sponsor the one place and the one infrastructure that hosts it all? And I'm just curious, here we are a lot of years later, and it seems like we have gotten to something more close to that. And even at the AC meetings last week, I was talking to a lot of people about we should do more collective funding in W3C. And I actually held up Open Web Docs as what I think is a successful case because it's like we do have a lot of collective funding. There are an independent group of people who do this and... Yeah, I don't know. I was just wondering if you had any thoughts on how we got here or where it should go, if there's also maybe lessons for outside of Open Web Docs and other spaces like, I don't know, web platform tests and there's lots of other things that are also-
Will Bamberg: It sounds like there are two separate pieces in the question. It sounds to me anyway like one is about funding and one is about platform. So one question is, why didn't webplatform.org work? It's a separate independent docs platform. And the other is, why isn't there funding for people to write docs that's independent to any one organization, which is what Open Web Docs is really? So I guess what I'd say is that in terms of the first question, the reason is that people trust particular platforms and you can build a new one, but not guarantee anybody will go there. So I think there's a lot of inertia, but also trust in particular platforms that's built up over a long time. And so I think that's just a fact. But it's still important that funding exists for people to maintain documentation for its own sake and not as part of the outreach associated with, for example, a web browser.
Eric Meyer: So sort of splitting it out of developer relations and just making it its own thing.
Will Bamberg: And one thing that happened, I think, in MDN and Mozilla in that kind of decade really from webplatform.org almost really... And even before that is that MDN kind of really gradually morphed from being something that was just, Mozilla Firefox Docs into being something that was Open Web Docs. It was like web platform documentation. And that was a slow but very definite move that happened over those years. And I mean various things, so those are the time when Microsoft shut down MSDN and redirected all their traffic to MDN, and that was a big deal. And part of that, I think... That only became possible because Microsoft were reassured reasonably enough that MDN was not just a Mozilla property, it documented the web. And for that to be true, I think you do need to have this kind of... You need to have a certain amount of open governance about it, I think, right?
Estelle Weyl: Right. And I think webplatform.org, which was the W3C version, I believe it was Doug Shepard's and Lea Varue that were on that team. But that shows the difficulty of starting something from scratch and getting buy-in when there's something already bigger out there. You couldn't expect Mozilla to give all the documents over to something smaller.
Brian Kardell: Definitely. Even in those conversations, I remember whoever I was talking to saying, 'Well, you don't realize how hard it has been even to get people to go to MDN instead of W3Schools because W3Schools, very early, became the place that people were going, even though a lot of the information was not good. It became the place.' And then there was all this inertia where they come up first on search results and it takes a lot of time to move that needle with PageRank and everything anyway.
Estelle Weyl: And I think W3Schools kind of tells us what the problem is with AI. I'm not saying that they are AI, I'm not actually equating the two at all, but people knew about W3Schools and they linked to it, and so it got higher and higher and higher. Whereas MDN... W3Schools is this closed environment that has certain writers. I don't know much about it, but if they have a mistake, I don't know how you go about correcting it. I certainly can't go in and correct it. Whereas MDN, anyone in the community can make an edit, and it is reviewed by the maintainers, so hopefully only correct information gets in. But 99.9% of the information that gets in is correct. And then if a mistake gets in, someone will correct it very quickly. That's not what happens with W3Schools or any closed environment. But because there are so many links, it still comes up first. And if something is inaccurate there or on Stack Overflow or on anything that AI is scraping, that is the result you're going to get. So it's really important to have a source of documentation that is done by AI as in actual individuals, which is the only good kind of AI, because every time I've asked, I'll ask AI a question, I already know the answer, but I'll ask a question. A technical question has never gotten it correct. And the thing is, I'm asking it pretty advanced stuff usually because writing on this new topic and there isn't that much on it, but 100% of the time it has been inaccurate. So it's really important that we have the web platform documented by actual individuals that research and confirm that everything is accurate. So it's so needed. And it's important that everything is documented, not just the stuff that is important to browser vendors at this time, but all the stuff that maybe has no browser vendor going, 'Rah, rah, rah,' behind it, such as security and authentication, privacy, and accessibility. We try to add those features into all of our documentation. And sometimes what the browser is doing is not exactly what the specification says, and so we file a bug. Or we report it.
Eric Meyer: Yeah, I like that there is that Open Web Docs becomes sort of an extra test on implementation versus specification. It's not just coming from implementers, but people who are, like you, looking at what implementers have done.
Will Bamberg: Yes.
Estelle Weyl: Yes.
Eric Meyer: Estelle, Will, thank you very much for joining us.
Brian Kardell: Yeah, thanks so much.
Estelle Weyl: Thank you so much for giving us the time and the platform.
Will Bamberg: Yeah, thanks for having us.
Brian Kardell: And thanks for all you do for the web.
Brian Kardell
Eric Meyer
Will Bamberg
Estelle Weyl