Lab Manual

Contextual Dynamics Lab, Dartmouth College

Jeremy R. Manning, Ph.D.

December 7, 2025

PUBLISHED BY THE CONTEXTUAL DYNAMICS LAB, DARTMOUTH COLLEGE

Current as of December, 2025

Introduction

This lab manual is intended to provide a crash course in doing research in the Contextual Dynamics Lab. It describes your rights and responsibilities as a member of the lab. The manual also introduces our general research approach and lab policies.

Who is this lab manual for?

⊕TASK: Upon reading through this lab manual for the ﬁrst time, please update the document to include your name in the Lab members section. Importantly, be sure to fork the GitHub repository, make your edit on your personal fork, and submit a pull request with your update. Be sure to recompile the .tex ﬁle after you make your changes so that the .pdf ﬁle is updated and the LaTeX compiler catches any errors you may have made. Also, feel free to make any additional changes you think would beneﬁt other current or future lab members. You could correct a typo, clarify something that’s unclear, add a comment or reference to a useful tool, etc. If you’d like to get feedback on your idea ﬁrst, create a GitHub issue describing your proposed change; you can use the existing issues to help decide what to focus on for your own edits if you’d like. Every new lab member should read the latest version of this lab manual in detail and reference it later as needed. Periodically throughout the document, you will see margin notes with listed TASK items. Completing your read through entails: (a) reading the contents of the manual, (b) asking current lab members about any confusing aspects, and (c) completing the relevant TASK items. You will also see non-task NOTE items; these provide helpful tips and additional commentary on the nearby text.

This lab manual is meant to be a “living document.” All lab members are welcome (and encouraged!) to submit edits that improve the content, clarity, and overall helpfulness of this document at any point throughout their tenure in the lab.

What should you do if you don’t understand something?

⊕TASK: If you haven’t used LaTeX before (i.e., the document formatting language in which this manual is written), you’ll want to download LaTeX and take a look at this “quick start” tutorial. If you don’t understand something in this manual, ask another lab member for help. Every member of the lab brings their own unique knowledge base, training, life experiences, and perspectives. Respecting and celebrating those diﬀerences drives the science we do. If you’re new to the lab or a particular technique, you might feel like a newbie today—but chances are good that someone else will be seeking your expert opinion before you know it. In addition to learning, there’s another reason for asking for help: if you don’t understand something, you may have discovered a mistake or a logical inconsistency!

⊕TASK: When you are done reading this manual and carrying out all required tasks, please ﬁll out the signature page, sign it (electronically), and email a PDF (of just the signature page) to contextualdynamics@gmail.com. You are oﬃcially a lab member once you have completed all tasks in this manual and receipt of your signed and ﬁlled-out signature page and checklist has been acknowledged by Jeremy.

Why is it worth my time to read through the manual?

Aside from pursuing your own curiosity, a major reason that you’ve decided to join an academic research lab is probably because you want to gain training or career-advancing experiences. This manual brieﬂy summarizes the collective wisdom of past and present lab members in a way that we think will best allow you to achieve your objectives. Learn from it, challenge it, and add to it.

What “isn’t” this lab manual?

This lab manual is not intended to provide a comprehensive overview of everything you need to know to do your research projects. As described next, you may not even know what you need to know to do your projects! Nevertheless, you need somewhere to start, and this is that place.

We also maintain a repository of lab tutorials that provide guidance on speciﬁc tasks. If you are looking for help on a particular task (or understanding a particular concept) that isn’t covered by the existing set of tutorials, please consider contributing a tutorial of your own once you’ve ﬁgured things out!

Bill of rights and responsibilities

⊕TASK: Read this letter about deﬁning and characterizing boundaries between lab members and noticing unhealthy norms. As a member of the Contextual Dynamics Lab, you are entitled to certain rights, and you agree to take on certain responsibilities.

Your rights as a lab member

1.: You are entitled to a safe work environment free from harassment, abuse, violence, and discrimination in any form.
2.: You are entitled to be supported and respected by all lab members.
3.: You are entitled to openly share your scientiﬁc ideas and constructive feedback with all lab members.
4.: You are entitled to appropriate credit (e.g. authorship, acknowledgement, letter of recommendation) for your work and ideas.

Your responsibilities as a lab member

1.: You agree to contribute to a safe work environment and to refrain from behaviors that harass, abuse, expose to violence, or discriminate.
2.: You agree to support and respect all lab members, including yourself.
3.: You agree to openly share your scientiﬁc ideas and constructive feedback with other lab members.
4.: You agree to clearly communicate and document your contributions to each research project (e.g. through GitHub commits and issues, reports, updates on Slack, etc.).
5.: You agree to establish open lines of communication between yourself and other lab members, and to address concerns or issues promptly and directly with the relevant parties (to the extent that you feel safe doing so).
6.: You agree to carry out your work with integrity and diligence, adhering to the highest possible standards of scientiﬁc excellence.
7.: You agree to utilize lab resources (including equipment, money, time, etc.) responsibly and sustainably.
8.: You agree to maintain a clean workspace free from clutter, including both personal spaces (e.g. desks) and shared areas (couch, sink, testing rooms, etc.).

Recourse

If you feel your rights as a lab member have been, or are in danger of being, violated, it is your duty to report those violations immediately to a senior staﬀ member (e.g. Jeremy, Department Chair, Deans, police, Title IX coordinator, ombudsman, etc.). Similarly, if you notice others endangering others’ rights, or neglecting their responsibilities, it is your duty to report those violations to a senior staﬀ member.

Oﬃcial lab practices and policies

Our lab’s practices and policies provide a framework for maximizing eﬃciency. Peak eﬃciency as a lab means being as scientiﬁcally productive as possible in knowledge discovery (learning new stuﬀ) and dissemination (papers, talks, conference presentations, publicly released datasets, software, etc.), while helping lab members achieve their training and career objectives. To achieve peak eﬃciency, we need to succeed on three fronts:

Communication. We want to foster an environment where everyone feels comfortable contributing to the collective dialogue. Our lab meets regularly to discuss logistical (e.g. scheduling, ﬁnancial, sociological) and technical issues. We also use a variety of software packages to synchronize and facilitate communication within our lab and between our lab and the broader scientiﬁc community.
Resource allocation. ⊕NOTE: Resources, links, and discussions related to grants and other funding opportunities may be found in the #grants Slack channel. All senior lab personnel (and any interested junior personnel) should join this channel to participate in discussions about lab resources. Our lab resources (e.g. equipment, time, money, attention) are ﬁnite. We foster an environment where lab resources are used eﬃciently to achieve our collective goals, and sustainable use of resources by regularly pursuing funding opportunities.
Adaptability. The whole point of research is that we don’t already know the answers to the questions we’re exploring or how to create the tools we’re building. That means we can’t always plan everything in advance. We often need to be focused and eﬃcient without knowing the end goal!

Your job as a contributing lab member is to help us to achieve our collective peak eﬃciency (as a lab) while also maximizing your own training and career potential. To do this, the Contextual Dynamics Lab practices agile research, as described in the next section.

Doing agile research

The agile approach to research we use in the Contextual Dynamics Lab is inspired by the Agile Movement in the software development world. The idea is to create learning, adaptable teams to work on very small bite-sized tasks. Speciﬁcally, project teams are designed to respond to unpredictability in research through incremental, iterative work “sprints.” Each sprint lasts approximately 1–2 weeks, and results in a demonstrable research product (e.g. a draft of a paper, a draft of a grant, a completed analysis or ﬁgure, a poster, a software tool, etc.).

This diﬀers from traditional approaches where a research team plans out every part of a project in advance. We still break projects into small chunks, but the key insight of the agile approach is that we only need to know what the next chunk is, rather than forecasting over an extended timeline. Although it helps to have a general sense of where things are going, we don’t need to know where a project will ultimately end up. The goals and process constantly evolve. Perhaps the best justiﬁcation for this approach is that the ﬁrst day of a new research project is when you’re the most clueless about what you’ll ﬁnd. So how could that be the ideal time to plan out the entire project?⊕NOTE: Our adapted approach also draws inspiration from this blog.

