SRCCON 2019 • July 11 & 12 in MPLS Support the SRCCON team

← SRCCON 2019 Session Transcripts

Noise & Signal: Knowing when to adopt new tech, and when to ignore it

Session facilitator(s): Alexandra Kanik, Natasha Vicens

Day & Time: Friday, 2:30-3:45pm

Room: Johnson

ALEXANDRA: Hey, everybody. We’re going to get started soon if everybody wants to wrap up their convos.

NATASHA: We have some big sticky notes at this table, that table, and this table here. If the people in the back could condense and come up to these tables, that would help so much. Maybe anybody at some of the bigger groups maybe want to make one.

ALEXANDRA: Awesome. Okay. Hi. Everybody’s h to be very mindfulere for this: noise and signal, newsroom tools? How not to lose your cool? Yup, so we will introduce ourselves real quick for the people just walking in, if you wouldn’t mind sitting at a table that has a big sticky in the middle, that would be helpful. And if there are too many people and it gets too congested, we have one more sticky so we can open up one more table.

NATASHA: Sorry for anyone who just got in here because there was a big meeting. If anybody’s got sharpies and pens and, we’ve got more up here, too. I’m Ally Kanik and I work for Louisville Public Media, we have an NPR affiliate. We have a long-form investigative journalism arm and also a kind of, like, public-media collaboration between Ohio, Kentucky, and West Virginia.

NATASHA: I’m Natasha Vincens and I work in Pittsburgh at a local news startup called PublicSource and I’m the interactives editor there.. We’re both the only ones that do data/dev/product if you want to call it that. We don’t call it that in our newsroom. So that’s what we do and so we have mindful and thoughtful about tech and adopting new programming languages because we don’t have a ton of resources. I know not only local, small newsrooms have those issues; everybody has those issues. But that’s why we pitched this session together, this session.

ALEXANDRA: So yeah, just real quick the… so I think basically what we’re trying to do is come up with strategies to identify, like, when you should even give, like, a new thing credence. Like, you should, like, think about adopting it into your workflow ‘cause I don’t know if y’all are the same but every time, like, a new thing comes out, like, a new library, or, “Oh, are you guys using this yet?”

NATASHA: Like, you’re not on SASS, you don’t use Gatsby.js? You don’t use ES6?

ALEXANDRA: And it’s really just like hard to know when to care about things coming out. Like, are they still going to be there in a couple years? Does your team have — I mean, we are — I’m a team of one. Natasha is a team of one. So do I have time to learn the tool? Do I have the resources to learn it?

NATASHA: Who has these struggles, too? Very common? Not cool. But we feel your pain.

ALEXANDRA: So, yeah, so that’s basically what we’re trying to do here. And, yeah, we just wanted to remind people about not everybody knows all the jargony things. Like, we’re going to be talking a lot about tech tools. So just try, if you’re thrown some stuff out there, try to be mindful that not everybody understand the acronyms that you’re using.

NATASHA: Like, I’ll throw some of my favorites out there. I didn’t know what working in sprints was until yesterday because we don’t do that in our local newsrooms. So I was like, are you running sprints? So I’m in the know now and I’m using that lingo but not everybody knows what that is. So let’s just be aware that have.

ALEXANDRA: And I guess on both sides of that, if you don’t know what somebody says, please ask… definitely ask and we’ll just all agree not to be assholes today. So point two, I think. Okay. So we were just trying to get a handle on, like, who is in the newsroom.

NATASHA: A little exercise because we all just ate lunch and lots of doughnuts. So stand up if you work on a team of five or fewer people. Oh, okay. Everybody sit down. Please, thank you. Stand up if you are the — so stand up, I guess if you work on a team of more than five people. Okay. Cool. Thank you.

ALEXANDRA: So anybody out there a lonely coder, like, the only person in their newsroom or their company. I don’t mean to say “newsroom” all the time. I know we’re all from different places. It’s just kind of habit for me. Let’s stand up! Whoo-hoo! Nice.

