 Hi, people. I'm just going to go because we have short amounts of time. OK, my hip got it. I'm Georgia Bolin. I'm going to talk about a game I have been designing as a side project. At the moment, it's called the tech policy card game. I am taking name suggestions. You can even do it on the GitHub if you want. So first, who am I? My background is in human-computer interaction in UX. I've worked a lot in data viz, technology, and a lot of community and research work. I'm currently the executive director at a nonprofit called Simply Secure. I won't read that, but that's up there. I'm also an advisor at Measurement Lab and at Tech Congress. And I was previously at the Open Technology Institute, which is where we started this project and the Spatial Information Design Lab. So the idea was, how can we use a game to better understand the policy space? So policy is pretty obtuse to most people, I would say. And people who work in policy aren't really great at making it approachable. As a usability person and a techie, I was like, let's do something about this. People love games. Maybe we can make a game to make it easier to understand. There's a lot of alignment, like structures, systems thinking, you have opportunities for creativity. So maybe we can get better at problem-solving or on policy if we have games to play. It makes it a lightweight way to understand those concepts. We could use it for workshops and teaching and honestly, just to decompress a little bit. Because when you lose the net neutrality fight, again, you get kind of tired and maybe you want to be able to joke about it with your friends. So I pitched a game company. I reached out to Looney Labs that makes Flux because that was what we were basing it off of. I was like, hey, super cool idea. And they were like, nah, that's cute. We don't think that'll make any money. I was like, too bad doing it on our own. So actually, that was just made it fun for us. So we did this basically through a bunch of workshops. Started at the Open Technology Institute. We did some there with the lawyers and techies who work in the office. We did some with some people who work in movement hosting. So groups like Rise Up, Electric Embers, things like that. I took all those ideas and tried to figure out a way to then pull that together. My lovely partner, twins, built a way for us to quickly prototype that. So all the cards are defined in JSON. There's a Python converter to turn them into printable HTML. And then we printed at MozFest and workshopped it some more and have actual cards. So this is all available on GitHub. You can modify it as you want. So some things we've learned. People are really good at coming up with, hey, these two things should mean this thing. They're not really great at making rules or actions. They were really excited about it as something different. People get really into the game, which is fun. Lawyers really don't like to know how their work can be simplified. It's kind of threatened by it. And then we, in play testing at MozFest, we really found some issues around the global and local scale. Things that we think are general knowledge. Acronyms or concepts or agencies don't always translate. So yeah, that's the GitHub. Please fork remix. It is super simple. If you have questions, let me know. Hi, I'm Stuart Geiger, and I am, I'm gonna talk to you today a little bit about documentation. I am the staff ethnographer at the UC Berkeley Institute for Data Science, which is a kind of weird role. I come from a background of anthropology and history and philosophy of science and very interested in how we know what we know and how that's changing around data and computation. And I wanna talk to you a little bit today about a project that's done in collaboration with several of my colleagues at BIDS and around documentation, which is something that is crucial, but often something that we have a lot of issues with. And this came out of a sort of interview in field-based study around documentation in free and open-source software, particularly in the data science space. Initially around this event called the Docathon, which was sort of an event around sort of saying that you're gonna only work on documentation for a week as opposed to working on other aspects of software. And the paper is now published in the Journal of Computer-Sported Cooperative Work. So go check it out at bit.ly slash OSS docs. And I'm gonna give you just some brief, high-level sort of findings and sort of teach you about some things that are sort of interesting and that we've learned from this. So first off, almost everyone routinely relies on documentation, especially veteran programmers. But one thing that's interesting is that many newcomers to programming, particularly students, sometimes think that Docs using the documentation is cheating or it's sort of wasting time. And so this is one thing sort of in education and training that a lot of, this is something that science education also deals with is sort of rote memorization versus learning sort of higher level concepts, learning how to use the documentation that the documentation is okay is an important part of computer science and programming education. There's also kind of the paradox of documentation, which is often that sort of those who are best able to write documentation are often those who need it the least, which is sort of an open source. There is this sort of, it's based on scratching your own itch, which in the case of documentation can sort of cause some issues if it's sort of just relying on people to produce things that they themselves need for their own sort of positionalities. We also sort of find that in an interview sort of documentation work was often perceived as not being technical work, but it involves many technical and non-technical skills too. We also found that most sort of open source free and open software developers said that they didn't enjoy writing documentation as much as they did sort of writing code and they feel like they get less credit from their peers for doing various kinds of documentation work. We also find that documentation work is not equitably distributed in a lot of these communities. It can also be gendered in the way that a lot of sort of community work is in these kind of projects. And some projects sort of require, have policies requiring documentation for new features or give maintainer author status explicitly for people who do documentation work, but many do not. And so to wrap up, this is sort of part of a much larger ongoing project on sustainability, invisible work and burnout in free and open source software. It's been funded by the Sloan and Ford Foundation. So if you'd like to talk to us about these issues, please get in touch, contact info is there. We'd love to talk to you if you're sort of in these sort of spaces or have thoughts and feelings about them. So thank you very much. All right, hello everyone. My name's Gabrielle Hayden. This is Vicki Steves. And we are both librarians for research data management and reproducibility. I'm at UofL and Vicki's at NYU. And we are here to say that when you think about reproducibility and communities of shared responsibility around reproducibility, you think librarians. The job of the library is to use cutting edge technologies to disseminate reproducible knowledge from the papyrus to the printing press to the repository. Our titles talk riffs on Walter Benjamin's famous essay, The Work of Art in the Age of Technological Reproducibility. And there he talks about the aura, right? The place and time in which something is created. So with apologies to my former career as a humanist, let's think about the aura as the computational environment, right? And as Dr. Whitaker noted, given the pace of computational change these days, that aura is increasingly difficult to replicate, to approximate when we want to make our research reproducible. So, and she did such a great job of talking about reproducibility. I'm not gonna belabor that definition here, but really just say people have started to really think of libraries when they think about research data management. But the role of libraries in assisting in reproducibility is not just in data management, but in everything that goes into data management best practices plus capturing the workflow and provenance of research practices and really capturing, as we say, that aura, that computational environment. And so I'll just say an overview of sort of what data librarians do, which is sort of the niche of librarianship in which Gabrielle and I are situated, is that we provide services for data and information literacy. We collect data for reuse by our community. We support you and your grants. We provide repository services and we do digital preservation and digital preservation is not just about keeping bits safe. It's about enabling reuse. And so you can see where weaving these together could really have a lot of potential for holistic research reproducibility services. And so here are a few ways in which I've worked in reproducibility services in the library and in which Gabrielle will also be working. A few of these just to gloss over infrastructure. So providing funds, labor and use of floss reproducibility tools. No corporate capture of reproducibility. You know who I'm talking about. Education, we teach a ton of classes on helping folks work reproducibly. The biggest area of improvement for libraries is making sure that the things that we are collecting are reproducible. And then in digital preservation land, we see, oh, I timed myself. There is emulation as a service as a means of preserving software and operating systems and making those available to researchers for computational reproducibility. Call to action this. Hello. So I'm a little stressed out. But I'll try to tell a story. So I come from Belarus, which is a country not many people know about. Or not many people know about what's going on there. It's a place where there are 23 universities. Lots of educated people. But not a huge impact on the scientific for publishing worldwide. So there was an attempt, or there was a chance for Belarus to be put on the map of the big science in the 30s when Albert Einstein applied to get a job at the Minsk University because his favorite assistant was teaching there. But the decision was escalated all the way to Joseph Stalin, if I said that, no. And no. So I think there is a chance for people to put Belarus on the map of science now. And there's something that's happening that's kind of like a revolution. Because 10 years ago, the librarians from 23 universities, all the universities in Belarus got together and made their universities publish all the research online and all the syllabus and all the teaching materials in an open format, all texts, everything fully searchable on an open source portal, this piece. And right now it's 600,000 articles. And it's about topics, about things like what happens when a part of your country is polluted by a fallout from Chernobyl. And there is a part of Belarus that's completely cornered on off and there are just wildlife things happening there and scientists. And you can find out about what happens when, from these publications, I mean, what happens when there is a language disappearing in real time, because 20 years ago, 30 years ago, there were 4 million people speaking my language. And now there are probably 200,000. So it's happening right now. And there are studies about that. Or maybe you just need a data set about how things are changing in the generations, in the academic setting, in the non-English-speaking area or country. So any of those things can be uncovered. If you need this data set, talk to me. I'm happy to open this up to anyone else. Thank you. Questions? Questions? Hello. My name is Asura. And I'm here to present Open Knowledge Maps, which is a project that wants to change the way we discover research. How do we discover research? We usually go to these, to our favorite search engine, type in our keyword, get a lot of results. And then, as we don't have the time to skim read two and a half million papers, we'll probably head over to the most cited one. And for reasons that are probably not good in a lightning talk, we believe this is bad and suggests an alternative, which is a visual approach. We create knowledge maps based on these results, extract key topics, build clusters. You can dive into these. You can read the papers. And we try to create all our software, all our projects, all the content is openly available, openly licensed. And please head over to openknowledgemaps.org and try it out. The second issue that I want to address, two lightning talks, goes back to this issue. All of us use Google Scholar. Everyone does it. This is part of research culture. And second of all, the more important fact is that this is bad, because Google Scholar does not provide APIs. We do not know how they rank the results. We have no access to historic data. And this is bad because it not only affects researchers and institutions, but also institutions. And as a matter of fact, by doing this, we are running into a wall of dark knowledge. This term coined by Jesh Kedal, 2016. Please look it up. Basically, it refers to the knowledge lost not only behind paywalls, but also behind the missing reproducibility, behind privatization, behind commercialization, and does also apply to all these other platforms that all of us use. So this is why we at Openknowledgemaps also support open infrastructure for discovery, for knowledge discovery. And please, two things, head over to Openknowledgemaps if you're interested, and also check out hashtag Don't Leave It to Google on Twitter. Thank you. Questions?