 Okay, so hi everybody. Welcome to today's webinar on Connecting Research Tools to the OSF. My name is Ian Sullivan. I'm one of the Transparency and Openness Training Coordinators here at the Center for Open Science. So, by this point I'm assuming that you're all users of the OSF or at least that you have an account on the OSF and have created a project or looked around somewhat. We're going to be focusing specifically on one portion of that. So, if we're covering areas that you haven't seen before like creating a project or adding components, things like that, the best place to catch up on that material is the recent OSF 101 webinar, a video for which should be going up shortly, and older versions of which we have from last semester already up on the YouTube channel. So feel free to follow along there if that's more information you need to map with what we're doing today. So, the OSF is designed from the beginning to support your research through this whole research lifecycle. It's just an abstract research lifecycle that we put together. That's our goal. But there are a lot of moving parts there and a lot of different components going along with different stages of your research lifecycle. And we realize that you may already have some tools that either you prefer using at different stages, that you're required to use at different stages, either by your institution or other people in your lab or collaboration, perhaps even a grant or a funding source that mandates particular tools. So rather than convince you to abandon all of that and do everything through the OSF, the OSF is designed with a feature called add-ons, which allow you to directly connect some of those tools that you are already using into your OSF project. So rather than just this research lifecycle with OSF at the center, you may have something more along the lines of this, where a wide variety of tools that you're using for different purposes are all pulled together through the OSF so that you have a more comprehensive picture of the work that's going on in your particular research study. So add-ons, that's the name of the main feature that we're looking at here to connect these different tools to the OSF. It allows you to connect your favorite tools directly to your project. Now we're going to dive straight into a project and show you how you can go about doing that. And we'll talk about some of the currently supported tools, future tools that are coming down the pipe a little bit later. And we'll look at some of the mechanisms at play here in terms of what each add-on can do and what add-ons is a whole offer to your OSF project. So let's switch on over to my example OSF project. So here I have a relatively fresh OSF project. I've given it a name. I've added some components here. I'm actually just going to rearrange these a little bit so that they make a little bit more sense to me. But as you can see from the files tree, I haven't actually added any files or other materials to my project. So I'm going to start off by just adding a couple of those directly to OSF storage, let's say under the materials component. So I'm just going to click on the OSF storage under materials, and that gives me my upload button. And now I'm going to go ahead and add in just a couple of these document files. So that's pretty straightforward OSF storage usage. But perhaps some of these other components are ones where I'm using other tools. Please magnify, short thing. There we go. So my materials may be relatively straightforward and I can put them straight on OSF storage. The analysis scripts may be much more complicated. Perhaps I'm using GitHub to manage editing these and keeping versions, perhaps collaborating with a number of my colleagues through the much more featureful or complicated Git-based collaboration model. So what I'm going to do is I'm actually just going to connect my GitHub repository for these scripts directly to the analysis scripts component of this project. You can connect add-ons either at the top level of a project or within any component. So let's go to the analysis script section there. You find add-ons in the settings tab of your main project toolbar. So my first step is going to be a click on settings. And you'll see here that we have a list of different add-ons that we support. This is the current list. There are some external tools that integrate as well. But let's start with what we have here. There's a question about having missed the introduction. Don't worry about that. The whole workshop is being recorded and will be available in a week or so. If you're missing anything in particular about what we're doing, feel free to just ask that. Okay, so here I am. I want to connect my GitHub repository with analysis scripts. So I'm going to check the GitHub option. And what I have here is a term sheet for this particular add-on. This breaks down everything that's possible for this service when we plug it into the OSF. What we're doing when we connect an add-on is we're connecting these two pieces of software together directly. And the software is designed on both sides to make some of the various things possible and others aren't. So this breaks down. For instance, I can add and update files either on the OSF or on GitHub and it will be reflected in both places. And really it just shows you the list of what's possible for each add-on. This is going to be different for all of the add-ons. So you should take a moment to review these terms for any of the add-ons that you are going to use commonly. So I'm just going to confirm this here. And once I've now enabled this GitHub add-on, it appears underneath in the configure add-ons section. So the next step is to click this import account from profile button and confirm. And what I get now is a list of my different repositories that I can select from to include in this particular component. So that's going to look a little different for you the first time that you connect a particular add-on wherever you're connecting it to. The first time it's going to take you to that other services website and you're going to log in that way and confirm that you do want to allow the OSF to connect to that service. You only have to do that once per service that you use and then the OSF remembers that. And you have the simpler version of the interaction that I just went through where all I have to do is confirm. And now I have this list of options. So I'm going to go ahead and click... Yeah, that sounds good. One particular repository. Now it's important to know that I'm the only one that's going to see this whole list of the repositories that are under my GitHub account. And this is true for any of the add-ons that you connect to an OSF project. The part that you connect directly, so this one repo that I've connected, becomes visible in the project. But regardless of, you know, other contributors to this project, whether they're ReadWrite or Admin or whatever their level of permissions, none of them are going to be able to see the other material in my accounts. So they're not going to know that I have a thousand other GitHub repositories that are not connected to this particular project. So we've selected one, we've hit save, and it tells us here that our setting has been updated. And now if we go back to the analysis scripts component, we'll see that under files, not only do we have OSF storage, we also have this particular GitHub repository. It tells us the repository information, and we can see all of the different files here. If we go ahead and click on one of those files, just loading up, we can see that this looks just the same as it would if this file were stored on OSF storage. So this is an R file, we render it here. There's a little note up at the top, because this project and this analysis scripts component is private, but I've connected a public GitHub repository to it. So this is just alerting me to the fact that people are able to see these scripts if they search through GitHub, though they can't see them on my project unless they're contributors. So a couple of things to note here about the individual file view. This file lives on GitHub, but because we've connected it to the OSF, and now we're looking at it here, it has the standard OSF GUID. So all files that are connected through add-ons get unique permanent GUIDs, just like the files that you add directly to the OSF. This can make citing and pointing people at particular files significantly easier than a lot of these other services where the URLs can be quite long and sort of difficult to parse through. So in addition, because this is a plain text file, R scripts, text script files, and markdown files are all plain text files, I can make use of the OSF's built-in edit functionality, and if I click on edit, I'm able to make changes here, a little comment at the top and hit save. So that process works exactly the same way as it would for a file if I stored this analysis script in OSF storage. And because of the ways that GitHub and the OSF cooperate when they're connected, this change that I've made through OSF is going to be directly visible through GitHub. So a change made in one place immediately moves to the other place as well. Not all of the add-ons work that way. That's one of the things that's spelled out in the term sheet that pops up when you go to connect an add-on to a particular project or component. So I'll show you another example of that, and then we'll come back to how that GitHub connection works because there's another important point there. So we've connected our analysis scripts to GitHub. Now perhaps we want to connect our manuscript section. Let's just go down to the manuscript component. And perhaps we are in the habit of collaborating with the rest of our team using a Word document that's kept on Google Drive. So what I'm going to do here in the manuscript section is I've gone to the relevant component. Once again, I'm going to go up to settings and scroll down to the add-on section. This time I'm going to select Google Drive, and we've got a different term sheet here that covers many of the same options. Hit confirm, and now I have the option to configure the Google Drive add-on. So I just hit the import button, confirm that, and then I get to choose what section or what folder in Google Drive I want to connect. So here I'm just going to connect the demo project folder and hit save. So that's complete, and if I go back up to the manuscript component, you can see that in addition to OSF storage, I now have this Google Drive folder, which also has many of these example files. So if we go ahead and say, well, this is not exactly where I want to keep all of these materials. So I'm just going to go ahead and head over to my Google Drive. So here is that same demo project folder that we just connected to our manuscript section. And in fact, what I want to do is get rid of most of these other files, the CSVs and the analysis scripts. I'm just going to go ahead and remove them on my Google Drive folder. And now if I go back to my OSF manuscript component and reload the page, we'll see in the Google Drive folder that those files no longer appear. So changes work in both directions. So we've got a couple of questions here that are relevant. The first one is, can the same Google Drive folder be connected in multiple projects? This gets to a great issue of what can be connected where? The short answer is yes. The same Google Drive folder can be connected in multiple projects or multiple components. The other thing that that touches on is how many add-ons you can have connected to any individual project or component. And the only restriction here is that you can only have one of each type of add-on connected in an individual component. So right now I've connected this Google Drive folder. And I can't connect another Google Drive folder into this same component. What I can do is I can connect a Google Drive, you know, if I have multiple Google Drive folders, I can either create sub-components and then connect different Google Drive folder into each of those sub-components or just use higher-level components and use names to highlight, oh, these are, you know, Ian's Google Drive files or what have you. However, within this component I can have one of each of the different types of components. So I can have a Google Drive folder and a Box folder and a Dropbox folder and a GitHub folder. And all of those can be connected inside this single component. That doesn't fit with how we've laid out our current project. We probably don't need Google Drive and GitHub both for our manuscript section. So I'm just going to connect the Google Drive one here. The second question is actually the point I wanted to get back to about that GitHub edit that we made a second ago. So if you're familiar with GitHub, then you'll know that one of the important parts of the Git version control system is keeping track of who makes what changes when. When you connect your GitHub account to the OSF, any changes that are made through the OSF go into that GitHub repository as you. So that change that we made to the analysis script was registered as a commit from GitHub and it was automatically accepted into that repository in GitHub. This brings up an incredibly important and powerful feature of add-ons. Add-ons allow you to manage permissions in a centralized location for multiple services. So anyone who has read-write access or administrator access to the analysis scripts component can now make changes to the files in this GitHub wiki. The same is true of the files in this Google Drive folder. Anyone that has access to either read-write or administrative permissions on that manuscript component has the ability to make edits to the documents in that folder to add new files to that folder or to delete files that are current there. Now this can be incredibly useful, especially if you are on a team that has people using multiple tools or where not everyone on the team can agree on which tools to use rather than having everyone have to have multiple different accounts on all of the relevant services and then handle sharing and permissions on each of those different services. You can connect them to components on an OSF project and then just use the OSF contributor settings in order to control who has access to what. So if for instance I want to make changes, I don't want everyone on this project to have the ability to make changes to the files in my GitHub repository. All I have to do is let's go into that analysis scripts component and if I go up to the contributor section, I can simply remove the right access for my two contributors. I'm just going to switch Courtney and Jennifer to read only and hit save. So now they both have access to all of the materials that are in that GitHub repository but they can no longer make changes that will be directly reflected in it and that's a very common configuration that we see people use with GitHub. If you're using Bitbucket, which is another one of our version control add-ons, that's actually only read only so it's not possible to make changes through the OSF that are reflected there and that's spelled out in the term sheet when you connect to Bitbucket repository. But even just with this sort of read only access, we've pulled all of the different materials from these different tools together into one place and we can use the OSF to organize and coordinate the activity in the project and you get some of the other benefits like the short GUIDs for each of the files that you get from the use of OSF as a whole. Okay, so a couple of questions here. So one related to permissions management. What happens if people change authorization rules in the add-on tool? Do those changes propagate back to the OSF? So I think what you're asking there and correct me if I'm wrong is if you change the permissions on say the Google Drive documents, is that going to change who has access to them in the OSF? And in that case the answer is no. When you connect the two services, you're telling Google Drive to give the OSF permission to access your files similar to the permission that you have. So the OSF is able to provide a second way for people to access the files that you then connect through the add-on process to a particular project or component outside of the normal permissions and sharing settings that are made generally possible through those other projects or those other tools. Which means that if you change the Google Drive file here to be only viewable to you, that's not going to affect my two contributors on this project who have access through the OSF to this component. That also means that in reverse, as I was saying, you can use the OSF as a way of centralizing these sorts of permission management so that I don't now have to go to this Google Drive folder and share each of the files individually or share the folder with my two contributors on this project. So they don't even need to have Google accounts. They don't need to have GitHub or any of these other service accounts in order to get access to the files. Once I have taken the step of connecting them to the OSF through one of these add-ons. This can really be a very powerful way to coordinate multiple tools across a team without needing to handle permissions on multiple different services, which can certainly be time consuming. I think that answers a couple of the questions here. There's a more detailed one about GitHub and how changes made through the OSF fit in terms of merge conflicts and so forth. Changes that are made through the OSF are directly accepted into the master branch of whichever repository you've connected there. So unless you've got two people simultaneously trying to save, the OSF is just going to go in and then you'll have to handle any merge conflicts through GitHub with the other changes that are causing the conflict. Which again, I think is part of why we so often see people set GitHub as read only. If you have a lot of contributors or really even just more than one contributor that are collaborating through Git already, there are a lot of different features of that workflow and the sort of complex branching and merging that you can do with Git that are not handled by the OSF and the OSF version control. But being able to make all of those materials directly available inside an OSF project to people who are not already Git or GitHub fluent can be a big benefit and certainly allow the people who are in this case developing the analysis scripts to develop the analysis scripts using whatever workflow and component tools they are most comfortable with and then just provide the fruits of that labor to everyone else on the team. Okay, so we've got a question about the version history. This is actually a great next step. So I'm going to go ahead. I've got, let's see, the data dictionary here. And if I just open up that data dictionary, this is the file I just uploaded a second ago. Complicated data dictionary. And I make a change and hit save. So I am now going to, through the OSF, upload that change data dictionary file. So the OSF is going to recognize that I mean that's to be a new version of this data dictionary. And if we look at the file through the OSF, it lets us know that this file is on Google Drive. But we can see in the revisions tab up here that there were two different versions made when they were made. So if I go back to view, you can see that the most recent version is here. It's going to work the same way if you make changes through Google Drive. Which of the different add-ons provide the OSF with version change information is spelled out in that term sheet that you see when you first connect the add-ons. So Google Drive and GitHub both provide us with that revision information. As does Dropbox, though unless you're a paid user of Dropbox, it only stores the most recent 30 days worth of versions. So that's one of the sort of considerations that you might want to take into account when you're deciding whether or not to keep your files on an external service like Dropbox or OSF where we keep all of the different versions of files that are made. Go back to the main project there. Okay, so there's one question about connecting other systems that are not on our list and is the API the best option there? So yes, all of these add-ons are actually just programmed towards the API, which stands for Application Programming Interface. That's the way that software applications talk to each other. So what's happening when you connect an API is that the OSF's API and say GitHub or Google Drive's API are talking to each other. And the different things that are possible which are spelled out in that term sheet are the things that the APIs for different services allow. So for instance, GitHub would give us every version of the file that has ever existed, Dropboxes will not. So we've got one more different add-on here to show you. This is one that's not a storage add-on like GitHub or Google Drive to give you an idea of what that looks like. If we go into the literature review, you certainly may have a literature review that consists of folders full of PDFs, but you may also be using a citation management tool. So if I go up to Settings again to connect an add-on, I'm going to click Zotero here. And this term sheet is very straightforward. It says that it explains permissions and forking and registering. You can't make changes to your Zotero folder through the OSF. So this is just a way of pulling your Zotero collections into your OSF project. So if I configure this one, I'm going to select this one Zotero collection and hit Save. That's all been saved. And now in addition to the files section here, if we scroll down, not when the main project page, in the literature review component where we just connected this, underneath the files page, we now have a Zotero page as well. And this has all of the different pages and items that I have in that particular Zotero connection. And I can do a couple of things here. I could change this citation style for all of the elements in that connection. So I can make this MLA and it will just convert all of those. I can copy the citation for each of these. Or I can view the original document as pulled down from the Zotero collection. So this is a whole another tool that's been added. And I can then sort and browse through those materials as part of my OSF collection without needing anyone to have a Zotero account or remember where to go and look for them. So those are some of the different types of add-ons that are currently supported. So there's one question about the private public settings on this. Is there any indication on the Google Drive side that a private document has been made public via an OSF connection? To the best of my knowledge, there is not. The only one that is able to connect some materials even add-on to the OSF is generally someone who owns those materials or has the relevant permissions. For instance, my GitHub repositories are the only ones that I can connect to this. If somebody else on the research team owns the GitHub repository where we're keeping a canonical version of those scripts, they are the ones that would have to connect that directly. So it's really about only allowing the connections to be made when someone who has the authority and the knowledge to do that is actually making the connection. So there's no indication on the Google Drive side if some of your documents are shared because you're the one that's going to be sharing them. Though it's certainly possible that you would also use the Google Drive sharing mechanism so that we might be collaborating on shared documents. And I wouldn't necessarily be able to tell that you had shared that document through the OSF in the same way that I might not be able to tell that you had shared it through other mechanisms. One last question about GitHub. Can someone that does not have a GitHub account commit changes within the GitHub add-on in the OSF? And yes, the changes will go through if they have right permissions for the component where the GitHub add-on is connected. So in this case, the analysis scripts, any of my contributors who have right permissions in that component will be able to make changes to the files connected through the GitHub add-on to that component. And those changes will show up as if I had made them because I am the one that authorized connecting those components. So the GitHub questions come up a lot and that's actually why we use GitHub as one of the main things to present here. It's certainly a lot less tricky with Google Drive or other tools that have less complicated version and collaboration mechanisms. There's an initial sort of reluctance with GitHub or any of the more complicated tools to provide that kind of right access. And that's why we like to bring it up and suggest that you can connect this directly to, you can connect a GitHub repository with, say, analysis scripts directly to the component in your OSF project. But the choice is completely up to you as to whether or not you want to use the potential for the OSF as a way to make changes to the materials in that repository. If you want to keep everything in Git and still provide the other people in your team the ability to make changes without also requiring them to learn Git or have a GitHub account, the OSF is a way to do that. But if you don't want to do that, you can just change the permissions on that component so that you are the only one with right access. And the materials can still be made available and included in the whole project so that you can use your OSF project as a centralized dashboard to sort of see all of the different materials and all of the changes to them that are being made across the research team through this work. I'm not sure I fully answered the question about tools that are not yet supported, but let's actually take a look at that right now. So just a couple of the benefits being able to use the OSF project as a dashboard as I just mentioned. In addition to short GUIDs for all of the different files, anything that you connect to the OSF through an add-on will also be included in any registrations that you make in, you know, of that project or of those particular components. So if you want to make a registration of your project, but you're not storing everything in OSF storage, that's fine when you make that registration will pull in copy of, you know, the most up-to-date copy of all of the files that are connected so that you can easily show the state of the data that's stored on Amazon S3 and the software and analysis scripts that are stored on GitHub. In addition to the materials that may be stored in OSF storage or Google Drive, all of those will be pulled together when you make a registration of that project, which is a very nice way of taking a snapshot of the full state of development and change in the project and the centralized permission management that we've talked a bit about already. So these are the tools that are currently OSF add-ons or that iterate directly from the external tool into the OSF. There are a number of different storage options, both for live sort of data like Google Drive or GitHub or S3 or sort of end-of-life repositories like Dataverse or FigShare, a couple of the different citation management tools and a couple of experiment operational tools like PsychoPie. We just released BitBucket, that came out I think about four or six weeks ago. We've got a couple more coming down in probably the rest of this year. So in the next few months it will move to this with the addition of OneDrive, GitLab and Dryad. And we're looking for the beginning of next year or soon thereafter. We're going to add a few more of these. So Microsoft Azure, Swift and Evernote, those are all ones that are being actively developed by our team. And again all of these are using the publicly available API. If you're interested in writing one of these yourself or just if there are services that you are already using that are not already mentioned here, but that would make it much easier for your life in doing research. If you could connect to the OSF, please do let us know. We want to hear from you that's how we evaluate these new services and prioritize where to put the effort in development. And certainly if you're interested in doing some of the development yourself, the OSF is a free software project and the API is publicly documented, but we would love to hear from you and offer whatever help that we can. So any questions about what we just looked at or things that you want to look at in the example project? Alright, so once again all of this has been recorded and we'll try and get the recording up in a couple of weeks. If you have any other questions, feel free to reach out to us. The email is help at osf.io and my name is Ian Sullivan. Thank you very much for joining us.