NATASHA: Stand up if you’re able to make newsroom decisions about adopting new tools or tech, or programming languages in your, or company.

ALEXANDRA: Oh, cool. Awesome.

NATASHA: We have, like, a split room. Very cool. Thank you. And then we went… stand up if you’ve adopted a tool in the last two years that you no longer use. A language or… okay. People have had cool successes. Stand up if you’ve ever been hesitant to adopt a new technology/language/tool in your newsroom.

AUDIENCE: Everybody!

ALEXANDRA: That’s why we’re here!

NATASHA: Please sit down. Thank you so much.

ALEXANDRA: All right. Cool. We won’t make you move for the rest of the day. I don’t know, so I always like to get to know the people that we’re going to meet. We’re going to be doing a lot of small-group work at the tables that you’re in. So maybe take a couple of minutes to get to know who you’re sitting with. You may have seen people stand up and do, like, little — you know, they’re lonely coders or whatever. Maybe include your name, you can do this in your small groups. Name, where you work, and if you’ve been to SRCCON before.

NATASHA: And what you’re excited for right now, in life, maybe at SRCCON, and maybe your dinner tonight. Okay. Go!

[ Group Work ]

All right. We’ll take about one more minute and wrap up.

NATASHA: Okay. We’re going to get started with our next session here. Everyone, thank you.

ALEXANDRA: I just wanted to make a quick shout-out to Stanley in the front doing our stenography and transcription. Thank you, Stanley. So, yeah, just a reminder when you’re speaking, you know, try to speak up so we make it as easy…

NATASHA: To the big group.

ALEXANDRA: And then also if there’s anything that you would like off the record, say, “Off the record first,” and then that’s stricken from the thing and so —

NATASHA: So and so now we’re going to move into some software functions and do some individual brainstorming for a few minutes. We want you to — do we have our I apologize — if you don’t have regular paper or can’t grab a Post-It, you can do it on there. We got some sheets for you. We just want you to create two lists with a line down the middle on a piece of paper and on one side, list some tech tools, programming languages that you’ve successfully adopted into your workflow, and then on the other side, those things that you have unsuccessfully adapted.


NATASHA: Did not adopt. Did I say that correctly? And then, these can be tech tools, project-management tools. Asana, Trello, programming-language tools, any tools that you use on the job. We’re going to play you a song for one minute. This is called “Beach Party for Tonight.” We’ll just take another minute with this song.

ALEXANDRA: Okay. Cool. I think we’re kind of curious if people have similar tools that they’ve tried and failed at, or tried and succeeded at so we’re just going to kind of — I think it’s more constructive to do the small group. So, like, within your smaller groups, just share the tools that y’all wrote down and see if there are any similarities or, yeah, if there are any similarities and then we’re going to go around the room and everybody kind of have a chance to say, oh, yeah, we have a lot of people using project-management tools that we couldn’t adopt or specifically one tool. So, yeah, discuss! If there’s anything that’s not clear, let me know.

ALEXANDRA: Okay. I know y’all are still talking and that’s cool because that’s going to bleed into the next thing that we’re going to do. But the second thing, maybe each table elect a representative that can — sorry.

NATASHA: I’ll just pass it around. We’re just really curious hearing about the tools, what did, what didn’t work for you. And then the next share will move on to why it didn’t work for you.

AUDIENCE: I work at the New York Times at the Interactive News Desk. And I didn’t get a perfect list of things that broke down into did adopt or didn’t adopt. It was more common that we had things that we adopted and then, generally, worked well. And then we have things that we also adopted but I don’t know if it always justifies the placement. So some of the things and I’ll just say that worked really well for us are GitHub as a project-management tool. Node as a pretty easy common-ground development language for server-side stuff. Slack as a communication platform, Google Docs as a place to write stuff down. ES6, like, a sort of recent JavaScript syntax that we’re still working towards it but it’s useful. And the stuff that isn’t always worthwhile but is sometimes useful which just takes longer is, like, writing the correct Webpack configuration. Or always running your app locally with data-compose. You can do it. It takes a little bit of futzing. Sometimes it’s a little bit of overkill. We don’t know what we should do.

