Lab Manual

User Manual:

Open the PDF directly: View PDF .
Page Count: 36

Download
Open PDF In Browser	View PDF

J E R E M Y R . M A N N I N G , P H . D.

LAB MANUAL

C O N T E X T U A L DY N A M I C S L A B , D A R T M O U T H C O L L E G E

Copyright © 2019 Jeremy R. Manning, Ph.D.
published by the contextual dynamics lab, dartmouth college
http://www.context- lab.com

Current as of January, 2019

Contents

Introduction

Bill of rights and responsibilities

Official lab practices and policies

Ask a question, answer a question

Internal Review Board (IRB) approvals
Checklist and signature page

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?
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?
If you don’t understand something you read in this manual, it is
important that you 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
differences drives the science we do. If you’re new to the lab or new
to a particular technique, you might feel like a newbie today—but
chances are good that if you stick around for a bit someone else
will be seeking your expert opinion before you know it. In addition
to learning, there’s another good reason for asking for help: if you
don’t understand something, there’s a reasonable chance that you’ve
discovered a mistake or a logical inconsistency!
Why is it worth my time to read through the manual?
Aside from pursuing your own curiosity, a major reason that you’ve

TASK: Upon reading through this lab

manual for the first time, please make
at least one edit. You could correct a
typo, clarify something that’s unclear,
add a comment, etc. Also add (or
comment on) an issue via the GitHub
issues page; you can use the existing
issues to help decide what to focus on
for own edits if you’d like. Importantly,
be sure to fork the GitHub repository,
make your edits on your personal fork,
and submit a pull request with your
edits so that everyone can benefit. Be
sure to recompile the .tex file when
you make your changes so that the .pdf
file is updated, and the LATEX compiler
catches any errors you may have made.

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.

TASK: When you are done reading this

manual and carrying out all required
tasks, please fill out the signature
page, sign it (electronically), and email
a PDF (of just the signature page)
to contextualdynamics@gmail.com.
You are officially a lab member once
you have completed all tasks in this
manual and receipt of your signed and
filled-out signature page and checklist
has been acknowledged by Jeremy or
Paxton.

decided to join an academic research lab is probably because you
want to gain training or career-advancing experiences. This manual
briefly 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 specific 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 figured things out!
If you encounter an error or problem you don’t know how to fix,
try checking the ask a question, answer a question section, where we
maintain a log of common problems and quick solutions. If you don’t
see a solution to your question there, consider adding the question so
that you or someone else can add the answer for future lab members!

Bill of rights and responsibilities
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 scientific 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 scientific 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,
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 scientific excellence.

TASK: Read this letter about defining

and characterizing boundaries between
lab members and noticing unhealthy
norms.

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 to a senior
staff 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 staff member.

Official lab practices and policies
Our lab’s practices and policies are intended to provide a framework
for maximizing efficiency. Achieving our peak efficiency as a lab means
we are being as scientifically productive as possible, in terms of
knowledge discovery (learning new stuff) and dissemination (papers,
talks, conference presentations, publicly released datasets, software,
etc.). It also means that our fellow lab members are achieving their
training and career objectives. To achieve peak efficiency, 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, financial,
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 scientific community.
• Resource allocation. Our lab resources (e.g. equipment, time,
money, attention) are finite. We want to foster an environment
where lab resources are used as efficiently as possible to achieve
our collective goals. We also want to foster sustainable use of
resources by regularly pursuing research 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 working on. That means that we won’t
necessarily be able to plan out everything in advance. We often
need to be focused and efficient without knowing the end goal!
Your job as a contributing lab member is to help us to achieve our
collective peak efficiency (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. Specifically, 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 figure, a poster, a software
tool, etc.).
This is different from traditional approaches that you may have
encountered in other labs or work environments, where a research
team might try to plan out every part of a project in advance in a
series of small steps. We still try to break projects into tiny bite-sized
chunks, but the key insight of the agile approach is that we only need
to know what the next chunk is, rather than attempting to forecast
out over an extended timeline. Although it’s often helpful to have a
general (if vague) sense of where things are going, we never actually
need to know where a project will ultimately end up. The goals and
process are constantly evolving. Perhaps the best justification for
this approach is that the first day of a new research project is when
you’re the most clueless about what you’ll find. So how could that
possibly be the ideal time to plan out the entire project?
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 inefficiencies. 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 scientific process.
While there is value to the italicized items, we value bolded items
more. There are twelve principles we use to achieve these tenets:

