 Today's session is on OSF in the lab and what we really mean by that is how you can go about organizing related or complicated projects using some of the more advanced OSF features. Links, forks, and templates are going to be the big highlights today. I'm Ian Sullivan. I'm one of the transparency and openness training coordinators here at the Center for Open Science and I would be remiss if I didn't point out that the Center for Open Science, we're a non-profit organization. Our goal is to increase the reproducibility and integrity, the openness of scientific research in all fields. So that's our non-profit mission and as a non-profit we're always open to support individually or from institutions. So a lot of what we're going to be doing today is looking through some different example OSF projects so that you can get a real feel for how these different features that we're going to be talking about actually work and the different situations where you might want to use them. As the first step on that, I'm going to show you the one OSF project that you should take home with you today. This link is to one OSF project that we're going to be using as sort of the index for everything today. I'll show you what that project actually is. So this is our OSF in the lab project just for today's webinar. It contains a number of useful things. These are all the example projects that we're going to be looking at today. They are actually linked into this project here. There's some documentation in the wiki that points to help guides for how to actually use each of the individual features that we're going to be looking at today and the presentation that I'm going to be following today is actually stored in this OSF project. Once the video of this recording is complete I'll be uploading it here as well as to YouTube. So if you take this one project with you that'll be a good indicator of all of the material that we're covering today and hopefully self-documenting. So the big question is going to be how do you organize materials on the OSF? I'm assuming that you've used the OSF before or at least you've gone through one of our OSF 101 webinars. You have some idea of how to organize an individual project. That's generally what we start off with. So the big answer to this question is then through projects and inside projects components. So I'll take a look at our first example project here which is just a simple experiment structure. This is exactly the kind of thing that we go through the process of creating during OSF 101 or in-person workshops. You have a basic project with a couple of useful components. These components are actually nested. There's a raw data component here inside the data component. So this is the basic answer. You start off with a project. You can organize things within components. Those are sort of the elementary features of how you can organize things in OSF. There are some good advantages to that. Each of these components has a unique GUID which is in the URL. So you can link people directly to any of these individual components. You can have as many components as you want. You can nest them. Those are all very useful features. Let's see what our component summary is. So some great features of components is that they're nestable. Components are also very easy to configure. It's all built in. You can handle permissions and so forth. When you create the component, you can bring in the permissions from the top level project. You can add people to a project and then select what components they're going to have access to. All of that is very straightforward. But there are a couple downsides. The two big ones are that you can't actually move components within a project. So if you've ever needed to rearrange a project before, it's currently somewhat difficult. You need to create new components and move the contents. You can't just drag the components into different sections. And just fundamentally, components can only be in one place. So for our simple projects, that's pretty easy. There's data, for instance, and you only want the data in that one place. Once you start talking about more complex organizations, you may want to include or reference the same content from multiple places. If you are linking to all studies by an individual researcher, for instance, that may cross multiple lines of research or go between different labs. And so components are this very straightforward, kind of hierarchical tool that you can use, but it makes it difficult to sort of cross lines. Our big alternative to components is linking. When we look at an actual component, or an actual project, so here's our linked projects example, but on any project you'll see in the component section there are two options. The first is add component and the second is link projects. So you can populate this list of components in either way, either by adding a component, these are all individual components, or if we look at our OSF in the lab project, these are all links and you can differentiate them by the little link icon next to all of their names. Now linking has some different advantages. The first one is that you can connect to multiple places because you're actually just making a link rather than creating a component and then putting material in that component. You can make links to as many places as you want. That also makes it easy to arrange and rearrange a project structure. This is important if you're dealing with connecting multiple projects. You don't want to be locked into a particular organizational structure, especially if this is the first few times that you're using that structure or using that structure with that particular group. Everyone has different opinions and habits about how things should be organized. The disadvantages to linking is that it can make things a little bit more complicated to manage because what you're actually doing is, rather than having say five components in one project, you have five projects that you link together, that now means that you have five separate places that you need to go in order to manage permissions in order to make things public or private. So just you lose some of the handy features with components in an individual project where you can make those sorts of changes for all of the elements inside of a project at once. Once you break them into separate projects and link them together, you get a lot more flexibility in how you organize and connect those, but the management of certain things, mostly contributor settings and whether things are public or private, multiplies with the number of projects that you're dealing with. Another downside of linking is that it only shows connections in one direction. So if we take a little bit of our linked projects example, that'll become a bit more apparent what I mean. So this linked project example is really just designed to show you one of the ways that you can use linking to connect material into multiple places inside. So the idea of this project is to demonstrate multiple studies being done in a research line. So it's the same group of researchers, they're doing a series of studies and some follow-up studies all within trying to answer the same research question. And so the individual studies, we take a look inside one of these components. The individual studies are actually separate projects that we've linked together. So we've got studies A, B, C, and D in the initial studies component. This was the first round of studies that our example researchers conducted. And then one of those, study C, turned out to be most promising. So here in our most promising experimental line, we have study C as well as the series of follow-up studies that they did on study C. And so you can see that study C is actually linked in both of these components. Again, if we go back up, you can see another way that these are all connected. We have a component for each of the three researchers that's in this research group so that it's easy to see which projects that researcher contributed to directly. So if we click on this first one here, you can see that researcher Sullivan was part of A, C, D, and then the C follow-up study, but was not part of study B. And so all of these are connected in multiple places. And that's a couple of different examples of when you might want to link identical content into multiple places within a project. But as I mentioned, one of the downsides of links is that you can only see these connections from this main linked project example. So inside this component, I see all of these four studies. But if we look at any of the individual studies, so study A here is linked to our main project in three or four different places. But from the study itself, you can't tell that. There's no indication here of a connection between this project and the project that we have as the main organizing project for the whole line of research. So I've manually added that to the wiki and as part of the description. But unlike with a component, we just look at the component from the main project here, we don't have these handy indications built into the project that say this component is part of a larger project and providing links between those to make those connections more obvious. All of the things that I'm listing as pros and cons are entirely situational. One of the great things about linking as well as some of the templating and forking that we're going to be talking about later is that they can now can apply across the OSF. So your projects or anybody else's projects, if I wanted to pull together in this particular example, a list of a dozen other projects that other people have put together that I thought were useful examples of how linking works, I can just do that and my project will show all of them. But in this case, they probably don't want to show a link to my project because their research and their research organization has no real connection to me as just an individual user of the OSF. So for this example where all of the studies being linked are actually being done by the same group and we do want to show links in both directions, the fact that we have to add those manually is a negative but for the general purpose use it's not. That's going to be true for most of the pros and cons we're looking at here. So that's some of the basics of components versus linking. Does anyone have questions about what we've run through so far? So if you have questions, feel free to throw them into the Q&A widget at any time. Okay, so components and linking show two different ways that you can build connections inside a project and build up multiple types of structures to fit whatever your workflow and organizational needs are. Whether those are the straightforward ones of just hierarchical components or if you need something more flexible like linked projects. Both of those tools are really focused around how to build up the project yourself. That can be a lot of work that can be sort of a barrier to people especially in terms of just looking at a blank slate. Whenever you have that clean sheet of paper in front of you it can take a little bit of activation energy to move from nothing to figuring out an appropriate structure that works for you. Thankfully on the OSF you don't have to do it that way. In fact, I'm a big believer that copy and paste is the height of flattery. And so the other two features that we're going to be looking at today both templating and forking are ways of borrowing some of the existing work that people have put into building nicely structured OSF work spaces. I'm using that as the foundation for your own work. Some of the advantages of that is that you just don't have to build from scratch. That makes it easier on you if you find other things that you like or just if you build it up once and want to keep using that kind of a structure. We want to make it as easy for you to reuse that work as possible not make you have to do it again from scratch every time. The second advantage is a big one. It allows you to share pretty structured work spaces. And whether that's with your colleagues inside a group, other people within the lab or in setting like a classroom environment where you want to make sure that new structures that people are starting that you're working with people who are using the OSF or who you want to use the OSF for a particular project. And you're going to want their work to have common structures. There are a couple of ways in the OSF that you can just build exactly the structure that you want those to have, whether those are for a class project or just a new experiment in your lab. Build it out once and then just give it to people. Just use this and you will have everything in the right place so that you don't have to think through and recreate that each time. So there are two different ways to go about doing that with the OSF. And both of these apply to any project that you can see on the OSF. So we're going to be looking at some examples where an individual lab or a classroom sets that up for sort of internal use. But if you find another project that's just publicly visible on the OSF that has the kind of structure you want to use or is close to the sort of structure that you want to use, the same tools are going to apply. So you're going to be able to make a copy of that for your own use and change things around as you want. So just keep that in mind as we look at some of the examples. So the first one is templates. And these, I didn't even bother marking as pros and cons because they're just entirely situational. These are the important features of templates. Copying a project as a template doesn't leave any mark on the source project. It just gives you a new project with the same general structure. So that means the same components in the same structure with the same name. But it does not bring over any of the content from that. So you don't get the wiki pages and you don't get any files. It also doesn't bring over any add-ons that have been connected to that project. And so if we take a look at one of our example projects here, this is our lab example project. And this is built around using templates. The idea is this one common project for the lab contains all of the material related to working in that lab and running experiments there. That includes some common lab documents, notes from lab meetings, as well as a template for new experiments. So we have one question about the license statement for projects and how that relates to copying and pasting. So the license statement is actually a very good fit for the next topic that we're going to be looking at, forking, which is similar to templates. When you're copying a project as a template, since the only material that you get are the list of publicly visible components and the names of those, it's unlikely that the license is even really relevant. But you're right, that will be an issue for forking, where some of the publicly visible materials will come over. And that's mostly the wiki content and so forth. So I'll show you what this template looks like and then how to actually copy a project as a template. So here we are in the new experiment template within our lab example. And what this template has is a couple of important features. The first one is inside the wiki are instructions for what people should do. So this explains what's going to happen inside, how you should copy the template. If we look back up at the main lab example wiki, this has very complete instructions on both how to copy this as a template, which we'll go through in just a second, and what the accepted lab procedures are once you've made a new copy of the template. And we'll look over what some of these best practices are. One of them is just whatever you decide upon as accepted procedures within your group. If you're dealing with these sort of complicated structures, just document what your expectations are. Where should things go? How should people use the templates? What should they do once they've created one to make sure that it connects correctly back to the main project? So documentation is your friend, and just put that directly in the project so that anyone who is considering interacting with the template has an idea of how it works. So if I click inside the new experiment template, this has just the basic components that I would want for any experiment in this lab. And so what I do, the main button that's of interest up here is up in the top right, next to the make public make private button is this branching fork. And so if I click on it, I get two options. I can either fork this project or I can duplicate it as a template. And so if I click on duplicate as a template, it tells me that there's an add on here that's not going to get pulled over, which is fine. And what the OSF is actually doing here is making a new project for me that just has the basic component names. And here I can just change the title to brand new experiment. There we go. So that basic operation, finding something that I can see, and then clicking on the duplicate as template option is again available with any publicly available project on the OSF. On our lab project, what the instructions are actually telling us to do. Once I've created the new project, I'm going to go into the research component and then link that new project here. So I'll show you how we do this to add a link. Just like add component, just click on the add the link projects button. And here we get to search. So I'm going to search for brand new. You can either search all publicly available OSF projects or just search my projects. I'm just going to search my projects. And here we can see brand new experiment when I click add. Now brand new experiment is directly connected to this lab example research component. There's actually a lot of documentation inside this lab example. If you're interested in using this within a lab in particular, I encourage you to check it out. And again, it's linked from the OSF in the lab project that I mentioned at the very beginning. One of the ideas in using this structure, you can see a slight difference between the two linked projects here. And that's that my brand new experiment is private. So the idea is by having everyone in a lab connect all of their experiments to this central component, the research page can remain public. And this can be a public representation of all the research that's done at the lab or at least all of the research that's publicly visible. If we take a look at this inside an incognito window, you'll see that only the first link is actually visible. Only the example lab experiment shows up because unless I'm logged in, I can't see my private project, which is the brand new experiment. So everyone in the lab can connect their projects to this public page with confidence because no one will be able to see the connection until that actual individual experiment is made public. So this is a way where we can connect everything, make it available as sort of a central index for everyone inside the lab that does have access to those projects, while also having an easy way to make public or maintain the public list of research as those individual projects will make their way to a public audience. And a lot of that is documented in more detail inside this main lab examples project Wiki. So that's templates. As I mentioned, as we saw, it does not bring over anything from the main project. And if you want connections to show, you have to actually link them individually or document that. The second option, forking a project, is sort of the reverse or has the reverse features. When I say forking, it's helpful to think of sort of a forking path in a road, not a dinner fork, and not the kind of forking that you may be used to from Git or GitHub. What this really is, is a template that still maintains a connection and that brings over some of the material. But it doesn't share the full sort of identity that you get with a GitHub fork. So the main features of a fork on the OSF is that when you fork a project, it leaves a connection to that source project. You can always see from the source project what has been forked. And so you'll always have links from the original to the forked copies which you don't get with templates. Forking also will bring over some of the content from your project as well as any authorized add-ons. Assuming that you are the one who created or who authorized the add-ons in their original project and you're the one making the fork. So that feature is only useful for your own work. But if you have a common structure, that you want to use for your research, and that structure includes add-on connections to Google Drive or any of the other particular locations and services that you might be using, for instance, in our lab example, if you have a shared folder of common lab documents that you want all of those experiments to point at, as long as you're the one making the fork, those add-ons will come over. If other people don't, they won't have permission to bring the add-on connection into a new project. And so we'll just take a look at one of our forking examples here. This one is a classroom example. It's very similar to the lab example, except that the instructions are a little different. Rather than using the template, it's going to use the fork option. The idea here is you provide a template component for student projects. If we click on the template there, we'll see just three basic component names, as well as a much more comprehensive wiki that includes instructions that you want students to follow in order to add the professor as a backup contributor to this project so that they can see the work throughout the life of the project. The reason that this wiki is more extensive than the one from the template-based lab experiment is that when you fork the project, you'll actually bring over the main wiki page content relevant to that. So inside of this template, if we click on the fork option, there are a couple of different things we want to look at. We can fork this project and it'll go through much the same process as the duplicate template. But there's also this button at the bottom that says view forks. This gives us a list of all of the forks that people have made of this example. This is used in the context of a classroom exercise as a fallback mechanism so that even if students fail to follow the instructions and actively link their work back to the main classroom project, there's always a way to find those projects so that the instructor or a teaching assistant can always check and see if all of the template forks are appropriately connected back just as a sort of backstop to keep projects from getting lost if students forget things. Students forget things. It happens. So if we just click on the fork inside this template again, I'll show you the process of forking this. It asks to confirm. All right, so now I can go to the fork and here we have the same addition to the name. It's fork of the original template. I'll just change that. And in addition, inside or next to all of the component names, it shows us exactly when that project was forked in the main project information section here. It shows where things were forked from. It gives us a link back to the source project and when that fork actually happened. If we go back to it, we should be able to see that the number of forks has gone up. In view forks, we get a link of the new one and when it was created. So being able to have those direct connections is a big feature of forks, as is the fact that our wiki content came along for the ride so that in my new project, I still have the example materials. So this is a relevant point to bring up Yasmin's comment that if there is no license on the content that you're forking, you may run into an issue. So you should probably, when dealing with other people's work that's simply publicly available but not necessarily freely licensed, confine yourself to copying as a template if you want to use that structure. That's probably what you're going to be doing in any case since you're unlikely to also want the wiki content for unrelated research to be pulled into you and your new project space. But thank you for that question. That is a great point. So any questions about forking and templating and the differences between them or scenarios where you may want to use one versus the other? All right. So just a couple of basic best practices for these kinds of complex project structures. The first one I mentioned earlier is just document your structure and procedures and do that inside the project. It's incredibly easy to lose track of which project you want it to connect where, especially if there are differences in how you structure different collaborations that you're working using the OSF on. Documentation and keeping it contained inside the project for easy reference is a great best practice. The second one is just plan for people to join and leave your project. So this addresses or this refers to a number of different considerations. One is having backup administrators on additional projects. This is something that's spelled out more in detail in both the lab and the classroom examples. So when you create a new project as a template or as a fork, both of those recommend adding someone else from the lab or from the class as a non-bibliographic administrator on that project so that someone else always has access and can make changes if you lock yourself out or if people leave the lab. That's something that's going to happen sooner or later and it's best to plan for that proactively. I've got a question here about where I would recommend doing some of this documenting. Our example projects use the Wiki for that because they're example projects and that's the most prominent place for documentation. Depending on how you've organized the rest of your materials, the Wiki is always a great option. You may also have components within your project for common protocols and documents. That could be a good spot for a document in whatever format you're already using or since you have that as a separate component, it will have its own Wiki and that would be a great place just to stick this documentation if the main project Wiki with the template Wiki aren't the most appropriate place to put things because you want to talk more about the actual research that you're doing and draw attention to the aspects of that. So thank you for that. That's a great question. One of the other big things to think about whenever you're talking about sort of complex project structures you're more likely to be talking about complex teams, larger teams and part of planning for when people join and leave is thinking through your data management plan and how that relates. If people are going to maintain access to some or all of these materials should they graduate or get other jobs or be moved off that grant, who makes those calls documenting that as part of your procedures so that it's clear to all of the researchers what the expectations are and what the procedures are for contacting the PI to maintain access or establishing that clearly this can greatly streamline the process as people are involved in the always hectic job transition time. The last one I'm actually going to show you an example of before we go over in detail but the structure I tend to recommend is that you keep shared resources like those lab notes or IRB protocols or grant applications or anything along those lines that you keep those at the top level of your structure and that you keep the study content or the content for the different studies related to that project in self-contained components. So I'll give you an example of that if we look at our OSF in the lab we have this multi-site collaboration example and this one is built entirely using components there are no links or templates involved here but it's designed to showcase how you might use the OSF for a very complex multi-site multi-institution collaboration and if we look in the wiki there's actually a diagram of the project structure that'll give us an example of this so here you can see each of these boxes is a component and at the top level we have manuscript and literature review presentations and grant management we also have one that just says study and the study again has analysis scripts and protocols as top level and then individual sites as their own sort of hierarchies. Now I mentioned this and I recommend doing it with the common resources at the top because you could just as easily turn this around right you could have administrative documents as a component with all of these sort of ancillary materials attached to it and then site one, site two, site three as main top level projects. I recommend the version that you see on the screen here specifically because it makes pre-registration easier if I want to pre-register this study I don't need to worry about having all of these existing sort of administrative components get pulled along for the ride. I can register the study or register individual sites at any time and not need to worry about mixing in the administration so that's really the only reason that I prefer this organization as opposed to sort of the inverse but for the time being it's a great best practice to consider when thinking through some of these complicated project designs from the beginning. So any other questions? Yes okay so there was a question about that flowchart from the multi-site one so I use draw.io which is I believe a piece of nice free software that allows you to just store things locally and doesn't connect to any sort of monthly fee or account requiring setup. Thank you for that. I hope it is useful for you as well. This says the structure diagram is great. It is not currently possible to automatically generate this kind of structure. I will certainly take that as a suggestion back to the developers. You can get a quick view of the general hierarchy if we look at the main project page for this collaboration example from the files tree. So here you can see the top level projects and each of them allows you to expand below. So it's not nearly as sort of an attractive presentation as the graph but it does give you one place that you can look through all of the elements without needing to open up multiple components and sort of dig through. Okay we've got a couple other questions that are general OSF related. Does everyone you share a project with have to have an account on the OSF? It depends what you mean by share a project. If you want people to actually be able to edit the materials on your project, create components, work on the wiki with you, then yes if you only want them to be able to see the project what you can do is look at a feature called view only links which allows you to create a view only link of your private project and so people with the link can then see portions of the project that you've made available. You may also want to take a look at the add-ons feature which would allow you to connect files stored on Google GitHub directly to your project. If you're storing some of your materials in some of those external services people can edit them through those external services. You can collaborate with people through Google Drive and have that reflected in your OSF project and they don't need to have an OSF account but if you actually want them to be working in the OSF with you generally speaking they do need to have an account and accounts are free there are no limits attached to them so hopefully that's not too much of a burden. People can also log into the OSF directly if they have an ORCID ID they can use that instead of creating a new password. Okay we've got a couple more projects a couple more questions about these projects here. The first is do we have a feed to see the activity on a project? We have a list of recent activity down at the bottom of the page it's not a feed in the sense of connecting to an RSS or other sort of feed reader external program that you can use but it is a live feed of all of the actions on the project and so it's a single place to check to see what's going on and who's doing it. We I think there's a feature request to make that connect to some external feed reading capabilities but if not I will enter that in and the last question here is do we have an example about data sharing in OSF from other sources like Drive or Dropbox? I think we've recently put out a couple of examples and I think if the other one is the kind that you're thinking of so one of our other example projects is just called supplemental materials example and this is points to a number of projects where people do have material in primarily GitHub in this case but if you're looking for some more detail about the general add-on capabilities and how those might work in either simple or complicated projects you can also check out our recent OSF YouTube videos. I gave a webinar about six weeks ago on specifically how to connect all of these different add-ons and manage those permissions that has some more detailed examples so if that's all the questions just want to thank everyone for joining me today and again this video will be up in a week or two both on our YouTube channel and on this main OSF in the lab project files so we'll send you an email to let you know when it goes up and feel free to continue browsing these example projects I'm looking at some of the documentation there if you have any questions as always you can email us at contact at sos.io all right thank you very much everybody