ALEXANDRA: It’s also interesting because it’s not just tools. It’s also procedures that almost fit into a workflow. Yeah, I would like to document my code every single time I write something but sometimes I don’t have time.

AUDIENCE: And another one is: what is a correct test framework?

ALEXANDRA: Don’t talk about testing again! You’ll set off a fire alarm.

AUDIENCE: So that’s a few examples.


AUDIENCE: We were going to go through a few different things that we were going to talk about. AWS, that’s worked for us on a couple of projects. Google App Engine, straight-up used them on a product before. And then some things that didn’t work. I talk my own experience we’ve had a couple of project-management tools that’s fallen by the wayside. AirTable has not. Basecamp, half the organization does, and half the organization doesn’t use. And I’m trying to think of the other ones. And so, yeah, there are lots of things that we can talk about that we had brought up or used in some way, but are not being used to their full potential or were very outdated in some way.

AUDIENCE: So we’re going to talk about this, I want to say Google Fusion Tables, I used on a project a long time, and it was a thing that was successful at the time but now has been shut down, so our work just vanished.

ALEXANDRA: By no fault of your own, unsuccessful.

AUDIENCE: Yeah, so that’s right.

AUDIENCE: We talked about some project-management things, too. So Trello was mentioned, AirTable as being successful, and Data Studio as things that have been helpful. What’s another one… Trello — move that back under “successful.”

NATASHA: It worked fine.

AUDIENCE: So we kind of spoke about some of the kind of Confluence kind of came up as a thing that didn’t work out.

AUDIENCE: What is Confluence?

AUDIENCE: It’s a little bit like SharePoint. It’s kind of a knowledge-base kind of systems that allow you to have kind of an internal Wiki for any kind of stuff. Any reference guide for all new employees or whatever. And, in this case, there was a lot of friction around the way it was set up. It’s only an internal tool. It’s only available within the building, or via VPN, for example, and Google Docs ended up being a better example and we looked at alternatives to Slack in terms of encryption and we were looking at a key-base Semaphore, and WireWas.

ALEXANDRA: And were some of those successful?

AUDIENCE: Semaphore was, and Wire was not.

AUDIENCE: One thing that’s kind of interesting that we’re looking at how in an evaluation phase is Flutter which is a language that compiles to both iOS Swift, and Android. So this is kind of an interesting inflection point for us because we’re deciding whether to use it or not and that’s going to determine whether it’s going to be successful or not.

AUDIENCE: I just wanted to add one extra quick thing. Similar to it, of all the tools that we had adopted and moved from. Amazon Redshift because it became really expensive.

NATASHA: What was it? Redshift.

AUDIENCE: It’s a big-data scalable data warehouse solution but we ended up replacing it with another AWS service. And then data-science machine learning models, that our data scientists worked on but never got adopted. But one that I use personally but couldn’t get greater support from was StackExchange which is used as a Q&A board. But, um, yeah.

ALEXANDRA: We got a contact, man. That was your fault.

AUDIENCE: We didn’t even get around the table to share.

ALEXANDRA: And we’re going to be getting into more in-depth. And if you guys feel like you have to break into two different groups, we can do that.

AUDIENCE: I can’t speak for the other side of the table but we weren’t able to share but one common thing that came up was Zeppelin and Sketch for prototyping. So, for me, in the newsroom, we were adopting a tool that was being used on the product side to try to standardize the workflows and the tools that we were using across the board. And people at the table were also kind of adopting, well, Zeppelin was the big one.

NATASHA: I actually don’t know what Zeppelin is. Is it design or Sketch?

AUDIENCE: It’s like designers can upload their files and it can show you the border ratings and all the CSS have that all generated for you. So much less taxing than having to use the eyedropper tool and say, what was that color again??

NATASHA: Should we move into small-group work now?

