Tobias Fried: When I look at Departure Mono, the thing that I remember is going to the public library, using the terminals, which were still dumb terminals, like an Amber CRT with a keyboard that connected to some computer in the basement, to look up the library catalog, and find something, and find its Dewey Decimal number, and then go locate it on the shelves. That’s what it reminds me of the most. And that very much would have been implemented in one of these bitmap pixel font, monospace pixel fonts at the time. So that’s the reference that comes to mind when I look at this.

Russell Goldenberg: Yeah. It’s a great question. I think it’s a question that is probably becoming more mainstream in the past year in the data viz community. I feel like I didn’t see a lot of it being discussed previously… And something that is admittedly lacking and lagging compared to other places. I mean, I’ll be the first to admit that we’re not the best stewards of all time of this. It’s something that we’re working on currently. This year - I think it was just this year, beginning of this year - we’ve put into place… We’ve never actually had any kind of checklist for what we should even check before publishing a story, and that’s something that my former co-worker Amber and I worked on together at the start of this year… And we’ve put together the first step of many of like what is the baseline for what we need to do. And luckily, there have been a lot of great people working on this.

Frank Elvasky - sorry if I mispronounced that; I probably did… Who’s been working on this thing called Chartability - they have a bunch of documentation specifically thinking through how to think through data storytelling and accessibility, and it offers a really kind of comprehensive look at all the things that you should be considering… So that’s really been the framework we’ve been basing things off.

We’ve got kind of like our foundational thing, which is just like your general accessibility, like “Can you go through the whole page just using your keyboard” and all those other things that are kind of standard without data viz… And then there’s kind of like different rungs of approaching it from a data viz perspective. I think the first is – I wanna say the easiest low-hanging fruit is having good copying language and proper semantic markup around things. So if you have a chart, you should be able to understand what the chart is about, and the main takeaways, from reading the title and the description… Or if there’s accompanying text, a lot of it is in having good summaries about what’s in it, especially if it’s like a complicated chart that you can’t put actual interactive accessibility stuff with… Having really good copy that helps also explain what is going on with this crazy chart. I think that’s a good starting point.

Having alternative ways of viewing the data… My last real article that I did - there was a way to just look at it in tabular format, or have the data available as like a CSV download… So those are kind of – there’s basically all these different things. Some are really easy, and they get incrementally harder to implement and think of, especially as visualization gets more complicated. But I think we’re really following other people that are thinking more thoroughly in this space, following what they’re doing, and trying our best to integrate these into our day-to-day workflow when we publish a story.

But I do know - and this is, again, stemming from the journalism world - there’s so much fast and furious publishing that it’s super-obvious that this is something that falls by the wayside. I’ve noticed that every single big news outlet, especially the New York Times - I don’t wanna throw anyone under the bus, even though I just did… Because they produce some of the best visual interactive eye candy from a data visualization standpoint. There’s oftentimes where they’re on deadline and something has to give… There’s probably different pressures being put on, like “We need to get this out by tonight.” Some of this stuff takes a lot more time to think through properly.

Kris Nova: I think we just got an AMBER alert here in Colorado, and that was my Okay Google box on the shelf behind me.

Tracy Lee: So I haven’t played around with Vue yet, I don’t know what the syntax is like, so I can’t comment on that… I can only comment on Amber, Angular and React. If you want serious guard rails, then go with something like Ember or Angular. If you want to have more options of choice and learn more JavaScript-specific, but maybe not be as productive… Like, more JavaScript, less productive because you need to learn more JavaScript and more how to configure things, then probably go with React. If you don’t care about those things and you just wanna get really productive and build applications and have things done for you, then picking something like Ember, Angular is better.

One of my girlfriends just moved from – she works at Netflix, and she moved from Ember to React recently because of her job… She was really happy that Ember – she said that Ember helps you think about scale and what you need to do next, and it gives you a good foundation on how to be very organized with your project.

[28:02] When she moved over to React, it was good to have that sort of – it’s almost like going to the army first, I guess, and then going out into the wild; like, you’re always gonna make your bed…

Jerod Santo: Exactly, I would tend to agree, and that’s why I was curious how it was put together, because it seems like it’s very much your poster child for a framework like Amber, or some sort of React-based thing. Real quick, tell us about actions, because we’re talking about differentiation and this seems like a place where you’re really embracing your nerdiness, which is really why I even ask you specifically about this features. It’s almost like an “if this, then that” type of a thing that you’ve built into it… Can you tell us about that?

David Cramer: [43:49] That’s always been a little bit interesting with the npm client, because it was… There are a couple of different things to talk about when we talk about our participation in open source. There’s the npm project itself, the CLI project. There’s the massive number of open source modules which are published and shared and installed on the npm registry, and then there’s the broader open source JavaScript community which sort of includes Node, React, Amber and all the rest.

