 Hi, I'm here to talk about linking Zenodo and GitHub. So Zenodo is a data repository, which basically means it's designed for storing data long-term. GitHub is a development platform, which means it's designed for data that's actively being updated in particular code. So why would you connect them? Well, if you are actively developing something, you also want to make sure that it will not be lost, especially if it's something scientific. So luckily there's an easy way to connect them together. Let's take a look. So here is Zenodo. This is sandbox.zenodo.org. Since Zenodo is permanent, I don't want to use the main Zenodo for practicing. And that's why they nicely made the sandbox. So below we see all of the data sets that have been uploaded. So you see the date is quite old here. I guess that's just sandbox. The real Zenodo is very active. So I'm logged into Zenodo. And here on GitHub, I'm logged into my account. And I would like to archive this board game network site. So let's get started. In Zenodo, I come and I go to my account and I click on GitHub here. So there's a nice big connect button here. So let's push it. Last time I was here, it didn't quite work, but let's see. There we go. So now I'm in Zenodo and it's connected. So let's see. It tells us how to get started, but it's pretty easy. We don't even need to read. First, there is on connected. And now it lists all of the repositories that I have in my account. Or actually all of the accounts that are connected to me. So within here, I will search board game networks. Here we go. So it looks like I've already connected this for the practice and it still remembers that somehow. Well, let's just ignore that. So I flipped the switched on. And that's basically it from the Zenodo side. Let's come back to GitHub here. So here I am. Here I am. So we see there's already one release from the previous example I did with this. Let's look at the settings. So if I go to web hooks, you notice it's sandbox.zenodo.org is here. And that's how I know it's actually working. So let's come back to code. So under releases here, we want to make a new release. So if I click here, I can draft a new release. Let's call this 0.2.0. And I've done some work here. Let's see, how would I describe this release? So this is the metadata and we want to make sure that this is updated and is useful to someone coming back later. Let's see, what would we call this? So here I've, so I've said I've updated the data and also the website and build process have been updated. So this here is to get tag version and we're tagging the release on master. This is the title of the release. So let's see, preview there. Yeah, okay. I'm not gonna say this is a pre-release and let's do publish release. So there the release has been made. So I guess I can go to all releases and yeah, I see 0.1.0 and 0.2.0. And if I come to Zenodo and click on here, I see there's two releases, 0.1.0 and 0.2.0. And I guess if I go to my account, I should be able to see that within Zenodo somewhere if it works. So what are some other considerations here? This will only save the source code and perhaps any other release artifacts you may make. And this means that, oh yeah, here we go. I've got the board game that works here. So if I click here, I see there's the repository and then all of the files inside of it. So in this repository, it builds network files out of this raw data here. And it's not archiving those network files themselves. So that means that you have to make sure whatever code or data you store here is reproducible. So since this is a Python code, I have a requirement.txt that tells me what kind of other dependencies are needed to make it and there is a make file that says how to make the raw data. But this is something else to consider. So how to make the code or data itself reproducible or reusable so you can recompile it or rebuild it or whatever you may need to do. And that's basically it. So it's a very easy thing to do. So when would you do this? Would you do this for every repository? Would you do it for only ones that you think are needed? Would you only do it when you publish it with a paper? Well, that really depends on your use case. So it's probably a bit much to do this on every single commit you make, but doing it on everything that you consider or release or published version or every few months would be pretty reasonable. Thanks a lot for listening.