Our agile research manifesto has three key tenets:

1.: Value individuals and interactions over processes and tools. To be clear, processes and tools are important. But we must always keep the user or consumer in mind. In practice, this means that a simpler (but potentially less comprehensive) tool or approach may be preferable in that it could be easier for a reader or user to make sense of.
2.: Value working, intuitive tools and research products over comprehensive documentation. Documentation is important! But if our research products are designed in an intuitive way, they can (in some sense) serve as their own documentation. An intuitive tool or research product with decent documentation is always preferable to an unintuitive tool or research product with comprehensive documentation.
3.: Value responding to change over following a plan. Each new step of the research process brings new insights and potentially uncovers mistakes or ineﬃciencies. Those discoveries may imply that a new direction is better than a previously planned one. These are opportunities that should be leveraged and embraced as part of the scientiﬁc process.

While there is value to the italicized items, we value the bolded items more. There are twelve principles we use to achieve these tenets:

1.: Our highest priority is to beneﬁt the research community through the early and continuous delivery of scientiﬁc outputs (ideas, presentations, papers, tutorials, tools, devices, etc.).
2.: We welcome changing goals and requirements, even late in the process. Doing awesome science means keeping an open mind. Your original goals and plans may no longer apply as your project progresses. Your original hypotheses may be proven false. Your assumptions may be incompatible with your data. Learn from these challenges and grow with them. Avoid getting “stuck” by refusing to change, and allow your questions to follow where your data lead, rather than be constrained by your initial ideas.
3.: We deliver research products frequently, in intervals ranging from a couple of weeks to a couple of months, with a preference for shorter timescales. Before you have a concrete manifestation of your work (a ﬁgure, a statistic, a presentation, a paper draft, a dataset, a GitHub commit, etc.) you have nothing you can show the world for your eﬀorts. Produce research products, even if they’re small and seemingly insigniﬁcant, as often as possible. You can always improve on an already produced research product.
4.: The product itself (software, paper, poster, presentation, grant) is the primary measure of progress. Before you’ve incorporated your latest eﬀorts into a shareable or communicable research product, it (eﬀectively) doesn’t exist.
5.: Continuous attention to technical excellence and good design enhances agility. Getting research products out regularly requires avoiding the temptation of aiming for perfection. Nevertheless, there are often several almost-as-eﬃcient ways to accomplishing tasks that vary in their design quality. For example, consider whether the solution to a problem you’re working on might also apply to other similar problems in the lab (that you or others are working on or have discussed). Can you make your solution general enough to cover those cases? Or, after completing a draft of a research product, you will likely have some insights into alternative (potentially better) approaches. Can you tweak the product to leverage those insights?
6.: Simplicity—the art of maximizing the amount of work not done—is essential. Keep in mind the scope of your task. What’s the minimum viable set of accomplishments that will allow you to complete that task? Get those done ﬁrst and “release” your product (e.g. commit to GitHub, share via Slack, etc.). You can always deﬁne a new set of goals for your next task centered around extending your just-released research product. This will help to avoid aimless drift, whereby you spend large amounts of time on tasks that are, in retrospect, tangential to the main scope of work.
7.: Aim to get some amount of work done every single day on your project. Commit your changes to GitHub, or document your progress in Slack or a Google Doc. Maintain careful records and logs so that someone can pick up your work in the future (and that future someone might be you!). Remember that your greatest collaborator is your past self, but they don’t respond to emails or Slack messages! Help “future you” maintain peak eﬃciency through methodical and well-documented work. (Note: don’t spend too much time on documentation; e.g. GitHub commits are themselves often suﬃcient for documentation, since one can always compare diﬀerent versions of a particular ﬁle.)
8.: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Each day, ask yourself: “am I motivated to do my best work on my project today?” If the answer is “no,” try to understand why. Is it lack of resources? Lack of support? Distractions? Ambiguous goals or research directions? Talk to your fellow lab members and see how they’d approach the challenges you’re facing.
9.: The best architectures, requirements, and designs emerge from self-organizing teams. Have you been chatting with a fellow lab member and you’re excited about what they’re working on? Or do you have ideas for building on that work? Or has a new potential team project emerged from a spontaneous conversation? Think about how you can leverage these opportunities into research products that you’re excited to work on!
10.: The most eﬀective and eﬃcient method of conveying information within a research team is face-to-face conversation. We use the CDL Google calendar to coordinate formal meetings between lab members. You can also sign up for meetings with Jeremy via YouCanBook.me. We also use Slack to coordinate, share notes/data, etc. But the ideal form of communication in the lab is face-to-face (or over Zoom), and it often involves a whiteboard.
11.: Agile research is sustainable research. Researchers should be able to maintain a constant pace indeﬁnitely. To be sure, we sometimes have crunch times where we absolutely must meet a deadline (e.g. a grant submission, project milestone, etc.). However, it is far more eﬃcient to make steady progress over an extended timeframe than to ﬂuctuate between periods of high and low productivity. By distributing your workload you’ll help yourself avoid burnout, preserve your mental and physical health, and allow yourself time to “step back” and think about the big picture (eﬀectively getting stuﬀ done between your work sessions!). Sustainable work habits also promote good communication and coordination between project team members.
12.: At regular intervals, the team reﬂects on how to become more eﬀective, then tunes and adjusts its behavior accordingly. At minimum, all active lab members need to reﬂect on their projects once each week in your Weekly Snippet (deﬁned below). You should also schedule regular meetings with your project team and/or Jeremy (via YouCanBook.me) to discuss progress, goals, roadblocks, and project logistics.

Papers

Research papers are the primary research output of our lab. Publications are the “currency of academia,” in that they are central to career advancement. With each allocation of lab resources (equipment, money, time) we should be asking ourselves how this contributes to a paper.

General procedure

All lab papers should be coordinated with Jeremy. A paper starts with a discussion of:

1.: What the paper is going to be about
2.: What the key results are
3.: What the overall “story” is
4.: The current status of various components of the project (e.g. data collection, analyses, ﬁgures, interpretation, literature review, etc.)
5.: Who the potential candidates for authorship on the paper are

We draft papers in LaTeX, either on GitHub or on Overleaf (an online platform that supports text editing and compiling PDFs in the browser). Progress should be shared regularly via Slack.

Authorship guidelines

⊕TASK: Review the NIH Guidelines for Authorship. The Contextual Dynamics Lab follows the NIH Guidelines for Authorship in considering whether your contribution to a project merits authorship on the paper. If you have made a non-trivial contribution to a project but did not meet the requirements for authorship, you will instead receive a citation in the acknowledgements section of the paper. In general, you likely meet the requirements for authorship if you contributed in any of the following ways:

1.: Drafted the manuscript (this warrants ﬁrst authorship)
2.: Came up with the idea or made other substantial intellectual contributions that meaningfully shaped the trajectory of the project
3.: Carried out an original experimental study (e.g. that you designed or implemented)
4.: Carried out non-trivial data analyses (e.g. more complicated than $t$ -tests)
5.: Contributed novel tools or resources to the project that haven’t been published yet

⊕NOTE: Conference posters and abstracts generally have substantially less stringent authorship requirements than formal papers. The general rule of thumb for posters is that all project team members should be co-authors. You are unlikely to meet the requirements for authorship if your contributions were limited to the following:

1.: Running experimental participants for an already-designed and coded-up study
2.: Running trivial data analyses (e.g. $t$ -tests or similar)
3.: Getting trained by one of the other project members on a project-related task
4.: Training another project member on a project-related task
5.: Sharing already-published tools or resources
6.: Editing or commenting on a draft of the manuscript

The ﬁnal determination for who will be an author on each lab paper (and in what order) will be made by Jeremy, following open discussions with project team members.

Making mistakes