ALEXANDRA: Yeah, let’s do it. I’m going to pull that up other slide. I think you’ve to do the… okay. So here’s what we were going to do for this and I think that I’ve heard a lot of you guys kind of doing this. Kind of, like, pick — and you can do this, like, as individuals, or you can do it as a group. Pick a tool from your list and you’ll notice on your tables, you have these big stickies and they’re broken up into kind of quadrants. So for each of the —

NATASHA: I can show here.

ALEXANDRA: Oh, yeah, we have on example here in case you’re like, “I have no idea what I’m supposed to do.”

NATASHA: Okay. So we have for your successful tools and your unsuccessful tools, we have four prompts written down the sides: how did you hear about it, what problems was it supposed to solve? What were the biggest struggles, and why or why not did you ultimately adopt or not adopt put it? So, like, an example of an unsuccessful tool that our newsroom didn’t end up adopting was Data Wrapper. I’ve heard about it from some data blog what problems did it solve — data-viz creation, struggles, limited flexibility, I couldn’t match my own styles without paying for it. Why we did not pay for it… why we didn’t adopt it. We moved onto a better software. So that’s an example.

ALEXANDRA: Yeah, so take some time and try to put some sticky notes under some of those topics and then we will reconvene and kind of see if there are any similarities there between those different things.

[ Group Work ]

So we’re going to be sharing as a bigger group now. Does everybody feel good about their Post-Its? Natasha was mentioning earlier, I think everybody has Post-It fatigue…

NATASHA: We’ve probably moved on from the Post-Its.

AUDIENCE: I think the Post-Its are successful.

NATASHA: Yeah, yeah.

ALEXANDRA: All right. Cool. So hopefully y’all had a good chance to talk about some ways, common ways that you were able to find tools and ways that some of the tools differed or were similar in the struggles that you encountered and maybe, like, why you were able to adopt the too tool in the end. We’re just going to go around — does anybody want to share what their table kind of came up some of the things on their lists?

AUDIENCE: Well, the two most successful ones, I think, that were in common in our group were Django and even generally just Python as a language, and GitHub, and GitHub Issues. Also, git. And unsuccessful things were niche languages like Go and Scala.

ALEXANDRA: What about being a niche language makes it hard?

AUDIENCE: There’s both the education aspect of getting engineers trained in it or newsroom engineers in particular. One that came up was Docker also which is successful in the product work but among the group —

AUDIENCE: It’s successful in silos. It’s not globally successful and accessible to everybody in the newsroom.

AUDIENCE: And then also for us — the sort of maintenance — ongoing maintenance — or community. Community’s probably the biggest one of either one. Either community of developers or community of standard modules to use. That’s really why we moved from DCOS to Kubernetes, or from Scala to Python to, you know, not adopting a certain language. Or any evaluation phase, not even adopting it because there wasn’t a community. One of that I worked for at my prior company was we didn’t decide to use React because we didn’t know if React would be around in one or two years.

ALEXANDRA: Did anyone else have anything in terms of community or whether or not they adopted things because there wasn’t a broad. Did you want to talk about that one?

AUDIENCE: In our unsuccessful catalog we talked a lot about project-management tools and various lines of why they weren’t successful just because people wouldn’t get on the same page. One person would hold out and do one thing and use a different system because that was their favorite system. I think that was definitely something that all of us had definitely seen/struggled with.

ALEXANDRA: So community can mean of people who adopt and/or use it at your workplace. But I thought community be like, StackExchange, what the hell is going on?

AUDIENCE: Well, that was kind of like our successful side, AWS and Google Cloud saying that there’s so much community and help on the community side. And found things that were old that had helped so many people move in the right direction.

ALEXANDRA: Some of you mentioned Django here. Has anybody used Django or everybody knows what that is? Yeah, the documentation is so good and it’s updated and it’s got the versioning of the updates and everything. Like, that makes all the difference and I’ve tried to use Flask before which is, like, a similar and I just couldn’t do it because I went to art school. I’m not trained as anything so I have to google my way through everything and if I can’t, it’s nearly impossible for me to do anything.