NOTE: Our adapted approach also
draws inspiration from this blog.

1. Our highest priority is to benefit the research community through
the early and continuous delivery of scientific 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 leads, rather than be constrained by your initial ideas.
3. We deliver research products frequently, 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 figure, a
statistic, a presentation, a paper draft, a dataset, a GitHub commit,
etc.) you have nothing you can show the world for your efforts.
Produce research products, even if they’re small and seemingly
insignificant, 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 efforts into a shareable or communicable research product, it
(effectively) 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-efficient 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 first and “release” your product (e.g. commit to GitHub, share via Slack, etc.). You can always
define 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 efficiency
through methodical and well-documented work. (Note: don’t
spend too much time on documentation; e.g. GitHub commits
are themselves often sufficient for documentation, since once can
always compare different versions of a particular file.)
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 effective and efficient 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,
and it often involves a whiteboard.
11. Agile research is sustainable research. Researchers should be able
to maintain a constant pace indefinitely. 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
efficient to make steady progress over an extended timeframe
than to fluctuate 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 (effectively getting
stuff done between your work sessions!). Sustainable work habits
also promote good communication and coordination between
project team members.
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly. At minimum, all active lab members need to reflect on their projects once
each week in your Weekly Snippet (defined below). In addition, you
should schedule a 30 minute meeting with Jeremy at the beginning
and end of each term to discuss:
• What your goals are for the upcoming term (start-of-term
meetings), or what you worked on over the prior term and how
well you feel you met your goals (end-of-term meetings)
• Reflections on how things are going in the lab (you will report
how things have been going from your perspective, and will receive feedback about how things have been going from Jeremy’s
perspective).
• Insights you’ve come to regarding how we can (for your project,
as a lab, as a department, etc.) further optimize efficiency or
otherwise improve our work environment.
• Any other issues, comments, questions, or concerns that you’d
like to check in about.
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, figures, interpretation, literature review, etc.)

5. Who is a potential candidate for authorship on the paper
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
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:

TASK: review the NIH Guidelines for
Authorship.