The work we do is complicated, and mistakes happen. When you notice a mistake (a bug, misinterpretation, mislabeling, or any other error), it is critical that you report the mistake immediately. Whereas mistakes are unavoidable in science, negative impacts can be minimized by fostering a workplace where reporting mistakes is celebrated and accepted as part of the natural course of getting things done. Mistakes are opportunities to learn and grow, and identifying or noticing mistakes should be celebrated as part of our growth as scientists. However, real harm can come from failing to report mistakes soon enough. There is a proverb that says “the best time to plant a tree was 20 years ago; the second best time is now.” Analogously, the best time to identify and correct a mistake may have been in the past– but the second best time is right now!

Example scenarios (not an exhaustive list):

1.: You’ve shared a ﬁgure, statistic, or other result, and you’ve realized there’s a bug in your code.
2.: You tried to collect some data and the experiment crashed or yielded corrupted data.
3.: You’re re-reading a paper that you shared, and you notice a mistake or typo.
4.: You made a plan with your project team and you realized it’s ﬂawed in some way, or that there’s potentially a better solution or approach.
5.: You released a software package and you’ve found a bug or error.

Appropriate actions for each of the above scenarios (this should happen immediately after you notice the mistake):

1.: Double check, to the best of your ability, that the mistake is real. This may involve checking over code, rebooting a computer and restarting an experiment, re-reading reference text, etc.
2.: Create a GitHub issue describing the problem. Provide information about how to reproduce the problem (if applicable), the expected behavior, and the observed behavior. Also, provide any relevant system or environment information that may be necessary for reproducing the problem (e.g. details of the computing environment).
3.: Coordinate over Slack with your project team to formulate an action plan.
4.: Ask other lab members for help if the course of action isn’t clear. Also, try Google and/or Stack Exchange.

If you think you might have caught a mistake but aren’t sure, consult with another lab member! It never hurts to be safe!

Project roles

Every project has four possible roles. You will play one or more of these roles on your project:

1.

Project Owner. This is the person responsible for maximizing “return on investment” of the project eﬀort. The project owner:

(a): Is responsible for project vision
(b): Constantly re-prioritizes the research backlog, adjusting any long-term expectations such as publication and release plans
(c): Acts as the ﬁnal arbiter of requirements questions
(d): Accepts or rejects each project increment
(e): Decides whether to publish/ship the project
(f): Decides whether to continue development
(g): Considers interests of funding bodies (e.g. NIH, NSF, DARPA, private organizations) and the scientiﬁc community
(h): May contribute as a team member
(i): Has a leadership role
(j): Will usually be Jeremy

2.

Team Member. Team members are responsible for carrying out the project work. Team members:

(a): Are cross-functional: includes members with development skills (write code or papers/grants), testing skills (e.g. data collection, test software, proofread papers/grants), and/or domain expertise (e.g. knowledge or interest in a relevant research area)
(b): Are self-organizing and self-managing without externally assigned roles
(c): Negotiate commitments with the Project Owner, one “sprint” at a time
(d): Have autonomy regarding how to reach commitments
(e): Are intensely collaborative
(f): Are (ideally) located in one team room (usually this will be the lab)
(g): Are (ideally) committed to long-term, consistent lab membership
(h): Are (ideally) focused on a single team/project at a time
(i): Have a leadership role

3.

Project Coordinator. The Project Coordinator facilitates the agile research process both directly and indirectly. The Project Coordinator:

(a): Helps to resolve impediments ⊕NOTE: The lab coordinator role is currently vacant. The necessary functions of the Project Coordinator role will need to be satisﬁed by other project team members during this time.
(b): Creates an environment conducive to team self-organization
(c): Captures empirical data to adjust forecasts (e.g. weekly Slack reports summarizing progress)
(d): Shields the team from external interference and distraction to keep it “in the zone”
(e): Enforces timelines
(f): Has no management authority over the team (anyone with authority over the team is by deﬁnition not its Project Coordinator)
(g): Has a leadership role
(h): Will usually be either the Lab Coordinator (note: this position is currently vacant) or Jeremy.

4.

Collaborator. Collaborators are not formally part of the project team and generally will not attend regular meetings as part of the team. Importantly, collaborators do not have a leadership role in the project. They may carry out one or more of the following roles:

(a): Provide data or share equipment ⊕NOTE: A project may never be held up by a collaborator. If the collaborator fails to provide a promised service, the project team must adapt. If the collaborator fails to meet a non-critical deadline, the project will proceed without that component of the project. Involvement as a collaborator is ﬂuid.
(b): Provide occasional consulting services
(c): Provide occasional feedback on project results
(d): Carry out minor analyses
(e): Proofread documents
(f): Help with administrative tasks such as scheduling
(g): Help with information technology tasks such as computer maintenance

By deﬁnition, collaborators play a minor role in the project, and they are not responsible for managing any aspect of the project. They may become Team Members if their involvement increases. Generally, collaborators will be included in a paper’s acknowledgement section, but collaborators are not normally co-authors.

Meetings

Eﬀective lab communication requires forums for communicating. We use Slack to facilitate remote communications, and encourage in-person interactions as often as possible—ideally several times a week for group projects. We have the following regularly scheduled meetings:

⊕NOTE: All lab meetings are hybrid: in person in Moore 416 or on Zoom. A Zoom link is provided in the #general Slack channel at the start of each term, to be used for all lab Zoom meetings unless otherwise noted.

Lab meetings. We hold weekly lab meetings. During the ﬁrst week of each term, we schedule meeting times via a When2Meet poll shared on Slack. Once ﬁnalized, the schedule is posted and pinned to the #general channel. If you are an active lab member, you are expected to attend our lab meetings unless you let Jeremy know that you have a conﬂict (e.g., a course that meets at the same time, another commitment that comes up, etc.). Prioritizing lab meeting attendance helps build and maintain a lab culture of collaboration and ongoing participation.
During lab meetings we typically focus on things that project teams want input on beyond their immediate group. We also use lab meetings to discuss logistics, give feedback on upcoming talks or poster presentations, and/or share project updates that might be of interest beyond one project team. Generally we spend most of the time going around the room and having each person give a brief informal update about something they are working on, planning to work on, or thinking about.
Project meetings. Many of our collaborative projects involve regular coordination within the lab and/or with external collaborators. During the ﬁrst week of each term, project meetings are scheduled via a When2Meet poll shared on Slack, with the ﬁnalized schedule posted and pinned to the #general channel. Attendees: all project team members and any other interested active lab members.
Hackathons. We occasionally organize hackathon events where spontaneously organized groups work on short-term projects or goals. These are scheduled on an ad hoc basis. Attendees: all interested lab members, Dartmouth community members, and external collaborators.
⊕NOTE: Department talks and colloquia are listed on the PBS Department Events calendar.
Department talks and colloquia. Each week the Department of Psychological and Brain Sciences invites internal and external researchers to present on a wide variety of research topics. You are encouraged to attend any that seem interesting. Attendees: all interested lab and non-lab Dartmouth community members.
Weekly snippets. Each week, all paid employees must ﬁll out a “weekly snippet” with brief answers to the following questions:
1.
What did you work on over this past week?
2.
What are you planning to work on this coming week?
3.
What is impeding your progress (if anything)?
4.
Anything else you’d like to add?

Reminders to ﬁll out your weekly snippet are automatically sent out (via Slack) each Monday at 9 AM. Weekly snippets are required for all paid employees and optional for all other lab members. If you are an unpaid employee but may request a letter of recommendation, weekly snippets help me maintain a sense of what you are working on and how you are progressing over time. I’ll also refer to your snippets during check-in meetings (e.g., to discuss project progress, contributions, letters of recommendation, annual reviews, etc.). Submit your snippet using the “Fill out your snippet!” workﬂow on Slack, accessible via the Workﬂows menu in the #general channel (usually near the top left of the window). Participants: all paid lab members and any other lab members who want to participate.

Getting started in the lab

The ﬁrst thing you need to do is get set up on the following platforms, which enable you to interact with the lab, download and use our software packages, and accomplish administrative tasks: ⊕TASK: Create (free) Google and GitHub accounts. Also initiate a request to join our slack workspace via this link.