AUDIENCE: Google’s internal documentation is not as good.

ALEXANDRA: Say again.

AUDIENCE: Google’s internal documentation is not as good. I just want to clarify that.

AUDIENCE: I named my dog, “Django.”

ALEXANDRA: Oh, my God! We’re going to have to see photos later.

AUDIENCE: Community for personal projects, that’s what made me switch from React to Vue. Especially for personal projects, I’ll go for Vue first because they go for developer experimentation and developer comfort and I trust the vision and kind of what they prioritize. So a lot, for me, adoption for any tool is really trusting the direction that it’s going knowing that the direction could change. I change vision or philosophy with kind of the contributors and developers.

ALEXANDRA: Yeah, yeah.

AUDIENCE: Yeah, I’m going to mention about Go. So a couple of years ago, I was working at a previous company and they had just adopted Go from the start and now I talked to the person that made that decision and it turned out that was a bad decision because they’re building the libraries that are available like date parsers and stuff. It’s basically how much time do you have on your hands as well. So they eventually switched to Python completely. So that was a lot of waste of time and effort and contributing to the community that didn’t even have the time to do that.

ALEXANDRA: So it’s like even if it has good documentation, if it doesn’t have the core features that you need it, and you would need to build a bunch of things, is it worth it?

AUDIENCE: So at my last firm we were all in with Google’s stuff. So Google Cloud, but also a lot of Google, things like Protobuff and the message transit formats and the experience there is if you aren’t Google, a lot of, like — it just doesn’t work as well. So, for example, in Protobuff you have this big schema sharing problem. Everybody’s gotta copy the schemas across the repos. But this isn’t a problem at Google because everyone’s on a mono-repo. So they don’t have any versioning problems because everything is in one place. But we don’t have 50,000 software engineers working for you. So I think with things like Go or places that are promoting that, if they’re coming from a huge engineering organization and you only have ten or 15 people or one person, you’re just not going to be able to — there’s so many things that that team at Google, for example, doesn’t consider when they’re releasing or open sourcing or promoting their stuff. So that’s one thing that I thought I would elevate. And there was this talk called Choose Boring Technology. He had this concept of innovation tokens, which is where if you’re starting a new project, you have some number of innovation tokens that you need to spend. And so these days at Etsy, it’s like we’re building a global marketplace of craftspeople. That sounds pretty innovative and so we’re spending a lot of tokens on our product. So as a result we don’t get to spend a lot of tokens on our technology, so we’re going to choose PHP and we’re going to choose MySQL and we’re going to choose MyApache. And these are boring, proven technologies. But this is going to go off topic.

ALEXANDRA: That’s actually perfectly on topic, actually. So that’s what we’re doing here. In my head what’s going to happen is we’re going to try to make a list, like a checklist almost and any time you’re kind of coming up against a new tool, you know, you check the boxes or you don’t check the boxes depending on what the tool does and how it works. But I like this token system almost ‘cause it’s instead of, like, checking boxes, it’s like, here’s my pot of tokens and money, and, like, here are all the things that I have to consider. And, like, what’s worth what? So that’s a really good way of thinking about it.

AUDIENCE: Hi, this is Tim. So not necessarily related to what we were talking about. But we recently did an evaluation of at least, like, eight text editors to choose. And we did heavy, like, technical analysis of the stuff. And there’s a bunch of things like, “Does it support the actual copy things that we want?” We didn’t want to put a lot of support into it and we weren’t sure the duration of using this. We just wanted editors not editing code basically. So we evaluated, like, language support and we had scripts to run — more like verbal or text scripts like try writing these words in Japanese, in Pin-Ying, in Spanish. And try to develop some operations for it. And then of a that try to develop small bits — actually do experiments with the technology to see how it works and to see what sort of robust — and so we tested against ProseMirror, CK Editor, and Slate were some of them. A lot of it was looking at it holistically, doing the exact same tests with everything, being consistent and then comparing them against with each other and determining what’s the best match for us. And this was like a bunch of time but we limited the tests to be something very simple like…

