This is an example project showing how the OSF might be used by a lab to create a shared lab space, share lab standards and resources, and collate the work that is being done by individuals/groups within the lab. # Getting started Welcome to the lab! This wiki contains the steps to take at key moments in the life of a lab like when someone joins the lab, when you start a new experiment or when the paper from an experiment is published. For documentation about day to day lab operating procedures or information about interacting with non-lab resources at the university, see the [Lab Documents](https://osf.io/q2und/) component. ---- *[**Design considerations**: The big consideration here is whether you want the main lab page to be publicly visible as a showcase of your work. You can easily have just the main lab project page and any linked publications or public experiments be visible to the general public while keeping your internal discussions, documents, and any unreleased experiment work private. In such a setup you would just move all of the following contents to the wiki in the Lab Documents section and instead use this page to give public information about your lab and the kind of work being done there. Most of the following assumes you are starting off using the OSF as an private ELN only accessible to lab members but it also highlights some best practices should you wish to use some of the public facing capabilities later on.]* ## When someone new joins the lab * Make sure they create an OSF account. * Add them as a contributor with appropriate access to this main lab project and all appropriate subcomponents. * **Researchers** All researchers should be given the default "read + write" access level to all parts of the main lab project. Adding everyone to the main lab project will ensure that all researchers are included in the lab's main citation information if we want to use this site as a lab showcase later on and also make sure that everyone can keep protocol and procedure documents up to date, participate in note taking at lab meetings, and other general activity. * **Assistants** Research assistants and others who may need read only access to these shared documents but who would not otherwise be listed as contributors on any of the publications coming out of the lab should be given "read only" access. Make sure to *uncheck* the "Bibliographic Contributor" box when adding these contributors. If we make this main project page public we can skip this step entirely since everyone will be able to read the page. If RAs are going to help with note taking during lab meetings they can be given "read + write" permission just for the [Lab Meetings](https://osf.io/43t8n/) component. * Make sure they read this wiki and review the policies and procedures in the [Lab Documents](https://osf.io/q2und/) component. ## When starting a new experiment If you want experiments in the lab to all have the same structure, you can use the 'template' feature in the OSF. We've created an example lab experiment template below. You can create whatever structure you want; the 'template' functionality will copy whatever structure you create into a brand new project, which you can then rename appropriately and add the materials/data associated with that particular experiment. Exact steps are outlined below. 1. Go to the [New Experiment Template](https://osf.io/n3qjs/) component of the Lab project. 2. Click on the little branch/fork icon in the top right like so: ![Fork/temlpate menu image][1] 3. Select the "Duplicate template" option from the menu ***Once your duplicate project has been created*** 4. Add everyone working with you on the experiment as contributors to the new project. Make sure to *unselect* the "Bibliographic contributors" option for any administrative staff or Research Assistants that would not normally be given authorship on the final paper. All co-authors should be given the default "read + write" access and you may want to give some "Administrator" access if they should also have the ability to add additional contributors and make decisions about whether parts of the project should be public or private. 5. Add at least one of the lab administrators who is not directly collaborating on the project as a non-bibliographic Administrative contributor to the project. This helps to make sure no projects get left off of the main lab list and that someone in the lab can always get access to the research materials should people leave the lab mid-project. 6. Go back to the "[Research](https://osf.io/6ga5m/)" component under the main lab project page and add your new project as a link by clicking on the "Link Projects" button in the Components section. ***Note*** that linking your project does not affect the public/private settings of your project. People viewing the main lab page will only be able to see the link to your project if they otherwise had access to see your project, either because they have been added as contributors to the project or because that project was changed to public. 7. Now that your project is connected and all collaborators have access, go ahead and change the name of the project to match your experiment. Simply click on the existing project name and you should be given a text box to change the name. 8. Enter your starting information about the purpose of the experiment and any information about your study design into you new project's wiki. 9. Finally, once you have your research question and plan details entered, this would be a great time to create a pre-registration of your project. More information about registrations is available in the [OSF Registrations Guide](http://help.osf.io/m/registrations) and this step is, of course, entirely optional. Note that all registrations eventually become public but the OSF allows you to set an embargo period of up to 4 years so that you have time to complete your experiment and proceed to publication. ## When your paper gets published *[A discussion of the many reasons you may want to make material about your experiment public is beyond the scope of this example project but, assuming you wish to publish something from your project in addition to the final manuscript, these are useful steps to take.]* 1. If your author agreement allows it, consider adding a pre-print, or post-print, version of your manuscript to your OSF project for that experiment. You can do this either in the Manuscript section or by simply adding a file to the main project storage. For the most up to date general guide to publisher policies on pre- and post-print distribution policies, see [Sherpa-Romeo](http://www.sherpa.ac.uk/romeo/index.php). 2. Review your project files for publishing. Make sure that any sensitive data is moved to separate components that can remain private. **Note** that if you are going to *register* your project you may need some more extensive rearrangement of materials within your project. This is because registering a project makes a public copy of *all* materials underneath the project or component you are registering, including ones not normally public. This can safely be accomplished by creating parallel "public" and "private" component trees under the main project and then only registering the public tree rather than the project as a whole. 3. Once you have verified that the project data can be responsibly shared, click the "Make public" button at the top of the project page and select which portions of the project to make public. 4. Consider adding tags using the tag widget to add relevant keywords and phrases to your project that will help highlight key aspects of your work for someone searching through the research in your field. You can use different keywords on each component or simply add all of them to the top level project page. 5. Once your project is public you can also request a DOI for the whole project or any of it's public components. Simply hit the DOI request button that appeared under the project/component name and description. 6. Make any post-publication registrations you wish. 7. Share widely! You can safely add your project or paper's OSF address to your CV; those addresses are persistent and globally unique IDs. ## When someone leaves the lab Make sure when graduation time rolls around or when researchers move to new institutions that you update the contributors list for the main lab project to remove anyone who has left. You have a couple of options for what to do about any currently open experiments they might be working on. Choose the one most appropriate for how much they will continue to collaborate on those experiments in the future and what the norms for authorship attribution are in your field. *[**Design consideration**: These are offered to outline some the general options. More information about the user permissions, along with detailed instructions on how to set them in your project, are available from the [OSF Privacy Controls Guide](http://help.osf.io/m/projects/l/526695-edit-contributor-permissions)* ### Option 1: Do nothing Most appropriate when you will maintain ongoing collaboration on an existing experiment. If you do nothing about permissions on currently active lab projects then departing lab members will maintain all their abilities to collaborate on those projects and will remain listed as co-authors for that experiment unless they were already marked as "non-bibliographic contributors". ### Option 2: Restrict access but maintain authorship Most appropriate when the departing lab member will no longer be actively collaborating on ongoing experiments but when they have already made sufficient contributions to merit being listed as a co-author according to the norms in your field. For any open projects where you wish to preserve an authorship credit for a departing lab member but want to remove their ability to make further changes to that project on the OSF, simply change their permissions in the Contributors settings for that project and all relevant components in the project to "Read only". They will no longer by able to change anything about the project but their ability to see the project will remain and they will continued to be listed in the authors line and citation tool. ### Option 3: Remove all access Most appropriate for situations where departing lab members have not yet made sufficient contributions to an experiment to warrant being listed as a co-author and will not be making contributions in the future. To remove all access and authorial credit on a project, simply remove the departing lab member from the contributors list on that project. They will no longer be listed as an author or included in the citation tool. If that project has not been shared with the public yet, they will also lose all ability to see the project. [1]: https://mfr.osf.io/export?url=https://osf.io/8bk4c/?action=download&direct&mode=render&initialWidth=554&childId=mfrIframe&format=1200x1200.jpeg