1. Drafted the manuscript (this warrants first 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

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 projectrelated 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 final 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.

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.

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 Chinese 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 figure, 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
flawed 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 effort. 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 final 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 scientific 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
(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 definition not its Project Coordinator)
(g) Has a leadership role
(h) Will usually be the Lab Coordinator (Paxton)
4. Collaborator. Collaborators are not formally part of the project
team and generally will not attend regular meetings as part of the
team. 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
(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 definition, 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.

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 fluid.

Meetings
Effective lab communication requires forums for communicating. As
described below, we use Slack to facilitate non-in-person communications, but Slack cannot replace in-person meetings. In fact, our
approach is set up to encourage in-person interactions as often as
possible—ideally several times a week for group projects. We’ll have
the following regularly scheduled meetings:
1. Lab meeting. We will have, as a lab, a regular weekly 1.5 hour
meeting on Wednesdays at 12:30pm. The precise format of this
meeting varies from week to week according to lab needs and
interests. Attendees: all active lab members.

TASK: If you are a senior lab member
(lab manager, grad student, or postdoctoral researcher), discuss with Jeremy at
the beginning of each term one thing
that you can present at a lab meeting.
Junior lab members (undergraduates)
are not obligated to present at lab
meetings, but may schedule a time to
do so upon request by coordinating
with Jeremy. Exception: if you are
presenting your work outside of the
lab, and if it is the first time you are
presenting that project, you must do a
practice talk for the lab (regardless of
whether you are a junior or senior lab
member).

2. Project meetings. Several of our collaborative projects involve regular coordination with external lab members. These are organized
on an ad hoc basis for each project. Attendees: all project team
members and any other interested active lab members.
3. Hackathons. We occasionally organize hackathon style events
whereby spontaneously organized groups work towards one or
more very short term projects or goals. These are scheduled on an
ad hoc basis. Attendees: all interested lab members, any interested
member of the Dartmouth community, and external collaborators.
4. Beginning-of-term and end-of-term meetings. At the start or end
of each term, you should schedule a 30 minute meeting slot with
Jeremy to discuss your research plans, progress, goals, etc. It is
your responsibility to sign up for a slot via YouCanBook.Me.
5. 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.
6. Howdy weekly snippets. Each week (via Slack), all paid employees must fill out a “weekly snippet” with brief answers to the
following questions:
(a) What did you work on last week?
(b) What do you plan to work on this upcoming week?
(c) What is impeding your progress?
(d) Do you want to set up a meeting with Jeremy? (If so, a link is
provided to schedule a meeting via YouCanBook.Me.)
Whereas weekly snippets are required for all paid employees, they
are optional for all other lab members. To be added to the weekly

NOTE: Each term, you should sign up

for a beginning-of-term or end-ofterm meeting time with Jeremy via
YouCanBook.Me.

NOTE: Department talks and colloquia

are listed on the PBS Department
Events calendar.

TASK: If you are a paid lab employee,

or if you would like to submit weekly
snippets, email Jeremy to get added to
the Howdy script.

snippet schedule, email Jeremy. Being added to the weekly snippet
schedules means that you will receive a link via the “Howdy”
survey bot (through Slack) each Monday at 9am. Your answers are
then compiled into reports that Jeremy receives each Wednesday
at 10 AM. If you are an unpaid employee but are likely to request
a letter of recommendation, weekly snippets are a good way for
me to maintain a detailed sense of what you are working on from
week to week and how you are progressing over time. (Virtual)
attendees: all paid lab members and any other lab members who
want to participate.
Getting started in the lab
The very first thing you need to do is to get set up the following
platforms, which will enable you to interact with the rest of the lab,
download and use the lab’s software packages, and accomplish
various necessary administrative tasks:
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.

TASK: Create (free) Google, Trello, and

GitHub accounts. Send your addresses
and/or usernames to Paxton (cc’ing
Jeremy) so that you can be added to the
lab groups. Also send your preferred
email address so that you can be added
to the lab Slack account.

2. Trello. This is used to manage all projects and tasks. It provides a
way of tracking progress and impediments to progress.

TASK: If you’ve never used Trello before,
you may find it useful to work through
this Trello tutorial.

3. GitHub. 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.

TASK: If you’ve never used GitHub
(Git) before, please work through these
GitHub Tutorials. You may also find
it useful to refer to this Git cheatsheet
and this Git workflow sheet when using
Git/GitHub at first.

4. 1Password. 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.).

TASK: If you are a senior lab member,

5. Lab website. We use the lab website to distribute research materials, describe ongoing work, and provide information about our
work.

TASK: Submit a photograph (of yourself

Once you’ve created those accounts, you can ask any questions
through Slack (use the #general channel or the channel specific 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.

request a 1Password invite from Jeremy.

or some other picture or image that
you want to represent you) and a 2-3
sentence biography to Paxton so that
you can be added to the people page on
the lab website. Alternatively, if you do
not wish to be included on the website,
send a note to Paxton expressing that
you do not want to be added to the
website.

Miscellaneous administrata
You can pick up a lab key from Michelle Powers (Moore Hall administrative office) 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.
Starting a new project
Our lab uses a number of project management tools and policies to
promote continuity across projects and lab members. First, make sure
that your project doesn’t already exist (generally this involves asking
Jeremy).
The general steps to starting a project are:
1. Create a Slack channel or decide on existing channel appropriate
for project use.
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 certified 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 off 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 private communications between one
or more team members).
Note that, as a general rule, you should focus the majority of your
efforts on one project at a time. This doesn’t mean you need to do
the same thing every day (each project has many components and, as

NOTE: If you create a new Slack channel

for your project, invite Jeremy, Paxton,
and other team members to join.

described above, the focus of lab projects will change over time), but
it gives some sense of how you should be allocating 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 a only 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 you time across multiple projects,
you should coordinate this with Jeremy, Paxton, and your team
members.
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:

TASK: email Paxton to request invites

to each of the calendars below—the
download links in the lab manual are
read-only!

• Google Calendar:
– We use the main lab calendar to keep track of lab-wide events
including lab meetings, conferences, and activities.
– 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.
– We use the out-of-lab calendar to keep track of known absences
(e.g. illness, travel, holidays, etc.).

TASK: If you are a graduate or under-

– We use the CDL class schedule calendar to keep track of course
schedules of grad students and undergraduates.

graduate student, please add your
schedule to the CDL class schedule
calendar at the beginning of each term.

– 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-specific 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 converge on mutually good meeting times that fit
(as well as possible) with everyone’s busy schedules. Doodle is
most useful for selecting a date from a large number of options,
and When2Meet is most useful for selecting a specific time on
a relatively 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 if you would
like to meet with Jeremy. Most meetings with Jeremy happen on
Wednesdays.

Attendance policy
In general, we expect full time employees to be in the lab during
“standard” working hours—roughly between 9 AM and 5 PM. The
precise range of hours you work is less important to us than putting
in an effort to help form a cohesive lab culture where lab members
can interact in person to share ideas, leverage expertise, solve problems, etc. Therefore, even if you end up deciding to shift your hours,
we’d like you to make a strong effort 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 that you won’t come in
every day, or if you need to occasionally schedule an appointment
during the 1–4 PM window). Similarly, if you are a part time employee, we’d like you to try to put in your in-the-lab hours during
the 1–4 PM time window as often as possible. (This is in addition to
weekly lab meetings.)
The lab also abides by Dartmouth’s standard paid time off policies
for benefits-eligible (full-time, non-student) employees. If you are a
salaried employee, you can find the official policy here, and if you are
an hourly employee, you can find the official policy here. If you are a
student employee, you are generally ineligible for paid time off (you
can take time off, 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.
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,

TASK: If you are a (paid) hourly employee, you’ll need to track your hours
using the Kronos system. Paxton can
help get you set up with that system.

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 or Paxton). Here’s the official
lab attendance policy:
• It is your responsibility to provide notice, well in advance, to anyone your absence will affect (e.g. Jeremy, Paxton, 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 labrelated 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-illnessrelated emergency, simply give as much notice and information as
possible.
• You are expected to attend all lab meetings and other regularly
scheduled meetings that are directly relevant to your work in the
lab.
• If you are scheduled to present at a conference (i.e. you submit
an abstract and the abstract 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 strongly encouraged (but never required) to attend relevant journal clubs, PBS talks, DHMC meetings and talks, thesis

defenses, and other relevant lab and/or Dartmouth-affiliated
events. If you are overwhelmed with other work, have a conflicting
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).

Compensation and benefits
If you are a non-student full-time on-campus employee, it’s likely
that you’re eligible for Dartmouth benefits, such as medical insurance, dental insurance, life insurance, etc. You can read more about
the comprehensive benefits package here.
Dartmouth also sponsors various health-benefits programs (for
all members of the Dartmouth community). For example, you are
likely eligible to get a free (or subsidized) fitness tracker, fitness
equipment, race fees, gym membership, etc. You can also earn cash
(up to $400/year) for meeting your fitness goals. Go here to learn
more or sign up for this program.
If you are a student employee, you may be paid or unpaid. In
general, full-time student employees are paid and part-time student
employees are unpaid until they have been a full-time employee for
at least one term. Your precise level of compensation will depend
on your position, how your work in the lab is funded, your prior research experience, etc. If you have comments, questions, or concerns
about your compensation, please discuss them with Jeremy.

Interpersonal issues
If you are experiencing an interpersonal issue with another lab
member or community member and are having trouble resolving
it on your own (or feel unsafe resolving it on your own), please
seek out assistance from Jeremy, Paxton, your Project Owner, your
Project Coordinator, or one of the Dartmouth community resources
described below as early as possible.
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, but not limited to, your fellow lab members). On (hopefully)
rare occasions, despite your best efforts, you may find yourself in an
interpersonal situation that you feel unable to resolve on your own.
You have many resources at your disposal to help get you back on
track.
The Office of Human Resources provides assistance and resources
to all faculty, staff, retirees, and prospective employees. The Student