ALEXANDRA: That sounds like it took a lot of time.

TIM: It took, like, two weeks for our team which was about too much time.

ALEXANDRA: That’s a huge thing: a text editor.

TIM: That’s a huge thing. Something that’s an example is a blockquote. We implemented something for that. That seems like something very easy and straightforward. But if you’re neck deep in implementing your product and you’re OBD this, and you realize that is a complicated thing that might be impossible, then you got in trouble.

AUDIENCE: I just want to say one more thing about community. There’s a technique that I sometimes use to figure out, like, how much community a project has. I don’t know if anybody has this or ever does this but if I’m trying to decide on a library to adopt or something like that, I’ll go onto Stack Overflow and I’ll search for the tags for the libraries that I’m considering and see how many questions there are for each library and I choose the one with the most questions ‘cause that indicates there are people using it, and answering questions about it and that kind of thing.

ALEXANDRA: Do they have a statistic on how many questions are answered on, like, if you were to look at the tag, can you see how many answered questions and asked questions?

AUDIENCE: You might be able to figure that out somehow, I just look at how many questions.

AUDIENCE: StackExchange publishes based on all the stats for their entire site, language percentages and also correlates it with a lot of things, like, what languages should you learn as a developer based on StackExchange questions or which jobs pay the highest based on that language and things like that.

AUDIENCE: But also they have — Stack Overflow has a page, I think if you search for “trends” and you just type them in and you can plot them all against themselves.

AUDIENCE: I use that same trick for GitHub. GitHub, and especially for npm modules because there’s approximately 76 million of them now. I would actually go to the npm site and see how frequently downloaded, but it’s GitHub and Stack Overflow but GitHub is one of my favorite places to ask, “How frequently is this used?”

AUDIENCE: And for anyone who’s writing an open-source tool, getting those GitHub stars is actually a big tool for developer option. My friend he developed his way up his GitHub stars. In the same thing that people buy likes because he wanted to build very quickly, community adoption around his tool.

ALEXANDRA: But is that mildly smarmy, though?

AUDIENCE: It is a little bit but it helps to build community.

ALEXANDRA: It’s an interesting way to think about it.

AUDIENCE: One small add-on to that. I got some advice a while back that said: don’t just rely on the stars on GitHub. What you really want to look at at least if you’re on npm and all the other package managers, as well, are how many other things are relying on this, and what you can do in npm is search and see how popular it is and how many dependents does this package have. It’s not just how often it’s downloaded but how many other packages directly use this thing and that’s a really simple thing that I use sometimes.

ALEXANDRA: Really quickly because we’re going to jump to something because we only have ten minutes.

TIM: So the other thing that I specifically look at is diversity of contributor. I look at all the commits in a GitHub repository. I do this a lot. I want to make sure that the commits are regular and if it’s not regular, that it’s stable software and that they respond quickly to issues. If they don’t respond quickly to issues or they’re rude to issues, or they don’t have a code of conduct to this. There’s also, is this owned by a single company or person. Is it a single person? If it’s one company like React, or Go, it’s one company that owns it. If there’s risk attached to one company that is not associated with the economics of the company being successful then that’s better.

AUDIENCE: I have one quick anecdote about that. I used to use this visualization language called pyturk to use it, and the research company wasn’t licensed to use it, so it got pulled.

TIM: That sucks.

ALEXANDRA: So I think this is just a continuation of what we were doing, but I think we want to start creating a little… I made it unnecessarily bad — I’m sorry. Creating, like, a little, like, master checklist, I guess, of all the things.

NATASHA: We’re going to go analogue.

ALEXANDRA: We’re going to analogue this whole… so kind of like a master checklist of, like, things that you need to consider when you’re going to be adopting the tool. And we already did kind of — I mean, what we were just talking about: how would you label that whole kind of like, like, GitHub stars or Stack Overflow. I mean, community…