1.: Slack. This is where almost all not-in-person lab communications take place. It provides an interface for asking questions, storing notes, and sharing ideas. If you have a Dartmouth College NetID you should be able to join the workspace by clicking the link. If you do not have a NetID, you’ll need to request one here. ⊕TASK: When you join our Slack workspace, initiate our onboarding process using the “Join the lab!” workﬂow. You can access this workﬂow in the #general channel through the Workﬂows menu (usually near the top left of the window). Once you initiate the workﬂow, you’ll be guided through the onboarding process.
2.: GitHub. ⊕TASK: If you’ve never used GitHub (Git) before, please work through these GitHub Tutorials. You may also ﬁnd it useful to refer to this Git cheat sheet and this Git workﬂow sheet when using Git/GitHub at ﬁrst. We also maintain a set of GitHub tutorials on YouTube. This is used to manage all code, papers, grants, presentations, and posters. In other words, anything where it’d be useful to track multiple versions, anything that we might ultimately want to release to the public, and/or anything that multiple lab members will be collaborating on. Each project has one or more GitHub repositories. You should treat GitHub as a digital version of a “lab notebook” that contains a formal record of every contribution you make to your projects. We use GitHub logs to assign credit for ideas, code or writing contributions, determine authorship order, and more. It is therefore critical that you regularly check in (commit) your work via GitHub so that you receive appropriate credit for your ideas and maintain a continuous traceable log for your project.
3.: 1Password. ⊕TASK: If you are a senior lab member, request a 1Password invite from Jeremy. This platform is used by senior lab members to manage secure notes and passwords (e.g. shared software licenses, card numbers and chart strings, etc.).