Employment Office provides a similar suite of services to student
employees. The Dartmouth Ombuds Office also provides confidential
and informal assistance in resolving concerns related to interpersonal
issues. Please also see the Ask a question, answer a question section on
resources for resolving interpersonal issues.
Lab resources
As with most academic research labs, we (sadly!) must conduct our
research within a limited research budget. In practice, the important
thing is to communicate with Jeremy before you spend (or commit to
spending) lab funds.
Generally, the lab’s financial 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 sufficient 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 sufficient funds, then we will need to get creative
by figuring out how to get the job done anyway on a seemingly toosmall budget. Usually we’ll find 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
specifics 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 official 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 workflow is to do non-intensive computations and analyses
on your personal desktop or laptop computer, and to offload more
intensive analyses to Discovery. The lab’s code repository includes
sample Python scripts for running analyses on Discovery.

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 affiliated with
PBS or DHMC. All equipment should be treated with care and
respect. Any malfunctions should be reported immediately.

Repository of shared lab papers
Our lab maintains a Dropbox repository of PDFs for internal use by
lab members and affiliates. Contact Jeremy or Paxton for a link (not
to be shared publicly).

Travel policy
NOTE: To obtain funding for a scientific

A major component of doing scientific research is communicating with other scientists. The Contextual Dynamics Lab regularly
presents at several international scientific 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 efforts 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. fly
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 specific 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 nonlab 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.