AUDIENCE: Community adoption.

ALEXANDRA: Community adoption and the nuance of it would be…

TIM: Consistency.

ALEXANDRA: I can write like this?

STANLEY: External evaluation. GitHub stars, et cetera, dependents, lots of users, comments, and quick responses to issues or PRs= external evaluation.

ALEXANDRA: Something that somebody brought up was security. How does that factor into whether people adopt something?

AUDIENCE: We had a conversation about using Google Docs or Google technology and we got some pushback from higher up in the organization from Legal about are those secure if we have sensitive reporting could that be moved over to the majority?

NATASHA: I’m interested: how many people use Slack? Does anybody use Matter Most?

TIM: I’ve heard of it.

NATASHA: Yeah, it’s like they’re a Slack competitor. They’re encrypted.

AUDIENCE: Matter Most isn’t really encrypted. It’s just fed rated and alternatives like, Semaphore, Wire, and keybase, those were essentially end-to-end encrypted so if the authorities were subpoenaed, or made them turn over their chatlogs, like Keybase wouldn’t be able to turn over Keybase chats, and Wire wouldn’t be able to turn over Wire chats. Like, we haven’t totally bought in because we’re really close to it.

AUDIENCE: Well, not even say a legal or authority-wise but Slack messages are available.

AUDIENCE: And also as the admin I can download all those Slack messages at least for our entire company. Our union drive which happens about a year and a half ago, there was a concerted effort by everyone who was involved in the union, all the employees because our CEO, at the time, was basically looking through all of emails and all of the Slack messages that they took all of those conversations, changed the Slack message retention policy to only two weeks, and then encouraged all the employees to have offline conversations because of the unionization effort, and in concert with that — probably just kind of the community mindset within our company that everything that isn’t appropriate to talk about on Slack, we talk about either over IMessage if it’s kind of whatever conversations, or with Signal if they’re privacy-related conversations, or anything where the authorities might be involved. Especially for reporters who, you know, have confidential sources and safe sources, you know, deidentified sources, and stuff like that.

AUDIENCE: One thing that I haven’t heard anyone say is, like, using this community as your resource. Like, we’ve found a tool, or created a tool for geocode — like, taking addresses and geocoding locations and we didn’t know where to learn for that. And we turned to the News Nerdery Slack channel and got really, really good responses and chose that tool based on that feedback. So I would also say that’s a really good community resource because we have lots more people there. They want to help.

NATASHA: I hope Slack never gets hacked. Pretty sure we’re all going to get fired.

AUDIENCE: I think it’s a certainty at this point.

NATASHA: Yeah, yeah.


AUDIENCE: Lonely Coders Club. It’s another Slack.

ALEXANDRA: And it differs — Natasha and I are in it. It differs because it’s a much smaller — not smaller group of people because it’s a smaller community of solo developers in their newsrooms so the problems tend to be a little more…

NATASHA: And freelancers.

ALEXANDRA: Yeah, yeah. But if anybody wants to join that, or thinks that could be the thing for them, please let me know and I can add you. Thank you. Any other things that are — I mean, I think we’re kind of wrapping up here. One thing I did want to say, actually, we should just jump into that, up here at the top of every page on this side, there was the link to the etherpad that we were typing away on. So feel free to keep checking that.

NATASHA: And, obviously, the transcript, too, thanks to Stanley.

ALEXANDRA: Yay! Thanks, Stanley! And we do, our ultimate goal is we are going to take all of these things that you guys did and compile — like, fill this list out a little bit more and we’re hoping to really set and have it be almost like a template that people — obviously, everybody’s situations are going to be a bit different but hopefully you can have a set of questions before you adopt a tool and you can adapt it to your needs.

NATASHA: Thank you so much.

ALEXANDRA: Awesome, guys!

AUDIENCE: What did you use instead of Data Wrap?

NATASHA: Ways and means of democratizing news and graphics.