Once you’ve created those accounts, you can ask any questions through Slack (use the #general channel or the channel speciﬁc your project). Depending on your role in the lab, you may be added on Slack as a single-channel guest (access to only one channel) or a full member (access to all lab channels). This generally depends on how long you’ve been in the lab and/or how many projects you are expecting to interface with. If you feel you don’t have the appropriate account type, please communicate your concerns to Jeremy.

Setting up your development environment

To ensure all lab members have consistent development environments, we provide an automated setup script. The script installs standard applications and creates a Python environment with all necessary packages for lab research.

⊕TASK: Run the CDL setup script on your computer by following the instructions below. Verify that all installations complete successfully.

To run the setup script:

On macOS or Linux:


curl -fsSL https://raw.githubusercontent.com/
  ContextLab/lab-manual/master/scripts/setup.sh | bash

On Windows (PowerShell as Administrator):


irm https://raw.githubusercontent.com/ContextLab/
  lab-manual/master/scripts/setup.ps1 | iex

What the script installs:

Applications: Slack, VS Code, LaTeX distribution, Git, Dropbox
Python environment: Miniconda with the cdl conda environment
Python packages: NumPy, Pandas, PyTorch, Transformers, HyperTools, Quail, timecorr, supereeg, and other lab-standard packages

After installation, activate the CDL environment with:


conda activate cdl

Getting help with setup issues:

For software or hardware issues: email help@dartmouth.edu
For lab-speciﬁc issues: reach out to Jeremy via Slack or email
For non-urgent questions or general interest problems: ﬁle an issue at https://github.com/ContextLab/lab-manual/issues

CITI training

Our lab studies human memory, so our research frequently involves interacting with (and analyzing data from) human subjects. It is essential to understand how to ethically and responsibly maintain the safety, comfort, and privacy of participants. Before beginning work on any lab projects, you must complete an online tutorial through the Collaborative Institutional Training Initiative (CITI) Program.

All lab members are required to complete CITI’s Group 2: Social/Behavioral Basic Course module. To complete the module, you will need to:

⊕NOTE: If you have previously conducted research through a class or another lab, you may already have completed the Group 2: Social/Behavioral Basic Course module. If your certiﬁcate is valid (i.e., it is less than 3 years old), you may send it to Jeremy without completing the module again.Create an account on CITI’s website. If you are a Dartmouth student or employee, choose Dartmouth College as your organization aﬃliation and use your @Dartmouth.edu email address to create your account. Dartmouth will cover your registration fee. Continue the registration process until you reach step 7. Select Human Subjects Research. Then select Group 2: Social/Behavioral Basic Course as your registration course. If you also need to complete the biomedical module, you will be able to add it after completing the social/behavioral module. There are 16 required modules that need to be completed. Read/watch the material and complete the quiz at the end of each module. You will need to achieve a score of at least an 80% to pass. Quizzes may be reviewed and retaken.

⊕NOTE: If you will be working on a project where data is collected from DHMC patients, you may need to complete the Group 1: Biomedical Basic Course module in addition to the social/behavioral module. If you will be working on a NSF-funded project, you may also need to complete the Responsible Conduct of Research (RCR) module.

Once you have ﬁnished the training module, send your Completion Certiﬁcate to Jeremy. To access your certiﬁcate:

1.2.3.1.: Sign into your CITI account and select Records at the top of your home page.
2.: Select View-Print-Share under Completion Record.
3.: Under Completion Certiﬁcate, select View / Print. You do not need to share your Completion Report.
4.: Download the PDF and send it to contextualdynamics@gmail.com.

Miscellaneous administrata

You can pick up a lab key from Michelle Powers (Moore Hall administrative oﬃce) by emailing her and cc’ing Jeremy. You will need to pay a $5 deposit, which will be returned to you when you return your key at the end of your tenure in the lab. If you are the last one in the lab for the day, please be sure to lock the door when you leave.

Connecting to WiFi and printers

WiFi: We recommend using eduroam as your primary wireless network. Eduroam is encrypted and works at other participating institutions worldwide. You can ﬁnd setup instructions at wiﬁ.dartmouth.edu. Note that eduroam is required for accessing printing services and ﬁle servers. Dartmouth Public is available as an unencrypted fallback option, but should only be used by guests.

Printers: Dartmouth uses the GreenPrint system for printing. You can use Web Print at greenprint.dartmouth.edu to print from any public computer. For detailed printer setup instructions, see the library’s printing guide. The nearest printer to our lab is located in Moore Hall, in the tunnel outside Filene Auditorium (oﬀers black-and-white printing, both single and double-sided). For a complete list of printer locations across campus, visit Dartmouth’s printer location guide. For poster printing, see the Poster printing section elsewhere in this manual.

International student considerations

Visa requirements vary widely depending on your country of origin, visa category, and other factors. These requirements also change frequently, so it is important to stay informed about the latest policies and how they may aﬀect your work in the lab. Some areas that may be aﬀected include:

Ability to volunteer: Some visa categories prohibit unpaid work, which may aﬀect your ability to volunteer in the lab.
In-person vs. remote work requirements: Some visas may require you to be physically present at Dartmouth College, while others may allow remote work.
Payment or course credit eligibility: Your visa category may aﬀect whether you can receive payment for your work or whether you need to receive course credit instead.
Eligibility for certain funded projects: Some projects (e.g., those funded by the Department of Defense) may require US citizenship or security clearance, which may limit your ability to work on those projects.

Some workarounds that have been successful for international students in the past include:

Course credit: Enrolling in independent studies or thesis projects to receive course credit for your work in the lab.
Grants: Applying for leave-term or on-term grants through UGAR (Undergraduate Advising and Research) or the Neukom Institute.

If you are a visiting scholar, please consult with OVIS (Oﬃce of Visa and Immigration Services) about your speciﬁc situation and how it may aﬀect your work in the lab.

We strongly recommend that all international students consult with OVIS before joining the lab to understand any potential restrictions or requirements that may apply to your situation. This is especially important for ﬁrst-year international students, who may have fewer options if they cannot sign up for independent studies.

Starting a new project

Our lab uses project management tools and policies to promote continuity across projects and lab members. First, make sure your project doesn’t already exist (check with Jeremy).

The general steps to starting a project are:

1.: Create a Slack channel or decide on existing channel appropriate for project use. ⊕NOTE: If you create a new Slack channel for your project, invite Jeremy and other team members to join.
2.: Coordinate with Jeremy to set up a GitHub for Slack integration between your project and channel by sending a link to the GitHub repo in the project’s Slack channel with a note asking to set up a Slack integration.
3.: If your project involves testing human participants, verify with Jeremy that your project is covered under an existing active IRB protocol, and that you are listed on the protocol. (A list of active IRB protocols appears at the end of this lab manual.) Depending on the protocol, you may need to complete one or more online training courses to become certiﬁed to run your experiment. If no existing protocol is appropriate for your study, discuss with Jeremy whether it would be more appropriate to create a new protocol or submit an amendment for an existing protocol.
4.: Create an initial set of short-term action items for kicking oﬀ your project and post them to your project’s Slack channel.

Joining a project

To join a project, simply subscribe to the project’s Slack channel and GitHub repository. All project communications should either be summarized on Slack or occur through Slack, whenever possible. This keeps notes searchable and visible to all team members (except direct messages, which are useful for non-project-related private communications between one or more team members).

As a general rule, focus the majority of your eﬀorts on one project at a time. This doesn’t mean you do the same thing every day (each project has many components, and project focus will change over time), but it guides how you should allocate your work time.

If you are a part-time employee of the lab, prior experience has shown that you will most likely be able to make a meaningful contribution to only a single project at a time. If you are a full-time employee, you may choose to devote some of your time to a secondary project (with the understanding that you will always prioritize your primary project). If you want to change which project is your primary project, or if you want to divide your time across multiple projects, you should coordinate this with Jeremy and your team members.

Leaving the lab

When you are ready to leave the lab, please work through the following oﬀboarding checklist to ensure a smooth transition:

1.

Notify Jeremy of your end date as early as possible.

2.

Ensure all code and data are properly documented and stored on GitHub.

3.

Back up and document all collected data:

Use GitHub if data is under 1 GB total and under 100 MB per ﬁle.
Use Discovery for larger ﬁles.

4.

Write a brief summary of work done for project continuity and future letters of recommendation:

Include GitHub links and ﬁle paths to your work.
Include your contact information for future questions.

5.

Optional: Share any feedback, comments, questions, concerns, or reﬂections about your time in the lab.

6.

Optional: Note any ideas about the future of your project(s), outstanding papers, or current status of ongoing work.

7.

Return all lab equipment and coordinate with Jeremy to log the returns.

8.

If any equipment was damaged during your time in the lab, notify Jeremy.

9.

Return any remaining petty cash and sign the close account form.

10.

Set to inactive any SONA experiments that no one else will continue.

11.

Coordinate with Jeremy to be removed from relevant IRB protocols.

12.

Coordinate with Jeremy to be added to the lab “alum” Slack channel.

13.

Update the lab manual with your end date by moving your name to the alumni section.

14.

Clean up your workspace, including shared areas you may have used.

15.

Return all keys to appropriate oﬃces or personnel.

16.

Keep in touch! We value our relationships with lab alumni and would love to hear about your future endeavors.

Scheduling

Our lab’s scheduling practices and policies are intended to facilitate lab member interactions between ourselves, our collaborators, and our experimental participants. There are three basic tools the lab uses to organize and schedule events:

Google Calendar:
- We use the main lab calendar (“Contextual Dynamics Lab”) to keep track of lab-wide events including lab meetings, conferences, and activities. Note: write access is granted only to senior lab members– i.e., lab staﬀ and graduate students.
- We use the CDL resources calendar to coordinate the use of shared rooms and equipment, such as testing rooms, our EEG systems, eye-tracker, hospital equipment, software licenses, etc. Request write access if you may require use of lab equipment.
- We use the out-of-lab calendar to keep track of known absences (e.g. illness, travel, holidays, etc.). All full-time lab members should request write access.
- We use the DHMC meetings calendar to keep track of important events and meetings at DHMC.
- We use the PBS department events calendar to keep track of talks and events happening in the department.
- You may also choose to create project-speciﬁc Google Calendars, inviting project team members.
- When you add an event (in any lab calendar), it is important to include the following information as a comment (this does not apply to “out-of-lab” events):
  - Key contact names and contact information (email or phone)
  - Physical address (where the event will take place)
  - A brief description of the event and/or other relevant information
  - Attach any relevant documents via Google Docs
Doodle, When2Meet, and YouCanBook.me. We use Doodle and When2Meet to ﬁnd meeting times that work with everyone’s schedules. Doodle is best for selecting a date from many options, and When2Meet is best for selecting a speciﬁc time from a small number of dates. YouCanBook.me is used to sign up for meeting slots with Jeremy. You can book a meeting in a free slot through YouCanBook.Me at any time.

Attendance policy

We generally expect full-time employees to be in the lab during “standard” working hours—roughly 9 AM to 5 PM. The precise hours you work are less important than helping form a cohesive lab culture where lab members interact in person to share ideas, leverage expertise, and solve problems. Even if you shift your hours, we’d like you to be physically present in the lab between 1 and 4 PM (prior arrangements notwithstanding; e.g., if you have a long commute and we’ve agreed you won’t come in every day, or if you occasionally need to schedule an appointment during the 1–4 PM window). Similarly, if you are a part-time employee, try to put in your in-lab hours during the 1–4 PM window when possible. (This is in addition to weekly lab meetings.)

The lab also abides by Dartmouth’s standard paid time oﬀ policies for beneﬁts-eligible (full-time, non-student) employees. If you are a salaried employee, you can ﬁnd the oﬃcial policy here, and if you are an hourly employee, you can ﬁnd the oﬃcial policy here. If you are a student employee, you are generally ineligible for paid time oﬀ (you can take time oﬀ, but you won’t normally be paid for it).

If you know that you’ll be unable to meet any of these general attendance guidelines, please coordinate with Jeremy to make appropriate arrangements. With the above in mind, we abide by a “common sense” attendance policy that relies on an honor system.⊕TASK: If you are a (paid) hourly employee, you’ll need to track your hours using the Kronos system. Jeremy can help get you set up with that system. If you cannot attend a lab event or meeting, your privacy will be respected: you do not (generally speaking) need to provide a reason for your absence (although you are honor bound not to abuse this system!) but you are expected to responsibly manage your schedule so that you get your work done and minimize inconvenience to others to the extent possible. The one exception is that if you seem to be abusing this system (e.g. as determined by your project owner, project coordinator, or fellow team members), you may be asked to provide additional information (in a way that does not invade your privacy—and if you are worried that this policy is overly intrusive, please bring your concerns to Jeremy). Here’s the oﬃcial lab attendance policy:

It is your responsibility to provide notice, well in advance, to anyone your absence will aﬀect (e.g. Jeremy, people you’re scheduled to meet with, etc.). The best way to do this is via email or Slack, along with adding your absence to the out-of-lab calendar.
- You are responsible for accounting for your planned absences when we discuss project schedules and goals. If you agree to take on work or to meet a deadline, you’re responsible for it until you make alternative plans with your team!
- Prolonged (more than 1 day, excluding weekends and lab-related absences) planned absences should be scheduled at least 1 week in advance, and ideally 2 weeks in advance.
- Brief (one day) absences (excluding weekends, and lab-related absences) should be scheduled as far in advance as possible, but at least at the beginning of the week, emergencies notwithstanding.
If you are feeling sick, do not come into the lab. We can arrange virtual meetings (if you are feeling well enough) or re-schedule as needed. Your recovery, and the health and safety of the lab, are the top priorities.
If you need to be out of the lab for an unexpected non-illness-related emergency, simply give as much notice and information as possible.
You are expected to attend all lab-related meetings and other regularly scheduled meetings that are directly relevant to your work in the lab (assuming you are feeling well and have not made prior arrangements to the contrary).
If you are scheduled to present at a conference (i.e., you submit an abstract and it is accepted as a talk or poster), you are expected to attend the conference to present your work. In the extremely rare event that an emergency situation arises that would prevent you from presenting as scheduled, you are expected to make alternative arrangements (e.g., by arranging for a co-author to present in your place).
You are encouraged (but never required) to attend relevant journal clubs, PBS talks, DHMC meetings and talks, thesis defenses, and other relevant lab and/or Dartmouth-aﬃliated events. If you are overwhelmed with other work, have a conﬂicting meeting, are running an experimental participant, or are out of the lab for other reasons, you do not need to provide a reason for your absence (unless you’re presenting or are otherwise playing a key role).

Graduate student grading

Research terms for graduate students are graded using the following scale: HP (high pass), P (pass), LP (low pass), and NC (no credit). The grading policy below provides guidance on how these grades are typically assigned.

⊕NOTE: If you have questions or concerns about grading, please talk to Jeremy.

High Pass (HP) is intended to highlight terms of signiﬁcant achievement or performance substantially above the norm. You will typically receive an HP if you accomplish any of the following during the term:

Submit a new grant or paper
Complete a major revision of a grant or paper
Release a major software package
Complete a major update to an existing software package

Pass (P) is the default grade for graduate students who are making satisfactory progress. If you are actively engaged with the lab and making reasonable progress on your research, you will receive a P.

Low Pass (LP) and No Credit (NC) are reserved for extreme circumstances. For example, if a student is out of touch with the lab for all or most of the term without doing any lab-related work or communicating in any meaningful way, they may receive an LP or NC. If Jeremy has concerns about your progress during a given term, he will reach out to discuss a plan to course correct prior to the end of the term (or the start of the subsequent term). Note that receiving multiple LPs can aﬀect your academic standing (e.g., two LPs results in academic probation, and three LPs puts you at risk of losing your position in the program).

Internship terms are still graded as research terms even though you are not physically present in the lab. If you are on an internship, please discuss expectations with Jeremy at the start of the term.

Credit hours: Research terms may be registered for 1, 2, or 3 credits. The grading criteria above apply regardless of the number of credits.

Compensation and beneﬁts

If you are a non-student full-time on-campus employee, it’s likely that you’re eligible for Dartmouth beneﬁts, such as medical insurance, dental insurance, life insurance, etc. You can read more about the comprehensive beneﬁts package here.

Dartmouth also sponsors various health-beneﬁts programs (for all members of the Dartmouth community). For example, you are likely eligible to get a free (or subsidized) ﬁtness tracker, ﬁtness equipment, race fees, gym membership, etc. You can also earn cash (up to $400/year) for meeting your ﬁtness goals. Go here to learn more or sign up for this program.

If you are an undergraduate student employee, you may be paid or unpaid (i.e., volunteer). Dartmouth College oﬀers several options for funding your work. The most commonly used funding mechanisms are through the Undergraduate Advising & Research (UGAR) program. The program provides funding for undergraduate researchers to carry out part-time research while enrolled in courses at Dartmouth College, or to carry out full-time research during oﬀ-terms (while not taking courses). The Neukom Institute also provides several funding opportunities for part-time and full-time research. If you wish to apply for funding through any of these programs (or through other programs), please coordinate your application with Jeremy. It is your responsibility to stay on top of application deadlines, program requirements, and so on.

If you are a Master’s student employee, you are likely to work in the lab for course credit as part of your training program. This work is generally unpaid.

If you are a doctoral student, you will likely receive an annual stipend and tuition waiver that is intended to compensate you (in part) for your work in the lab. If this applies to you, you should receive information about your compensation and beneﬁts when you enter our PhD program. Although doctoral students’ stipends are normally guaranteed for ﬁve years, all students are expected monitor the #grants channel on Slack and/or seek out other funding opportunities independently.

In general: we value all lab members’ eﬀorts and contributions, and you should expect to be compensated for your work. Your compensation may take the form of course credit, wages, beneﬁts, use of resources, mentorship, etc. You should also be proactive about seeking out funding opportunities—we are a small lab with limited resources, and as a team member you are expected to help secure funding to cover your expenses. If you have comments, questions, or concerns about your compensation, discuss them with Jeremy.

Interpersonal issues If you are experiencing an interpersonal issue with another lab member or community member and have trouble resolving it on your own (or feel unsafe doing so), seek assistance from Jeremy, your Project Owner, your Project Coordinator, or one of the Dartmouth community resources described below.

All lab members, regardless of position or status, are protected by (and must abide by) Dartmouth’s human resources policies. This means behaving professionally and respectfully towards others (including your fellow lab members). On rare occasions, despite your best eﬀorts, you may ﬁnd yourself in an interpersonal situation you cannot resolve on your own. You have many resources at your disposal to help.

The Oﬃce of Human Resources provides assistance and resources to all faculty, staﬀ, retirees, and prospective employees. The Student Employment Oﬃce provides a similar suite of services to student employees. The Dartmouth Ombuds Oﬃce also provides conﬁdential and informal assistance in resolving concerns related to interpersonal issues. Please also see the section on resources for resolving interpersonal issues. Dartmouth College’s Title IX Oﬃce provides resources pertaining to issues related to sex or gender-based discrimination.

Lab resources

Like most academic research labs, we must conduct our research within a limited budget. In practice, communicate with Jeremy before you spend (or commit to spending) lab funds.

Generally, the lab’s ﬁnancial policy is the following: we will do whatever is possible to ensure you have the equipment and resources you need to do your best work. If you can adequately justify an expense and suﬃcient funds are available, then we will spend what it takes to get the job done. If you cannot justify an expense, or if the lab does not have suﬃcient funds, then we will need to get creative by ﬁguring out how to get the job done anyway on a seemingly too-small budget. Usually we’ll ﬁnd ourselves somewhere in the middle of this continuum, which will help us to stretch our limited budget as far as possible while not making ourselves crazy or losing too much productivity in the process.

Some of our projects are intended to be self-funded and/or to support other projects (e.g. StockProphet). Any use of project-generated funds should be discussed with Jeremy.

Computers

All lab members need a computer to get their work done. We generally prefer to use Macs, as this maximizes compatibility across lab members. Depending on your expected role in the lab and the speciﬁcs of your project, the lab may provide a computer to you, or you may be expected to use your personal computer to complete your work. Any equipment purchased by the lab, including personal computers, is the oﬃcial property of the Contextual Dynamics Lab and should be treated as such. All equipment must be returned to the lab when your association with the lab is complete.

In addition to personal computers, we also maintain a lab account on Dartmouth’s Discovery Supercomputing Cluster. In addition to having access to the compute nodes shared amongst the entire Dartmouth community, we have purchased several dedicated servers and a powerful head node that is shared with the COSAN Lab and the Dartmouth Brain Imaging Lab. When you link your Discovery account with the lab, you will automatically have access to those additional computing resources. We use Discovery for our most computationally intensive work. This link contains instructions for creating an account and accessing the Discovery cluster. Our suggested workﬂow is to do non-intensive computations and analyses on your personal desktop or laptop computer, and to oﬄoad more intensive analyses to Discovery. The lab’s code repository includes sample Python scripts for running analyses on Discovery.

Separate from the Discovery Supercomputing Cluster, our lab also uses two Lambda Labs “Scalar” GPU servers with a total of 16 A6000 GPUs and 64 computing cores. Each server has roughly 3 TB of storage, which is shared by the entire lab. Let Jeremy know if you’d like access to our GPU servers (and send your NetID) so that we can set up your account.

Other research equipment

Many research projects require specialized research equipment (e.g. for neuroimaging using fMRI, EEG, ECoG, etc.). Some of the necessary research equipment is owned by the Contextual Dynamics Lab, and other equipment is shared with other labs aﬃliated with PBS or DHMC. All equipment should be treated with care and respect. Any malfunctions should be reported immediately.

Repository of shared lab papers and books

Our lab maintains a Dropbox repository of PDFs for internal use by lab members and aﬃliates. Contact Jeremy for a link (not to be shared publicly).

Travel policy

⊕NOTE: To obtain funding for a scientiﬁc conference, prior to submitting your abstract, you must (a) brieﬂy describe or discuss how attending the conference ﬁts in with your goals and/or plans, (b) provide conﬁrmation that you have applied for some form of external funding, and (c) provide an approximate travel budget, including all registration fees, tickets, meals, etc. Your budget should not include lab events (e.g. lab dinners), which are covered by a separate mechanism. Your budget must be approved by Jeremy prior to submitting an abstract in order for the lab to cover your expenses. (Your expenses will be covered up the agreed-upon amount, at which point you are responsible for making your travel plans accordingly, submitting receipts, etc.) To initiate a request for travel funding, join the #receipts channel on Slack and use the workﬂow (lightning bolt in the lower left) menu to start a “Conference $ request”.A major component of doing scientiﬁc research is communicating with other scientists. The Contextual Dynamics Lab regularly presents at several international scientiﬁc conferences. If you are presenting your work from the lab (i.e., you are the presenting author for a talk or poster), then your travel expenses and conference registration fees will be guaranteed by the lab, under the assumption that you will also make reasonable eﬀorts to seek out alternative sources of travel funding (e.g. through PBS, other internal Dartmouth sources, applying for travel awards, using personal grants like NRSAs or NSF fellowships, etc.). You are also expected to keep costs low (e.g. ﬂy economy class, seek out cheaper tickets, stay in reasonably priced hotels, share a room with other lab members, etc.). By the same token, we also want to be cognizant of your comfort and time, and it is not always necessary to use the cheapest option. More speciﬁc travel guidelines will be given on a per-conference or per-trip basis.

If you are not presenting your work (or if you’re presenting non-lab work), but you are a senior lab member, then the lab may cover your travel expenses to a limited number of conferences each year. These should be discussed on a case-by-case basis with Jeremy.

If you are a junior lab member not presenting your work, the lab will generally not pay for you to attend conferences. However, if you are interested in attending a conference, and you aren’t able to secure funding through non-lab sources, you should discuss your options with Jeremy.

Making a poster

⊕NOTE: If you commit to presenting a poster at a scientiﬁc conference, you agree to prepare a complete draft of your poster at least two weeks in advance of the conference, and to complete a ﬁnal draft of your poster (that incorporates feedback from Jeremy) at least one week in advance of the conference. If you do not meet these deadlines, you may be required to withdraw your submission and/or cover any conference-related expenses that you incurred, at Jeremy’s discretion. The preferred methods for creating posters are to use LaTeX BeamerPoster, Adobe Illustrator, or Inkscape. The lab has several example poster templates on ﬁle, but these are not organized well yet. Your best bet is to ask Jeremy for an old poster and modify it. You can also create a ﬁle from scratch. Ensure that any images are either vector graphics, or bitmaps (.png, .jpeg, .tiﬀ, etc.) at suﬃciently high resolutions (at least 300 dpi).

Poster printing

⊕NOTE: Be sure to coordinate with Jeremy regarding the funding source covering your poster printing cost prior to going to print your poster. There are two on-campus poster printers. One is in the Map Room of Baker Library. More information may be found here. The Map Room printer should be used in most cases. It is important to schedule your printing time as far in advance as possible, particularly before conferences when many people will want to print. Advanced planning can help us avoid the additional costs associated with oﬀ-campus printers. The Department of Psychological and Brain Sciences covers conference poster printing costs for PBS labs and students (coordinate with Jeremy to obtain the PBS Chart String for poster printing).

Publication costs

All costs related to lab publications will be fully covered by the lab. Jeremy can help facilitate these payments.

Subject compensation

Most in-lab experimental subjects will be compensated via t-points. Coordinate with Jeremy in order to receive a t-point allocation well in advance of the start of the term you wish to run participants.

⊕NOTE:In some cases, external funding sources may be available to cover cash subject payments (e.g. undergraduate Honors Thesis Grants or Neukom Scholars grants). Coordinate with Jeremy to determine whether alternative funding sources are available for your project. Cash subject payments for lab research projects will in most cases be fully covered by the lab (see the NOTE). Subject payment guidelines are generally found in the IRB approval documentation relevant to your project. For Mechanical Turk (or other online) experiments, a subject payments budget should be approved prior to beginning the experiment. Cash payments may be made via petty cash, which is managed by Jeremy.

Who to go to with questions

This section provides guidelines for directing questions about technical and interpersonal issues. Resolving technical issues within the lab saves time, but some require external help. Interpersonal issues should be resolved in accordance with your comfort, but be aware of the resources below should you need them.

Tech issues

For issues related to our lab’s ﬁleserver, seek assistance from Jeremy.
For issues related to Slack, send a direct message to @Ryan Sokol.
For issues with other lab-owned equipment (e.g. computers, research equipment, etc.) Jeremy or the senior lab member actively using the equipment should be your ﬁrst-sought resource.
For issues related to the Discovery computing cluster, or for general Dartmouth College-speciﬁc IT questions or issues, open a ticket with the Information, Technology, and Consulting oﬃce.
For issues related to the Tensor GPU cluster, contact Bonnie Scott.

Lab documents

For questions about non-paper documents (e.g. receipts, consent forms, IRB protocols, the lab website, etc.), talk to Jeremy.
For questions on papers or posters, talk to Jeremy.

Lab policy

If you have a question about the lab’s policies, ﬁrst try to ﬁnd the answer in the Lab Manual.
If you feel your question is not adequately answered in the Lab Manual, post your question on Slack (or, if it’s a private issue, talk to Jeremy).
If you think your question is likely to be of general interest, update the lab manual to reﬂect the answer.

Speciﬁc methods

If you have questions about speciﬁc methods related to a project, ask a senior lab member working on the project.
It may also be helpful to check the CDL tutorials repo, and contact the author(s) or contributors of a related tutorial.
You can also post your question in the #computrons channel on Slack.
Remember, Google and Stack Overﬂow are your friends! Often other people have encountered (and solved!) similar problems, and sometimes they even share the answers online!
If you still cannot ﬁnd an answer to your question, reach out to Jeremy.

Interpersonal issues

Clear, direct communication is often the best way to address interpersonal issues. However, if you are having trouble resolving something (or feel uncomfortable doing so on your own) you should reach out to one of the following resources:
Senior lab members (e.g. your immediate supervisor)
Jeremy
The PBS department chair
The Undergraduate Deans Oﬃce or the Graduate and Professional Schools Deans Oﬃce
Dartmouth’s Oﬃce of Human Resources
Dartmouth’s Faculty/Employee Assistance Program
Dartmouth’s Title IX oﬃce (for concerns about sexual misconduct, harassment, or assault)
Hanover Police (if criminal activity is involved)
WISE, a 24-hour crisis hotline for free and conﬁdential services to address domestic and sexual violence and stalking ( 866-348-9473)

Ethics issues and reporting

Dartmouth’s Compliance and Ethics Hotline ( 888-497-0516)
Safety and Security’s anonymous reporting form

Internal Review Board (IRB) approvals

Experimental ⊕NOTE: Prior to running any non-lab-member participants in your study, you must coordinate with Jeremy to verify that (a) your experiment has been approved by the IRB and (b) your name is speciﬁcally listed on the associated protocol. protocols and IRB approval forms are maintained and coordinated through RAPPORT. Typically this system is accessed directly by Jeremy, but if you feel you need access to RAPPORT then let Jeremy know.

List of active protocols

1.: Eﬃcient Learning (STUDY00029685). Used for all behavioral learning and memory experiments for participants run in the lab or via Amazon Mechanical Turk. The protocol also covers ﬁtness-related studies (e.g. incorporating ﬁtness tracker data and other on-body and remote biosensors including scalp EEG and eye-trackers, and/or performing physical tasks like riding on a stationary bicycle or running in place).
2.: fMRI Eﬃcient Learning (STUDY00030020). Analog of the Eﬃcient Learning protocol, but allows for fMRI data collection.
3.: Electrophysiological Localization of Human Brain Function (STUDY00012495). Hospital protocol used for studying electrocorticographic activity in epilepsy patients.
4.: Network dynamics in human epilepsy (STUDY00029400). Hospital protocol used for studying network dynamics inferred via electrocorticographic activity in epilepsy patients.
5.: Perceptual and Memory Dynamics (STUDY00031514). Used for studies investigating the relationship between perceptual and memory metrics and symptoms associated with common psychiatric disorders.

List of inactive protocols

1.: EEG Eﬃcient Learning (STUDY00029881). Analog of the Eﬃcient Learning protocol, but allows for scalp EEG data collection. This protocol is redundant with the revised Eﬃcient Learning protocol, which now allows for scalp EEG data collection as well.

Testing procedure

When you run an experimental participant, you must have them sign a consent form. After each day of testing (or more frequently), you should give all signed consent forms to Jeremy. Consent forms are kept in a locked ﬁle cabinet in Jeremy’s oﬃce.

All experimental data must be stored securely, as per IRB guidelines. All lab computers employ disk encryption and password protection. If you need to copy unpublished data onto a non-lab computer, you need to verify (by checking in with Jeremy) that your computer satisﬁes our data security requirements. No personally identiﬁable data about our participants may ever be shared outside of the lab.

Lab members and alumni

Current lab members

Jeremy R. Manning (2015 – )

Postdoctoral Researchers

Hung-Tu Chen (2024 – )

Graduate Students

Paxton Fitzpatrick (2021 – ) Xinming Xu (2021 – ) Claudia Gonciulea (2025 – )

Undergraduate RAs

Ansh Patel (2021 – ) Megan Liu (2023 – ) Yue Zhuo (2023 – ) Maura F. Hough (2023 – ) Aaryan Agrawal (2023 – ) Grady Redding (2023 – ) DJ Matusz (2023 – ) Sarah Parigela (2023 – ) Jake McDermid (2023 – ) Emma Reeder (2023 – ) Michael Chen (2023 – ) Andrew Cao (2024 – ) Jacob Bacus (2024 – ) Rohan Goyal (2024 – ) Everett Tai (2024 – ) Chelsea Joe (2024 – ) Matthew Givens (2024 – ) Can Kam (2024 – ) Miel Wewerka (2024 – ) Rodrigo Vega Ayllon (2025 – ) Evan McDermid (2025 – ) Owen Phillips (2025 – ) Colson Duncan (2025 – ) Annabelle Morrow (2025 –) Ellie Mattox (2025 – ) Ben Hanson (2025 – ) Jaysen Quan (2025 – ) Andrew Richardson (2025 – ) Keene Dampal (2025 – ) Kevin Chang (2025 – )

Lab alumni

Postdoctoral Researchers

Andrew Heusser (2016 – 2018) Gina Notaro (2017 – 2018)

Graduate Students

Lucy Owen (2016 – 2021) Caroline Lee (2019 – 2021) Kirsten Ziman (2017 – 2021)

Lab Managers

Kirsten Ziman (2016 – 2017) Emily Whitaker (2017 – 2018) Paxton Fitzpatrick (2018 – 2021)

Research Assistants

Max Bluestone (2018 – 2019) Maddy Lee (2020 – 2021) Xinming Xu (2019 – 2021)

Undergraduate RAs

Jessica Tin (2016) Gal Perlman (2016) Peter Tran (2016) Sheherzad Mohydin (2016) Joseph Finkelstein (2016) Aman Agarwal (2016) Clara Silvanic (2016) Jake Rost (2016) Aamuktha Porika (2016 – 2017) Allison Frantz (2016 – 2017) Marisol Tracy (2016 – 2017) Wei Liang Samuel Ching (2016 – 2017) Armando Ortiz (2017) Christina Lu (2017) Campbell Field (2016 – 2018) Bryan Bollinger (2017 – 2018) Stephen Satterthwaite (2017 – 2018) Ann Carpenter (2018) Kirsten Soh (2018) Rachael Chacko (2018) Darya Romanova (2018) Iain Sheerin (2018) Mustafa Nasir-Moin (2018) Seung Ju Lee (2018) Paxton Fitzpatrick (2017 – 2019) Maddy Lee (2016 – 2020) Alex Martinez (2018 – 2020) William Chen (2019 – 2020) Aaron Lee (2019 – 2020) Shane Hewitt (2019 – 2020) Sarah Park (2019 – 2020) Austin Zhang (2020) Vivian Tran (2020) Luca Lit (2020) Kelly Rutherford (2020) Helen Lu (2020) Kunal Jha (2020) Will Baxley (2018 – 2021) Daniel Ha (2021) Shane Park (2019 – 2021) Tehut Biru (2020 – 2021) Tudor Muntianu (2019 – 2021) Chelsea Uddenberg (2020 – 2021) Greg Han (2020 – 2021) Esme Chen (2020 – 2021) Chris Long (2020 – 2021) Ethan Adner (2020 – 2021) Chris Jun (2020 – 2021) Chris Suh (2020 – 2021) Tyler Chen (2020 – 2021) Darren Gu (2020 – 2021) Aidan Adams (2021) Damini Kohli (2021) Natalie Schreder (2021) Swestha Jain (2021) Will McCall (2021) Anna Mikhailova (2021) Thomas Corrado (2021) Brian Chiang (2021) Kevin Cao (2022) Goutham Veeramachaneni (2022) Zachary Somma (2022) Dawson Haddox (2022) Alexander Marcoux (2022) Jessna Brar (2022) Wenhua Liang (2022) Molly McQuoid (2022) Mark Taylor (2021 – 2022) Francisca O. Fadairo (2023) Ameer Talha Yasser (2023) Daniel Carstensen (2021 – 2024)

Checklist and signature page

By signing below, I certify that I have completed the following tasks:

□

I have joined the lab’s Slack account and worked through the orientation workﬂow to share my accounts and information with Jeremy. (Click the Workﬂows menu in the #general channel and select ‘Join the lab!’ to start the onboarding process.)

□

I agree to check Slack regularly (at least once per normal business day, excluding days I mark on the out-of-lab calendar) and to respond to messages and requests in a timely manner (within a few hours during normal business hours, or early the next business day if messages are received after hours).

□

I have created a GitHub account and have been added to the appropriate lab GitHub group(s). If I am unfamiliar with Git, I have gone through the GitHub tutorials.

□

I am proﬁcient in LaTeX, allowing me to edit and understand this lab manual’s source code.

□

I have submitted a pull request to the GitHub repository that adds my name to the lab members section, along with any other updates I think would be helpful. I have also recompiled the PDF of the lab manual by running pdflatex twice, and have ensured that (a) the PDF compiled without errors, and (b) the table of contents was generated correctly.

□

I have run the CDL setup script (described in the Setting up your development environment section) and veriﬁed that my development environment is correctly conﬁgured.

□

I have access to the following lab calendars: Contextual Dynamics Lab, Out of lab, CDL Resources, DHMC Meetings (if applicable), and PBS department events.

□

I have been added to the lab’s 1password account if I am a senior lab member, or I have not been added because I am a junior lab member.

□

I have completed the required CITI program module(s) and have sent my Completion Certiﬁcate(s) to Jeremy.

□

I am an unpaid or salaried employee, or I am an hourly employee and have gotten myself set up on Kronos to track my paid hours.

□

If I am a paid employee (including graduate students), or if I would like to be paid, I agree to regularly seek out and coordinate with Jeremy about relevant funding opportunities that could help support me and/or my research.

□

I have submitted a photograph (of myself, or a representative scene or object) along with a brief (2-3 sentence), professionally worded biography, to be included on the lab website. Alternatively, I indicated (via Slack message to Jeremy) my preference to not be included on the lab website.

□

I agree to regularly attend lab meetings (unless I have a course conﬂict and have informed Jeremy).

□

I agree to send Jeremy regular updates regarding my progress and work, including weekly snippets, meetings, Slack discussions, and/or GitHub updates.

□

If/when I decide to end my aﬃliation with the lab, I will notify Jeremy and any project members aﬀected by my departure. I will also coordinate with Jeremy and other relevant lab members to facilitate a smooth transfer of my project-related roles and responsibilities to other lab members, including a discussion about potential authorship on future publications related to the work.

□

I have read Leah Somerville’s commentary on speaking out in toxic or abusive environments.

□

I have reviewed the NIH guidelines for authorship.

□

I agree to abide by the lab’s bill of rights and responsibilities, and to follow oﬃcial lab practices and policies.

□

I have carefully read through the entire lab manual, and I have checked oﬀ all of the above items to indicate that I have carried out the indicated tasks.

□

I will send a digital copy (PDF) of the ﬁnal two pages of this manual, including checked-oﬀ list items, my digital signature, and today’s date, to contextualdynamics@gmail.com.

__________________________________________	______________
Signature	Date