The npm client is open source - it always has been - but for a very long time it was essentially a single-author open source project, which is a very simple governance style. The governance was, “I make all the changes, and if you have an idea, I’ll either take your pull request or not”, but it was essentially just run by me.

That’s since changed significantly. We have a team of people working on it - there are three individuals working on it today, and quite a bit of their actual day-to-day work is spent on communication with our open source users. We take issues on the open source GitHub issues list, they have a semi-regular call that they do as an open hangout where people can suggest things for their agenda to discuss for that week, and they do regular releases with release notes, and are very responsive to the community.

That transparency has caused an increase in the number of pull requests and the quality of bug reports that they get, but they’ve also been working on making the codebase itself a little bit more accessible, which is a big and somewhat overlooked challenge in any open source project. I think the social structures around most open source projects make it so that you never really address that, because all of the people who are working on it obviously are the ones who are capable working on it, who are not intimidated by the codebase and who think it’s totally fine… Whereas newcomers can look at this, the way that it’s structured and the way that the architecture isn’t really well explained and say, “Gosh, this seems kind of hard. I don’t know if I really wanna get involved.” So they don’t get involved, they don’t get a voice and so it never changes.

I’ve seen this in literally almost every single open source project I’ve ever been connected to - npm, Node, PHP Core project, the Linux Kernel… Although the Linux Kernel probably does a better job of this particular aspect than most projects. It’s still pretty daunting, though. You can approach it in a couple of different ways, by breaking things up into smaller modules, breaking things up into sub-projects that people can contribute and be a part of, but it’s still just an ongoing, difficult, unsolved problem to make a codebase accessible.

But in terms of our role in the community, that’s been a little bit more challenging. I feel a personal weight of responsibility to make sure that this community is a functional community and to make sure that our users are able to use the service and not be in too great a conflict with one another, and able to actually get what they expect out of it. As the community has grown, we’ve gone through several different stages where different sorts of governance approaches have made more or less sense.

In the very early days actually, Michael wrote the first version of the registry, which had no authorization or authentication whatsoever. It was like, “You wanna publish a thing? Alright. You probably know what you’re doing if you know what this thing is.” That didn’t last very long. That had people taking advantage of it almost from day one, so we scrambled to add some authorization in there, but it was the simplest possible thing and now we’re kind of grown up to this stage where we have private code, where we have teams, and you can specify which team has access to which modules, to read access, write access and so on.

[48:08] Also, as a community, you go from the state where literally everybody has met everybody else. Where everybody was one or two degrees of separation from each other, to the point now where there’s more npm users than in some major American cities. This requires a different sort of policy, it requires different practices in terms of having things more well-documented and a little bit more regimented in how we approach certain types of conflict.

While on the one hand it’s a little bit troubling to have a for-profit company - or any entity, really - in this position of authority and control, at the same time anarchy doesn’t really serve anybody. Anarchy just means that the loudest voices have the most control, and that’s really not any better. I feel like there does need to be some sort of governance structure, and a body with a dedicated interest in keeping this community healthy is in charge of keeping this community healthy. Otherwise it doesn’t happen, and you end up with a tragedy of the commons really quickly.

At the same time, we try very hard not to abuse our position and to be as transparent as possible. Some of the things we do there - we have a support team, which if you email support@npmjs.com you will talk to them. They’re not there to do your Node homework, they are there to resolve issues that you might have with the service if there’s no other outlet that sort of makes sense. It’s sort of the frontlines of our support for the community.

We also have a lot of time and effort and money and energy spent on keeping the service running, which is sort of the core thing that keeps the community healthy. We try very hard not to abuse our position as much as possible. We are trying to run a business, but the actual purpose of this business is to keep the community alive and running and healthy. My main goal with starting a company is to keep the npm registry running forever. I think that’s in the interest of most of our users, so I can sleep okay at night because of that.

If two people want the same thing or are fighting over something, the one that you don’t agree with is gonna be very upset at you about it, and there’s sometimes just no way around that.

Carlisia Thompson: Yeah, and even Amber - I learned that actually just yesterday, that they have something that generates JSON API’s pack, and if you have a schema for that, I think they auto-generate code. Somebody was saying it’s super easy, and we can do that with an API in Go, of course. Now, I have to follow up on something else you said now. Why is Go not good to use with SQL? I’ve never heard that before.

David Heinemeier Hansson: Yeah, Active Model Serializer. I think there’s values to both of them. I think JBuilder’s probably a better fit when an API is just one of the things that you’re doing, along with everything else, and then I think the serialization project makes a lot of sense when you’re just building an API and you always want the same representation in all of your API setups. It works very well for, let’s say, something that Amber expects. So we’ll figure that out.

Again, there’s no underlying fundamental philosophical differences here, and I think that that’s a key realization that you have to make to be able to have progress and stay in the same tent.