NAVIGATION
The Lab Wiki on Notion complements the information provided in this manual. Lab members are expected to keep the Wiki up to date by editing and adding entries as needed. It contains logistical details, like lab housekeeping, relevant forms, templates, program timelines, how-to guides and tips, and helpful articles. If you notice any inaccuracies or discover a useful strategy, directly edit the Wiki. Having written documentation of random things you’ve needed to figure out will save you and other members time later.
When communicating as a “representative” of the lab (e.g., with participants), use the shared lab email: poislab@louisville.edu. When you join the lab, you will be given access to this Outlook account as a delegate, and you will be able to send and archive emails in this account. A few procedural notes:
Scheduled lab meetings (e.g., weekly lab meetings, monthly status updates) and lab-related availability (e.g., for running participants) should be added to the lab ‣.
Individual and project meetings that don’t involve the whole lab are managed using Outlook calendar invites. I strongly recommend integrating Outlook into your calendar system rather than copying events to your personal calendar as you might miss updates, including last-minute rescheduling.
You don’t need to ask permission for time-off. However, it is your responsibility to get coverage for any time-bound tasks (e.g., participant tracking). Do this as far in advance as possible as a courtesy to whoever will be covering for you and at least 1 week in advance. Once you know your days off, please add them to the ‣. Because lab projects often involve multiple members, it’s helpful to keep the lab apprised of when you’re out of the office so we know not to expect replies or progress on tasks.
A lot of academia is rejection. We get rejected from programs, grants, scholarships, journals, conferences, and so on. Yet, we don’t talk about rejection often, as least not as often as we highlight accomplishments (which are important to celebrate too). As a result, rejections can make us feel lonely, like we’re the only ones who can’t get it together when everyone else is breezing through academic life.
The ‣ is where we “collect” our rejections and celebrate them. We celebrate trying hard, going outside our comfort zone, and exposing ourselves to external judgment when we could have chosen to avoid it. Mostly, we celebrate the willingness to be vulnerable, to let others know they’re not alone, and that so much of our journey is about failing—and that’s OK. To paraphrase Jimmy Chin, it’s important to fail and to fail early.
All lab projects are managed on Notion. This means information, tasks, meeting notes, etc. related to studies are housed in Notion. This way, anyone who wants to learn about a study can find everything they need from the Notion project page. Notion keeps tasks organized and helps us track progress on projects easily (see guide for using Notion). Also, organizing workflow by project minimizes task switching, which hampers productivity.
While general project information is in Notion, documents related to projects are kept in CardBox. Partly because CardBox is secure (only accessible by certain users) and partly because Notion is not a great storage management tool. All lab-related files should be saved to CardBox, not locally on your computer. Link CardBox files in Notion to streamline project management. That is, all projects and related documents should be accessible via Notion without having to search on CardBox.
To start a new project, you’ll need to submit an IRB protocol and get it approved by the IRB. You can only work on projects and access study data if you are on a currently approved IRB protocol—no exceptions. Lab members on a project must familiarize themselves with the IRB protocol and ask questions if study procedures are unclear. We want studies to be run consistently so our results are valid. If procedures change, submit an amendment so your IRB protocol remains accurate.
If you run into any issues involving participants (e.g., breach of confidentiality, participant is upset), please let me know immediately. In fact, even if you’re unsure about whether you need to tell me, let me know anyway. False positives are better in this context.
Keep shared lab folders as organized as possible because different people will be accessing those files at different times (even after you leave the lab). For the same reason, include a README.txt in each project folder that includes information on the study, organization scheme of the folder, and links to any other information relevant to the project.
Use the following structure (a template folder titled newProject is in Box):
Use CamelCase and underscores for file naming. Avoid spaces because not all systems read spaces well. In addition, generally, files should use the following format: StudyName_ParticipantID_FileType_Date. That way, we know what study the file is related to, what content it contains, and how recent it is. If you see a file that is named differently, please correct it to this format for consistency and legibility.
As soon as is feasible (ideally before starting a study but, in some cases, before data analysis when using secondary data), preregister your study design and proposed analyses on OSF. Preregistration can increase confidence in reported findings but also forces us to be more thoughtful about study objectives and methods to meet them. Remember that you’re part of a team, so ask for help and guidance if you need it. Trying to perfectly design a study by yourself is stressful and inefficient.
At minimum, your findings should be reproducible, which means if someone else runs your code with the same dataset, they should get the same results. Reproducible research is the bedrock of a reliable science, so it’s important that you check that your results are replicated with the same dataset. (Replicability more broadly refers to getting consistent findings with a different dataset.)
Making your research reproducible requires high levels of organization, attention to detail, and dedication to documentation. Remember, another person who does not know how your brain works needs to be able to get the same results with the same set of raw data. Thus, you need to make extensive notes on every step of your analytic process: what you did, how you did it, and the order of operations. This includes liberally commenting your Rmd code and using version control to track when and why changes were made (e.g., using a clear and concise commit message on GitHub). Be as explicit as possible about your methods.
At the end of a project, upload de-identified data, study materials, and final Rmd code to the Open Science Framework (OSF). Be sure to check with me before uploading any data. Sometimes we collaborate with other labs and don’t have permission to share data or we are sharing clinically sensitive data and need to check files thoroughly before sharing.
I also encourage posting preprints (manuscripts prior to submission) and postprints (manuscripts after peer review but before publication) on PsyArXiv before they are copyrighted by journals. This allows our research to be easily accessible by others.
Generally, if you spend effort (e.g., ≥2 hours) creating something others would benefit from having access to (e.g., measures, treatment protocols, and therapy worksheets), use a Creative Commons license. A Creative Commons license lets people know what they’re allowed to do with your work and circumvents the barrier of tracking down a creator to obtain permission for use.
Consistent with APA guidelines, authorship is determined by individual contribution to a study. The person taking the lead on a study is first author by default, unless they hand off the project to someone else. I will be last author on studies led by students and supervised by me, as long as I meet criteria for authorship outlined by APA.
Generally, contributing to study design, running statistical analyses, and writing sections of the manuscript warrant authorship—running participants usually does not. Other lab members who help with a project in some meaningful way may be added to the author list as well. Although not required by APA, I expect students to contribute to some writing in a manuscript as part of authorship, so they develop their writing skills and learn about the publication process.
Order of authorship will be discussed with everyone as soon as is reasonable (e.g., once roles have been outlined), but this may change depending on how responsibilities shift throughout the project. Either way, initial and subsequent discussions of authorship should include all named co-authors. If you have concerns about authorship, please bring it up with your project lead or me at any point.
If the original lead relinquishes ownership over a project, first authorship may be transferred to the person who takes on the lead role. Leading a project primarily entails seeing it through, so whoever sees a project through to completion (e.g., publication) typically will be given the first-author role and this may not be the person who started the project. The original lead will likely stay on as an author so long as they have done enough work to qualify for authorship.
For the most part, R (run through the RStudio interface) is the preferred statistical program because it is open-source, incredibly powerful with the right packages, and facilitates code sharing and reproducibility. The R learning curve is steep and analogous to learning a new language, but once you understand R grammar (tidyverse helps tremendously), you’ll be able to troubleshoot and figure things out a lot more easily. The Lab Wiki has resources for learning R; they’re a good starting point for getting into the R universe.
GitHub offers version control and is helpful for tracking various versions of your work, especially Rmd files. It can also be used to share data and code in a public space so that others can access study materials.
When you’re adding references to a document in Word, use the Zotero Word plugin to add citations as you go. Zotero is a free, open-source reference manager that takes care of citations, references, and formatting, so you don’t have to worry about formatting references. The lab Zotero account has an existing library for all lab members to use. Please pull references from the lab library because that ensures that we don’t have conflicting references. Lab members are encouraged to update and clean up entries as they work on their own projects.
If you need to get a poster printed, the university will pay for it, but it has to be printed at the Department of Geographic and Environmental Sciences. They only do paper posters and are more expensive than other places, so check your options before proceeding (e.g., if cost is similar, it may make more sense to pick up your poster at the conference site).