conference, prior to submitting your
abstract, you must (a) briefly describe or
discuss how attending the conference
fits in with your goals and/or plans,
(b) provide confirmation 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.)

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
The preferred methods for creating posters are to use LaTeX BeamerPoster, Adobe Illustrator, or Inkscape. The lab has several example
poster templates on file, 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 file from scratch. Ensure that any images are either vector graphics, or bitmaps (.png, .jpeg, .tiff, etc.) at sufficiently high
resolutions (at least 300 dpi).

Poster printing
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 off-campus
printers. The Department of Psychological and Brain Sciences covers
conference poster printing costs for PBS labs and students (coordinate with Paxton to obtain the PBS Chart String for poster printing).

NOTE: If you commit to presenting a
poster at a scientific conference, you
agree to prepare a complete draft of
your poster at least two weeks in advance
of the conference, and to complete a
final 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.
NOTE: Be sure to coordinate with
Jeremy regarding the funding source
covering your poster printing cost prior
to going to print your poster.

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

Subject compensation
Most in-lab experimental subjects will be compensated via t-points.
Coordinate with Paxton in order to receive a t-point allocation well in
advance of the start of the term you wish to run participants.
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 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 Paxton.

NOTE:In some cases, external fund-

ing sources may be available to cover
cash subject payments (e.g. undergraduate Honors Thesis Grants or
Neukom Scholars grants). Coordinate
with Jeremy or Paxton to determine
whether alternative funding sources are
available for your project.

Ask a question, answer a question
This section contains a log of common issues and errors encountered
by lab members, as well as some guidelines on where to seek help
with issues that may arise in the lab. If you encounter an issue you
don’t know how to resolve right away, this is a good place to begin
your efforts.
Common problems and solutions
If you run into a tricky technical issue you think is likely to come
up again, consider adding it to the log, and then adding the solution when you resolve it. Additionally, if you find yourself helping
another lab member with a problem you encountered in the past,
document the problem and its solution here for future lab members.

Git & GitHub
• Trying to clone a GitHub repository results in the following error (often
after updating Mac OS):
xcrun:

error:

invalid active developer path

(/Library/Developer/CommandLineTools), missing xcrun at:
/Library/Developer/CommandLineTools/usr/bin/xcrun

Xcode Command-Line Tools need to be updated. Run
xcode-select --install and follow the prompts.

Testing room computers & running experiments
• Trying to run an experiment in a Docker container results in the following error:
Error response from daemon:

driver failed programming

external connectivity on endpoint :
for 0.0.0.0: failed:
Error:

Bind

port is already allocated

failed to start containers:

The port is the line of communication between the computer’s
local environment and the environment in the Docker container.

This error means the port used by the container you’re trying
to start is already being used by another active container for a
different experiment. You’ll need to stop the other container in
order to free up the port and run yours. Type docker ps to see
a list of active containers. Find the container whose port (in the
PORTS column) matches the port number in the error, and look at
that container’s name (in the NAMES column). Type docker stop
to stop the active container, and you will
be able to start the container for the experiment you are trying to
run.
• Trying to connect to a Jupyter notebook running in a Docker container
results in the following error in the web browser, despite setting up ports
correctly:
ERR_CONNECTION_REFUSED

If your machine is running Docker Toolbox, a legacy version
of Docker, then accessing the container requires navigating to
http://192.168.99.100: rather than localhost:.
If you are not running Docker Toolbox, check that the Dockerfile
contains an EXPOSE command, and upon executing
docker run you include the tag -p :.
Who to go to with questions
This section contains guidelines of where to direct questions related
to technical and interpersonal issues that may arise, or any issues you
encounter not already listed in the sections below. In general, resolving technical issues within the lab saves time, but there will inevitably
be some we cannot resolve on our own. In general, interpersonal
issues should be resolved in accordance with your comfort, but it is
important to be aware of the below resources should you encounter a
situation in which you want to use them.

Tech issues
• For issues related to our lab’s fileserver, seek assistance from
Jeremy.
• For issues with other lab-owned equipment (e.g. computers, research equipment, etc.) Paxton or the senior lab member actively
using the equipment should be your first-sought resource.
• For issues with Dartmouth IT, open a ticket with the Information,
Technology, and Consulting office, or contact Andrew Knutsen.
• For issues related to the the Discovery computing cluster, contact
John Hudson.

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

Lab policy
• If you have a question about the lab’s policies, first try to find 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 reflect the answer.

Specific methods
• If you have questions about specific 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 Overflow are your friends! Often
other people have encountered (and solved!) similar problems, and
sometimes they even share the answers online!
• For more general methods questions, talk to Paxton.
• If you still cannot find an answer to your question, talk 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 Office or the Graduate and Professional
Schools Deans Office
• Dartmouth’s Office of Human Resources
• Dartmouth’s Faculty/Employee Assistance Program
• Dartmouth’s Title IX office (for concerns about sexual misconduct,
harassment, or assault)
• Hanover Police (if criminal activity is involved)

Internal Review Board (IRB) approvals
Experimental protocols and IRB approval forms are maintained and
coordinated through RAPPORT. Typically this system is accessed
directly by Jeremy or Paxton, but if you feel you need access to
RAPPORT then let Jeremy know.
List of active protocols
1. Efficient 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
fitness-related studies (e.g. incorporating fitness 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 Efficient Learning (STUDY00030020). Analog of the Efficient 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.
List of inactive protocols
1. EEG Efficient Learning (STUDY00029881). Analog of the Efficient Learning protocol, but allows for scalp EEG data collection.
This protocol is redundant with the revised Efficiently 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 Paxton.
Consent forms are kept in a locked file cabinet in Jeremy’s office.

TASK: prior to running any non-lab-

member participants in your study,
you must coordinate with Paxton to
verify that (a) your experiment has been
approved by the IRB and (b) your name
is specifically listed on the associated
protocol.

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 satisfies our data security requirements. No personally
identifiable data about our participants may ever be shared outside of the lab.

Checklist and signature page
By signing below, I certify that I have completed the following tasks:

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 proficient in LATEX, allowing me to edit and understand this
lab manual’s source code.
I have submitted one or more edits to the lab manual by making a
pull request to the GitHub repository.
I have added or commented on at least one issue on the lab manual’s GitHub issues page.
I have access to the following lab calendars: Contextual Dynamics
Lab, Out of lab, CDL Resources, CDL class schedule (if applicable),
DHMC Meetings (if applicable), and PBS department events.
I have joined the lab’s Slack account and agree to check it regularly
(at least once per normal business day, excluding days I mark on
the out-of-lab calendar).
I have created a Trello account and have been added to the appropriate lab Trello group(s).
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 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.
I am a paid lab member and have coordinated with Jeremy about
getting added to the weekly snippets Howdy script, or I am an
unpaid lab member.
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 have coordinated with Paxton to indicate my preference to not be
included on the lab website.

I agree to regularly attend lab meetings (unless I have a course
conflict and have informed Jeremy or Paxton).
I agree to set up a beginning-of-term or end-of-term meeting with
Jeremy at least once per term.
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 official lab practices and policies.
I have carefully read through the entire lab manual, and I have
checked off all of the above items to indicate that I have carried
out the indicated tasks. and plan to complete those assigned.
I will send a digital copy (PDF) of the final two pages of this
manual, including checked-off list items, my digital signature, and
today’s date, to contextualdynamics@gmail.com.

Signature

Date

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Page Count                      : 36
Page Mode                       : UseOutlines
Author                          : Jeremy R. Manning, Ph.D.
Title                           : Lab Manual
Subject                         : 
Creator                         : LaTeX with hyperref
Producer                        : pdfTeX-1.40.19
Create Date                     : 2019:01:28 15:40:04-05:00
Modify Date                     : 2019:01:28 15:40:04-05:00
Trapped                         : False
PTEX Fullbanner                 : This is MiKTeX-pdfTeX 2.9.6870 (1.40.19)

EXIF Metadata provided by EXIF.tools

Lab Manual

Navigation menu

Versions of this User Manual:

Views

Navigation