Peelle Lab Manual Peellelab

User Manual: Pdf

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

Peelle Lab Manual
Jonathan Peelle
Department of Otolaryngology
Washington University in Saint Louis
http://peellelab.org/peellelab_manual.pdf
January 21, 2018
1
Contents
1 Introduction 1
2 General 2
2.1 Funding ................................ 2
2.2 Local Collaborators ......................... 2
2.3 Other Collaborators ......................... 3
3 Being in the lab 4
3.1 Everyone ................................ 4
Big picture ............................... 4
Small picture ............................. 5
3.2 The Boss ................................ 5
3.3 Postdocs and Staff Scientists .................... 6
3.4 PhD students ............................. 6
3.5 Employees ............................... 7
Hours .................................. 7
Timesheets .............................. 8
Employee resources ......................... 8
3.6 AuD capstone students ....................... 8
3.7 Undergraduate students ....................... 8
Honors students ........................... 8
Independent study students .................... 9
All undergraduates .......................... 10
3.8 University policies .......................... 10
Employee guidelines ......................... 10
Sexual harassment .......................... 11
4 Communication 12
4.1 Communication within the lab ................... 12
My door ................................ 12
Lab meeting .............................. 14
Basecamp ............................... 14
Wiki .................................. 15
Email .................................. 15
Calendars ............................... 15
i
Cubbies ................................ 15
4.2 Communication outside the lab .................. 16
Phone ................................. 16
Manuscripts .............................. 17
4.3 Abstracts ................................ 19
Talks .................................. 19
Posters ................................. 19
5 Science 20
5.1 Big picture science .......................... 20
Scientiic integrity .......................... 20
Open, accurate, and reproducible science ............. 20
5.2 Practical science ........................... 22
Setting up a research study ..................... 22
Our lab checklist for scientiic publications ............ 23
Participants .............................. 23
Subject payment ........................... 24
Testing locations ........................... 25
Lab notebook ............................. 25
5.3 Computers and data ......................... 25
General guidelines .......................... 25
Backing up your iles and data ................... 26
5.4 Authorship .............................. 26
6 Other 28
6.1 Recommendation letters ...................... 28
7 Frequently asked questions 29
8 Glossary 30
1 Introduction
My goal is to foster an environment of consistent scientiic excellence and
personal development that supports every lab member in reaching their full
potential, and helps us have fun while doing great science. I want you to be
happy and productive while you are here. This manual is a irst point of
reference for current lab members as we strive to achieve these goals, and
serves as a general introduction for prospective members. You can also ind
the lab elsewhere:
Lab website: http://peellelab.org
• Facebook1:http://facebook.com/PeelleLab
Twitter: http://twitter.com/peellelab
There are also a couple of sites accessible only by lab members:
Lab wiki: http://sites.google.com/site/peellelab/
Basecamp: https://3.basecamp.com/3151709/
In general, irm policies are in the lab manual, whereas ways of imple-
menting these policies (i.e., getting stuff done) are on the wiki so that they
can be updated by anyone in the lab. Basecamp organizes tasks that need to
be done (and relevant discussions) for speciic projects, rather than general
principles. Any information that is potentially private should go in a pro-
tected location. (You can read more about various lab resources in §4.1 on
page 12.)
The LaTeX source for the lab manual is available from https://github.
com/jpeelle/peellelab_manual.
I assume the lab manual and wiki are accurate. This means that you should
follow all of the policies and protocols contained in the manual and wiki. If
you notice something that seems to be wrong, please let me know (for the
lab manual) or change it yourself (for the wiki). If there is something in the
lab manual or wiki that you notice people aren’t doing, please bring this up
at lab meeting, or to me, privately—don’t assume this is okay (it’s not).
1What, you haven’t “liked” our page yet?
1
2 General
2.1 Funding
External funding supplies the vast majority of resources needed to conduct
our research, including salary for personnel, equipment, subject payment,
and so on. It is important that we run the lab in a way that shows we use our
research funding wisely.
Our current funding includes:
R01DC014281 from NIDCD, “The neurocognitive basis of listening ef-
fort”. Often called the “lexical competition” grant.
R21DC015884 from NIDCD, “Neural systems supporting speech pro-
cessing in listeners with cochlear implants”.
Funding from NIH (through our own grants or those to collaborators)
means that work in the lab is supported by the taxpaying public.
2.2 Local Collaborators
Joe Culver (Radiology) directs the optical radiology lab and is a co-
investigator on several projects using optical imaging (HD-DOT) to mea-
sure neural responses to speech.
Nico Dosenbach is a pediatric neurologist with whom we are collab-
orating on language studies in patients and optimizing single-subject
language mapping.
Gammon Earhart directs the program in physical therapy and is a col-
laborator on some studies looking at movement and speech.
Jill Firszt (Otolaryngology) directs the adult cochlear implant program.
We are working with Jill on projects related to cognitive processing and
listening effort in listeners with cochlear implants.
Jay Piccirillo (Otolaryngology) is an MD with whom we sometimes work
on issues related to attentional dysfunction in tinnitus. He runs the
Outcomes research group, on the same loor as our lab.
2
CHAPTER 2. GENERAL 3
Mitch Sommers (Psychology): We have several projects with Mitch’s
lab looking at lexical competition, eyetracking, and listening effort.
Kristin Van Engen (Linguistics/Psychology) collaborates on a number
of studies looking at listening effort, accented speech, and memory for
degraded speech.
2.3 Other Collaborators
Matt Davis (MRC Cognition and Brain Sciences Unit) was my super-
visor during a postdoc in Cambridge and we still occasionally work
together on projects looking at the neurobiology of speech compre-
hension.
Jessica Grahn (University of Western Ontario): Beat and rhythm per-
ception, and the effects of musical training on brain structure.
Murray Grossman (Penn) was my mentor during two separate post-
doctoral positions. We are primarily working together on a grant look-
ing at aging and hearing loss during speech comprehension, with Art
Wingield.
Jamie Reilly (Temple): I am working with Jamie on a project examin-
ing object naming and semantic memory in dementia. Fun fact: Jamie
is the only person I know who has published an article on Sherlock
Holmes (sort of).1
Art Wingield (Brandeis) was my PhD advisor and remains a close friend.
In addition to being a co-investigator on the grant with Murray, I look
to Art for wisdom, council, and humor.
1Reilly J, Fisher JL (2012) Sherlock Holmes and the strange case of the missing attri-
bution: A historical note on ”The Grandfather Passage”. Journal of Speech, Language, and
Hearing Research 55:84–88. doi:10.1044/1092-4388(2011/11-0158)
3 Being in the lab
3.1 Everyone
Big picture
We expect each other to:
Push the envelope of scientiic discovery and personal excellence.
Do work we are proud of individually and as a group.
Double-check our work, and be at least a little obsessive.
Be supportive—we’re all in this together.
Be independent when possible, ask for help when necessary.
Communicate honestly, even when it’s dificult.
Share your knowledge. Mentorship takes many forms, but frequently
involves looking out for those more junior.
Work towards proiciency in Unix, Matlab, and R (bonus points for
Python and LaTeX).
Be patient. Including with your PI. He will forget things you just talked
about, and repeat some stories over and over. Them’s the breaks.
Advocate for our own needs, including personal and career goals.
Respect each other’s strengths, weaknesses, differences, and beliefs.
Water the plants when they need it.
Keep everything awesome.
And, for all research projects, to follow the principles discussed in Chap-
ter 5, unless we’ve explicitly discussed an exception.
4
CHAPTER 3. BEING IN THE LAB 5
Small picture
We’re sharing a relatively small space, so please be thoughtful of others, in-
cluding (but not limited to):
With few exceptions, do not come to the lab if you are sick. It’s better
to keep everyone healthy. Health is especially important because we
are in a clinical building with hospital patients here for care, and we
have a responsibility to keep them healthy, too. If you are sick, email
the lab manager or me to let me know you won’t be coming in, and
update your lab calendar to relect the change.
Be considerate with the thermostat. Everyone has different prefer-
ences, so we all need to learn to compromise.
Do not leave food, drinks, or crumbs out in the lab. Please put food
trash in another trash can (not in the lab), especially late in the day or
on Friday (so that food doesn’t stay in the lab overnight).
Lock the door if there is no one in the lab, even if you will only be gone
“a minute”.
Avoid wearing strong perfumes/colognes/etc. in the lab (for the sake
of your coworkers and our participants).
Keep the lab neat—especially in the phone area. Items left unattended
may be cleaned, reclaimed, or recycled.
3.2 The Boss
You can expect me to:
Have a vision of where the lab is going.
Care about your happiness.
Obtain the funding to support the science, and the people, in the lab.
Support you in your career development, including writing letters of
recommendation, introductions to other scientists, conference travel,
and promoting your work as often as possible.
CHAPTER 3. BEING IN THE LAB 6
Support you in your personal growth by giving you lexibility in work-
ing hours and environment, and encouraging you to do things other
than science.
Treat you to coffee.
Make the time to meet with you regularly, read through your manuscripts,
and talk about science.
Obsess over font choice, punctuation, and graphic design.
3.3 Postdocs and Staff Scientists
I expect postdocs to move towards being more PI-like, including giving talks,
writing grants, and cultivating an independent research program (while still
supporting the lab’s research). And, to have (or acquire) the technical and
open science skills listed for PhD students, below.
Postdoc salaries generally follow NIH guidelines (regardless of the source
of funding).
3.4 PhD students
I expect PhD students to:
Know the literature related to their topic like the back of their hand.
Seek out and apply for fellowships and awards (including travel awards,
etc.).
Realize there are times for pulling all nighters, and times for leaving
early to go to the park and enjoy the sunshine.
By the time you’re done, you will have to know how to do statistics and
plots in R, share your work with me using Rmarkdown, use Matlab scripts for
data analyses, know enough Python to navigate presentation in PsychoPy,
and make igures and posters using Adobe Illustrator or a similar graph-
ics program. You will also preregister your experiments when appropriate
(which it almost certainly will be) and share your data and analysis scripts
publicly. The learning curve can be a little steep on these but it’s well worth
CHAPTER 3. BEING IN THE LAB 7
it. (If these aren’t compatible with your goals or interests, my lab is probably
not a good it for you!)
3.5 Employees
I expect paid employees, whether full-time or part-time, to use their time ef-
iciently to support the projects to which they are assigned. Paid employees
will typically have the most interaction with other staff, and with research
participants, and in these contexts especially should be a model of profes-
sionalism.
Hours
Work hours in the lab are 8:30–5:00 (or 9:00–5:30), with 30 minutes for
lunch. If you are testing participants outside of this time, we will adjust ac-
cordingly for those weeks. You are responsible for keeping your hours at
the agreed amount (8 hours per day, 40 hours per week for full-time em-
ployees). To maintain full-time beneits eligibility your hours cannot drop
(much) below 40; if on a given week you work substantially less than 40
hours, vacation time will be used to make up the difference (per HR policy).
Time off should be requested at least 2 weeks in advance, via email. Once
approved (via email) please add to the lab calendar. You are responsible
for making sure you have suficient vacation hours to cover any time off;
otherwise, you will not be paid.
Sick time should also be requested over email. Per HR policy, full-time
employees are allowed up to 5 unveriied sick instances per iscal year (be-
yond this medical veriication is required).
(Note that graduate students, postdocs, and staff scientists are given more
lexibility in their hours, provided they make suficient progress on their
projects. This lexibility does not extend to other paid positions because
we need to maintain a consistent lab presence for scheduling, supporting
undergrads, interacting with other staff, and so on.)
Even if you speak with me in person, it is important to document these re-
quests (and my approval) over email so that we have a record. It is your
responsibility to make sure this happens.
CHAPTER 3. BEING IN THE LAB 8
Timesheets
Hours entered on your timesheet should relect hours actually at work.
Web clock times should be entered from the lab (from a lab computer—
not your cell phone).
Clock out for breaks 30 minutes or longer (this is your lunch).
Submit your timesheet before the due date.
Employee resources
There are many resources and beneits available through human resources
(http://medschoolhr.wustl.edu). These are spelled out to some degree
on the website, and I can also put you in touch with people in the department
or HR who can offer guidance.
3.6 AuD capstone students
I expect AuD students will be organized and independent, and—importantly
manage their time and clinical responsibilities so that they complete a project
by the end of the year, which requires being somewhat strategic in the topic
we pick. The written report is typically due at the end of April, with an oral
presentation in early May.
To actually collect a reasonable amount of data, it is almost always nec-
essary to start collecting data during the Fall semester, which is challenging
because of class and clinic responsibilities. Don’t say I didn’t warn you!
At the outset of your capstone project, please make a to-do list on Base-
camp with planned due dates (see Table 3.1), and keep this updated through-
out the year.
3.7 Undergraduate students
Honors students
Students who have already demonstrated themselves to be careful and in-
dependent workers for a minimum of 3 months may apply to do an hon-
ors project in the lab. The overall project should be discussed in the Spring
CHAPTER 3. BEING IN THE LAB 9
Table 3.1: Deadlines for one-year research projects
Senior honors Capstone
Topic picked Spring of prior year
Stimulus materials inalized September 1
IRB approval inalized September 15
Data collection begun October 1
15 minute lab talk on background Fall semester
Draft of introduction and methods December 20
Complete written draft March 1 April 1
Practice talk April 1 April 15
Final written draft End of April End of April
Oral presentation After Spring break Early May
for completion the following year. Due dates and requirements differ across
programs; check with your individual program for application requirements.
I expect that we will start working on this over the summer before the project
year, whether that involves you working in the lab over the summer, or work-
ing from home.
Because honors projects necessarily rely on lab resources, they need to
it within the overall scope of lab research. I have a list of possible honors
projects to choose from which it within our ongoing research which we can
use as a starting point for our discussions.
The paperwork requirements differ by program. It is your responsibility
to check what the requirements are in your program and department, and
make sure to get your project submitted by the deadline (which might be the
semester before your senior year).
At the outset of your honors project, please make a to-do list on Base-
camp with planned due dates (see Table 3.1), and keep this updated through-
out the year.
Independent study students
Undergraduate students in the lab during the year should enroll in an inde-
pendent study section to receive credit for time in the lab.
Independent study students should plan on producing an annotated bib-
liography of 5–10 articles on their selected topic, and making a 15-minute
CHAPTER 3. BEING IN THE LAB 10
presentation at lab meeting sometime during the semester. (Depending on
what department you are enrolled through, you may have additional require-
ments.)
All undergraduates
I expect undergraduates to be utterly reliable and willing to help with what-
ever projects need it. At a bare minimum, reliability includes showing up
on time, maintaining your hours on the lab calendar, and making sure that
all of your work is accurate (double-check everything). If you ind yourself
without a speciic project:
Ask around to see if you can help with anything.
Look on the wiki under “Essential lab skills” and spend some time
learning something new.
Look on Basecamp for either a wiki page that needs creating/updating,
or other miscellaneous lab tasks that need to be done.
There is enough to do that you should not be bored!
Your irst semester in the lab is an opportunity to see whether continuing
in the lab is a good it; after your irst semester we will meet and discuss
whether you will continue.
3.8 University policies
Employee guidelines
Important guidance on beneits and policies (including time off policies and
the School of Medicine Employee Handbook) are available on the medical
school human resources website: http://hr.med.wustl.edu/Policies/.
It is important that these policies are followed at all times. You are respon-
sible for reviewing the policies and beneits; human resources is a good re-
source and they can help you if you have any questions.
CHAPTER 3. BEING IN THE LAB 11
Sexual harassment
University policy requires that if any faculty member (such as me) becomes
aware of sexual harassment or abuse involving students or employees we
must report it to the Title IX Sexual Harassment Response Coordinator. Coun-
selors and other medical professionals on campus who discuss these issues
in their professional capacity can keep patient conidentiality.
4 Communication
4.1 Communication within the lab
I am usually busier than I’d like to be, and as a result have less time for talk-
ing to folks than I’d like. However, you (lab members) are one of the most
important parts of my job, and I need your help to stay organized and in-
volved in the things I need to be involved in. Some general rules of thumb
are:
1. Be proactive—tell me what you need. This includes coming to knock
on my door even if it seems like you are interrupting, emailing me to
set up a time to meet, or catching me before or after lab meeting. In all
likelihood I will not check in with you as often as I’d like, so it is up to
you to make sure nothing falls through the cracks.
2. Write things down and remind me what we’ve talked about. I would
love to remember everything we decided when we met last week, but
this doesn’t always happen. Don’t hesitate to bring me up to speed
when we meet. Even if I already remember what we are talking about,
a couple of introductory topic sentences will help get me in the right
frame of mind. Be sure to write down everything in your lab notebook
and Basecamp!
3. Read all of the lab documentation: this lab manual, the lab wiki, and
Basecamp. You are responsible for knowing what is in each of these
places, following the rules and guidelines we have set up, and notifying
someone if you ind incorrect information (or if you have questions).
4. I can be the most helpful to everyone if you are a little bit strategic in
what you ask me. Please check the lab wiki, other people in the lab, and
a Google search before shooting me off a question (see Figure 4.1).
My door
Metaphorically my door is always open, but sometimes my door is, physi-
cally, closed. If this is the case:
12
CHAPTER 4. COMMUNICATION 13
Have a question?
Is it in the lab manual? yes you’re done!
no
yes you’re done!
Is it on the wiki?
no
yes update wiki you’re done!
Does google know?
no
yes update wiki you’re done!
Does an undergraduate know?
no
yes update wiki you’re done!
Does a research assistant know?
no
yes update wiki you’re done!
Does a postdoc know?
no
yes update wiki you’re done!
Does your PI know?
no
either you have discovered something super important,
or it probably doesn’t matter that much.
Figure 4.1: Lab decision tree. Answers to all your questions should be in the
wiki!
CHAPTER 4. COMMUNICATION 14
If we have a meeting scheduled please knock! Hopefully I am around.
If we don’t have a meeting scheduled, a closed door generally means I
am trying to do some writing and should not be interrupted. Of course,
if it’s an emergency, please knock anyway. Otherwise, please send me
a Basecamp message or try another time.
Lab meeting
We meet once each week to talk about science together, and to make sure we
have a chance to touch base on administrative and practical issues. There
may even be a snack. Regular attendance and participation is expected (un-
less you have a class or clinical responsibilities during that time).
Basecamp
Basecamp is the main tool for lab communication and is preferred to email
in almost every situation. Please help me by keeping Basecamp up to date!
A few thoughts and tips:
If we have a meeting to talk about your project, take notes on your
laptop right in Basecamp. Make a new discussion with notes from
the day—you can copy these over elsewhere later. (Alternatively, take
notes on paper, but then put it in Basecamp right away so you remem-
ber.)
Use the to-do lists, both for yourself and others (including me). It helps
me see what is coming up, and what things you are thinking about.
Take the time to assign a person responsible when possible (including
yourself, or me).
When you post a message, you can optionally have it emailed to peo-
ple on the project. One of the nice things about Basecamp is that it can
reduce the amount of email we have to read. If you need a response,
or it’s critical I know what you’ve added, then by all means have Base-
camp email me. But if you are just taking notes or updating an ongoing
discussion, uncheck the box and it will save me a few minutes.
I make an effort prioritize Basecamp over email. Most things you would
email me are related to a project, and can thus be a message (or to-do)
CHAPTER 4. COMMUNICATION 15
in Basecamp. The advantage (in addition to me replying to it sooner) is
that it helps loop other people in and keep our discussions organized.
Wiki
The lab wiki is our shared collection of knowledge about how to get things
done in the lab. The lab manual you are reading now is “top down, in that I
am writing the whole thing myself. By contrast the wiki is a shared resource
to which everyone can—and should—contribute. A good rule of thumb is
that if you need to igure out how to do something, someone else in the lab
may someday need to do the same thing. Whenever possible please docu-
ment what you igure out on the wiki, including updating old sections which
may no longer be relevant. Please encourage each other (and those working
with you) to do the same!
Email
When contacting me, please use Basecamp whenever possible. I will try to
reply to emails when I can but please don’t use it for anything urgent if you
can avoid it. If you need to reach me urgently you can call my cell phone, or
call the lab (where someone can get in touch with me).
I try to use Basecamp as much as possible, but sometimes will need to
email you. I expect you will read all email sent to you, and respond (if a
response is needed) within one business day.
Calendars
Accurate calendars are extremely important in managing lab space and re-
sources. It is crucial that everyone use the calendars regularly and ensure
they are accurate. Use the lab calendars and follow the instructions de-
scribed on the wiki.
Cubbies
In the closet are trays (aka “cubbies”) for every lab member. If you have items
you want to leave in the lab (such as papers you are working on), leave them
here rather than out on a table. If you need to leave something for a lab
member, put it here.
CHAPTER 4. COMMUNICATION 16
Please check your cubby when you come into the lab.
4.2 Communication outside the lab
Communicating to people outside the lab is extremely important: your ac-
tions relect not only on yourself, but on the lab, the lab director, the de-
partment, and the university. This is true both for participants (who volun-
teer for our studies) and scientiic colleagues (whose opinions have a direct
impact on our success and opportunity—they are the ones reviewing our
grants and papers!). It is important that every time one of us represents the
lab it is to a high level of quality. The less experience you have, the more
preparation is required. Don’t skimp!
Phone
If the phone rings in the lab, answer it: identify the lab and your name.
Most calls will be from potential (or current) research participants,
so it’s important they view us as professional and competent. “Peelle
Lab. This is [your name here]. How may I help you?” is a great start.
Remember that many people calling will be older and/or have hearing
loss, so speak slowly and clearly.
Check voicemail messages daily to make sure nothing important slips
through.
If someone calls the lab and leaves a message, call them back within
one business day to conirm that we received the call. If they would
like to participate in a study but we can’t schedule them, thank them
for their interest and ask if we can contact them in the future should
one come up (if you actually will). If you are not going to contact them
(or they do not qualify), tell them that we are done recruiting for that
study and do not have anything else available, but thank them for their
interest. Refer to §5.2 (page 23) and the lab wiki for detailed instruc-
tions on scheduling participants and general phone etiquette.
CHAPTER 4. COMMUNICATION 17
Manuscripts
General
Always show a manuscript (or revision) to all authors before submit-
ting it, giving them the opportunity to comment.
Go over page proofs carefully, including the references. There is almost
always a mistake (ours, or introduced by the publisher).
Always give the senior author the opportunity to look at page proofs.
Formatting
When you are out in the big world on your own, you are free to format your
manuscripts however you like. While you’re in the Peelle Lab, when sending
me a draft of a manuscript, please do the following:
Include page numbers.
Include the full author list starting from the irst draft, which helps
clarify any authorship issues or concerns early on.
Include placeholders for all sections (i.e., introduction, methods, re-
sults, discussion, etc.) even if they are empty, so that we can ill them
in as we go. Having placeholders also helps clarify the organization
from the beginning.
Use styles, especially for headings. This will help organization of the
manuscript and make it easy to change font and formatting if need be.
(To make a heading, don’t simply select the text and make it bold; select
the text and then a heading style, such as “Heading 1”.)
While we are sending drafts back and forth, keep the text single-spaced.
If the journal requires double spacing, we can add this at the end.
Embed igures and tables in the body of the manuscript rather than
putting at the end, or in separate iles. Again, we can change this to
match journal guidelines before submitting if need be. It’s much easier
to read and comment on a manuscript if I don’t have to switch back and
forth to different iles for tables and igures.
CHAPTER 4. COMMUNICATION 18
Some of these are good practice; others are simply my own preferences.
However, if you humor me in these, it will decrease my distraction when
reading your writing, and ultimately enable me to be more useful. I’m happy
to send you a blank draft manuscript to get you started.
Your papers should be free of spelling and grammatical errors. There
is no shame in asking for help with this; your fellow labmates, classmates,
or the writing center (http://writingcenter.wustl.edu) are available to
help. The best proofreaders will explain to you why things need to be changed
so that you learn how to be a better writer, rather than simply correcting
your writing. By taking time to clarify your writing early on, you will be-
come a better writer, and also free me up to help you focus on the scientiic
content. If you send me a paper with grammatical errors or sloppy writing I
will return it to you, which is annoying for both of us.
When naming iles, please include your name and a version number. If you
send me a ile called “Research_Statement.docx”, it is likely to get lost—try
“Baldrick_research_statement_v01.docx” (assuming your name is Baldrick
and this is the irst version you are sending me). Renaming iles with
initials when making comments is generally helpful; I would send this ile
back to you named “…_jp.docx”. After you incorporate any changes, you can
then create a new document named “Baldrick_research_statement_v02”.
See also http://www2.stat.duke.edu/~rcs46/lectures_2015/
01-markdown-git/slides/naming-slides/naming-slides.pdf
Figures
If we are still trying to work out what a good igure looks like, I’m happy to
talk this through with you and look at rough drafts. However, if we have a
good idea of what we want in the igure, please send me something as in-
ished and polished as you can make it—this makes it easy for me to give the
most helpful feedback. If you give me something that isn’t your best work, I
will probably just tell you things you already know.
Most igures should be vector art (saved as PDF or EPS iles). Vector-
based iles don’t suffer the artifacts and poor quality that raster-based im-
ages show when magniied. Use a graphing program (such as R, Matlab, or
JASP) to export to an EPS ile, and then modify that ile in Adobe Illustrator
or other image-editing program.
CHAPTER 4. COMMUNICATION 19
Don’t use Microsoft Excel for your igures! It’s never the best option. If you
must organize your data in Excel, that’s ine, but then do plotting in a bet-
ter plotting program (e.g., R, Matlab, or Python). (JASP also makes decent
graphs.)
4.3 Abstracts
Anyone submitting an abstract for a conference, symposium, etc. should
clear this with me irst, and circulate to all authors at least one week before
the submission deadline.
Talks
Anyone giving a talk to a non-lab audience is required to give a practice talk
to the lab at least one week before the real talk. If this is your irst public talk
on a lab project, plan on at least two practice talks (starting at least 2 weeks
before the real talk). Practice talks should be mostly inished (inal slides,
practiced, and the right length) so that our comments will be as helpful as
possible. Schedule one or more meetings with me ahead of time to plan or
go over your slides, especially if you haven’t given many talks before.
Posters
Anyone presenting a poster should circulate an initial version to all authors
at least one week before the printing deadline. Use the lab Adobe Illustrator
template so that our posters have a consistent look to them. If this is your
irst time using Illustrator, make sure to leave plenty of extra time so you can
learn how to use the software.
Make sure to double check the poster size and orientation for the confer-
ence, and the size of the paper or canvas it will be printed on.
For many conferences you will want to bring a sign-up sheet where peo-
ple can request an emailed PDF.
5 Science
5.1 Big picture science
Scientiic integrity
You have a responsibility to me, the institutions that support our work, and
the broader scientiic community to uphold the highest standards of scien-
tiic accuracy and integrity. By being in the lab you agree to adhere to pro-
fessional ethical standards. There is never an excuse for fabricating or mis-
representing data. If you have any questions, or in the unlikely event that
you have concerns about a research practice you have seen in the lab, please
talk to me immediately.
It is also important that you prioritize the accuracy of your work while
in the lab. Unintentional errors due to inattentiveness or rushing can be
extremely damaging and produce results that turn out to be incorrect. Al-
though there is always a pressure for a high quantity of research, it is criti-
cal that everything we do is of the highest quality. Please double-check
your work frequently. In many cases multiple people will double-check a
data set to ensure no mistakes have crept in along the way.
Open, accurate, and reproducible science
For lab manuscripts, we go through a paper checklist1that includes sections
on open science and statistics to encourage us to continually keep these is-
sues in mind.
Open science
We are working towards putting all stimuli, data, and analyses online and
linked to each research publication. The idea is not to simply tick a box of
“open science”, but to make these resources readable and useable for review-
ers and other researchers. In service of this:
Items need to be documented and described. At a minimum, each col-
lection should have a README ile2at the top level that provides de-
1https://github.com/jpeelle/paperchecklist
2http://jonathanpeelle.net/making-a-readme-file
20
CHAPTER 5. SCIENCE 21
tails about the item in question (such as a set of stimuli or an analysis).
Code should be tested, bug-free, and helpfully commented.
Links should be permanent (ideally a DOI).
In pursuit of this high level of organization and documentation, lab mem-
bers will frequently be asked to review and error-check lab materials (in-
cluding sound iles, text lists of stimuli, etc.). Lab members creating stimuli
or conducting research projects should organize them from the outset in a
way that is conducive to eventual sharing (GitHub, ipython notebooks, etc.).
Accurate science
A key part of accuracy is anticipating and avoiding “adverse events” (includ-
ing near misses), and creating structures in the lab that facilitate a high level
of reliability.
Inspired by a blog post on reliability in the lab3we have a page on the lab
wiki for reporting adverse events, and have allocated time at lab meeting to
make sure none slip through the cracks. Examples of adverse events include:
Any of the lab computers malfunctioning (including freezing or crash-
ing)
Not being able to ind the installation disc for a software program
Nearly running out of money to pay participants (this counts as a “near
miss” which we also need to discuss)
As a lab member it is your responsibility to be aware of times when things
don’t go as planned and bring these to the attention of the rest of the group.
Even better, let’s all work together to ind ways of preventing such occur-
rences in the future.
3http://jeffrouder.blogspot.com/2015/03/is-your-lab-highly-reliable.
html
CHAPTER 5. SCIENCE 22
5.2 Practical science
Setting up a research study
Anyone starting a new research project should follow this approach, which
I’ve adapted from other labs. The goal is to have a consistent way of doing
things in the lab that encourages open science, collaboration, and me being
able to understand your project after you have left the lab.
The main repository. Have me start a project on Open Science Frame-
work4(OSF) with you as a contributor for your project. This project
should contain a descriptive README.md ile that gives the study back-
ground and hypotheses, a description of all of the iles in the reposi-
tory, and links to any relevant iles not in the repository. Basically, with
the README.md ile, another researcher should be able to understand
and repeat the study.
Data. The OSF repository should contain the programs used to col-
lect the data (e.g., EPrime, PsychoPy, etc.), any raw non-MRI data, pro-
cessed data used for statistics, etc.
Stimuli. Stimuli should be uploaded to OSF before data collection starts.
These could be in the main repository, but if they might be used by
another study—which is often the case—they should have their own
repository, and be linked from the lab website.
Statistics. Scripts for analysis—for example, from R, Matlab, or JASP
should be in the OSF repository. Scripts should be written to use the
open data as much as possible; for example, by getting data directly
from OSF rather than from the local disk, or by including code to han-
dle MRI data downloaded from a shared repository. Wherever possi-
ble scripts should also generate igures as close to those in the paper
as practical.
Final igures. EPS, PDF, and/or PNG images of inal igures should be
in the repository with an explicit CC-BY creative commons license so
that the igures can be re-used without charge by us and others (e.g.,
in review articles).
4http://osf.io
CHAPTER 5. SCIENCE 23
Our lab checklist for scientiic publications
Anyone writing a manuscript (including an honors or capstone project) should
consult the Peelle Lab Paper Checklist 5and discuss with me before submit-
ting your manuscript (ideally, early on in your project!).
Participants
Our research is made possible by the goodwill and generosity of our research
participants. We not only need people to participate in our studies, but to try
hard to do their best, and potentially return for a future study. Caring for our
participants is one of the most important parts of the lab and something in
which every member plays a role.
The most important thing is that participants must always be conident
that we are professional and treating them with respect. All of the speciic
advice supports these goals. In general, it is helpful to model our interactions
off of other professional situations, such as a doctor’s ofice.
For all participants:
Dress professionally: No jeans, t-shirts, sweatshirts, sneakers, or san-
dals. When in doubt, ask! This is true for both young and older adults—
dressing professionally will help undergraduate participants to take
the experiment seriously.
Answer the phone, and return all phone calls (and emails) promptly.
Tell participants who you are, and where you are calling from: “Hello,
this is [name] calling from the Peelle Lab at Washington University. I
am returning your call from yesterday regarding a research study.
Be prepared to answer questions. If you don’t know the answer, it is
completely ine to ask the participant if someone else can call them
back. You are then responsible for making sure this happens quickly.
Arrive at least 30 minutes prior to testing time to make sure equip-
ment and paperwork are all set, and to be around in the event the par-
ticipant shows up early. Everything should be set up before the par-
ticipant arrives. For people coming from off campus, you should be at
the designated meeting spot 15 minutes before the agreed upon time.
5https://github.com/jpeelle/paperchecklist/blob/master/checklist.pdf
CHAPTER 5. SCIENCE 24
Table 5.1: Terms associated with research studies
Instead of saying: Say this:
experiment study, research study
subject volunteer, participant
test (e.g., “hearing test”) task or screening (“hearing screening”)
For non-students, and especially older adults:
Always use a title (Dr./Ms./Mr.) and a participant’s last name when
addressing them. If you aren’t sure how to pronounce their name, ask
them.
We can also help participants feel more at ease by being thoughtful about
the language we use. For example, participating in a “research study” is more
friendly than being a “subject” in an “experiment”.
Some participants are involved in multiple studies, and they may lose
track of which person is associated with which study. Make sure to remind
participants you are calling or emailing that you are from the Peelle Lab, and
clarify the location for testing when the time comes.
Refer to the lab wiki for speciic information on recruiting, scheduling,
and testing participants.
Subject payment
We typically pay our subjects in cash—this is easier for them, and thus we
are more likely to get repeat subjects. One of the lab members takes out a
travel advance, and then people testing participants will take out what they
need to pay the subjects. Each subject signs a payment sheet to document
that they got paid. Naturally, it is very important that we keep track of this
money.
If you are running subjects and take cash from the advance, you are re-
sponsible for returning signed forms and/or cash equalling that amount.
If you lose the forms, you will have to track down the subject and have
them sign a new one, or pay back the missing cash out of your pocket.
CHAPTER 5. SCIENCE 25
If you are the one taking out the travel advance, you are responsible
for reconciling the advance (and any shortfall not otherwise accounted
for).
Testing locations
Many of our shared testing locations are shared with other researchers,
so it is very important that we are good citizens when it comes to us-
ing these spaces. Being a good citizen includes scheduling the time as
required, not using more than our allotted time, and leaving the room
as clean as we found it (or preferably cleaner).
No Peelle Lab equipment should be left in testing rooms—this includes
laptop, audiometer, microphone, etc. (It all lives in the lab.)
No one should test a subject without signing out the testing room.
See the lab wiki for speciic instructions for various locations.
Lab notebook
Anyone conducting an independent research project should have a lab note-
book for keeping track of discussions, experiments, and taking notes. You
may also want to use an electronic notebook (e.g., Evernote) as your pri-
mary lab notebook, or to supplement a paper copy. The important thing is
that you are keeping notes, and they are in one place.
5.3 Computers and data
General guidelines
Testing laptops should never leave the lab except for testing. Always
sign out the computer and any other equipment (such as the EPrime
dongle) on the lab resources calendar.
Do not install extraneous software or store personal iles on the com-
puters.
CHAPTER 5. SCIENCE 26
Backing up your iles and data
Always assume that as soon as you turn your back the computer on which
you have been working will explode. Thinking such dire thoughts will make
it easier to follow these guidelines:
If you save iles to the shared lab drive, backup will automatically hap-
pen. When working on a lab computer save all of your iles to the
shared drive. If you are working on lab projects on your own computer,
transfer these iles to the shared lab drive regularly to make sure they
are in one place, and backed up.
Full-time employees should back up their computers on an external
hard drive, preferably through an automated backup program (such
as Apple’s Time Machine or SuperDuper!) that runs at least daily.
Data from participants is irreplaceable and should be removed from
testing computers immediately following testing and onto the lab server
in the “outputs” folder for the appropriate study (found in the “projects”
folder). (MRI data is an exception as it is already backed up on CNDA.)
Make sure your work is always backed up.
5.4 Authorship
Many professional associations and journals have published authorship guide-
lines, which are worth looking at (for example: ICMJE). In my view there are
two key requirements to being an author:
1. Contribute to the intellectual scientiic content of the manuscript in a
meaningful way.
2. Contribute to the writing of the manuscript in a meaningful way.
Note that “collect data, “analyze data, or “fund the study” aren’t on the
list. Those are very important parts of a paper, but do not (on their own)
warrant authorship. Being an author means understanding the content and
being willing to take public responsibility for the work: a large part of this
concerns the theoretical motivation and implications of the research. In
CHAPTER 5. SCIENCE 27
practice theoretical contributions are most often made through helping with
the study design, data interpretation, and discussion about a topic.
This doesn’t mean that as an undergraduate student or research assis-
tant you can’t be an author on a paper. Of course, if the study goes well and
you are involved, you might be. However, you will need to know enough (or
learn enough) about the subject to understand what we’ve done, and to sig-
niicantly contribute to the writing. I won’t add you to a paper just because I
like you and want to help you out; I will consider giving you the opportunity
to be involved to a degree that you have earned authorship, if you are willing
to take on the challenge.
Typically one person will take on the main responsibility for writing the
paper, and this person will be the irst author.
I assume that, unless we have talked about it, I will be an author on pa-
pers coming out of the lab. This does not mean that you should add me on to
papers as a courtesy; it means that I expect you to include me in the process
of discussion and writing in a way that merits authorship. In other words,
the same approach I take with you.
It is worth pointing out that there are many views regarding authorship,
and within any view there are always borderline cases. When collaborat-
ing with other people, I tend to defer to their own lab culture. However, it’s
important that within our own lab, we are clear on the expectations for au-
thorship and transparent about authorship discussions and decisions. If you
ever have any questions, please come speak to me.
6 Other
6.1 Recommendation letters
It is part of my job (and, thankfully, quite often a pleasure) to write letters
of recommendation for people in the lab. Please give me as much notice as
possible, and make sure I know the deadline, format (electronic? printed?),
oficial name of the organization, what you are applying for, and so on. Please
also send along a current CV.
If you are an undergraduate, I will write your letters on my own. For
more senior lab members, I will also write your letters on my own, but please
send me a draft of the letter (which I will extensively modify). The irst few
times you do this it will probably feel awkward. However, keep in mind that
your goal is to make it as easy as possible for a letter writer (in this case, me)
to complete the task by the deadline and without error. Even though I will
re-word a lot of the letter, it will still have the name of what you are applying
for and details regarding how long I have known you, the projects you have
worked on, and so on. This is extremely helpful in jogging my memory and
will give me more time to focus on saying good things about you. Don’t worry
about being too “braggy”; I have no problem toning things down if need be.
Like everything else, communication is key, and when in doubt, ask!
28
7 Frequently asked questions
Where are all the FAQs?
No one has asked any questions yet.
If you are looking at a printed version, please write ques-
tions here:
29
8 Glossary
HRPO (“harpo”) (Human Research Protection Ofice)
The ofice in charge of human subjects research and the IRB.
IRB (Institutional Review Board)
The IRB oversees human subjects research and makes sure that re-
search is conducted in a way that protects subjects’ safety and pri-
vacy. Our lab submits protocols to the IRB which describe the research
we want to do; the approved protocol is linked to a particular consent
form that subjects sign when they participate, informing them about
the study.
PI (principal investigator)
In the context of a grant, the PI is the person responsible for making
sure the proposed research gets done. More broadly it refers to a re-
searcher who has their own research group or lab (i.e., someone who
would be in a position to be a PI on a grant, regardless of whether or
not they are currently funded).
project
In our lab, a “project” refers to a speciic IRB protocol, whereas a “study”
is a particular experiment done under this umbrella approval.
study
In our lab, a “study” refers to an experiment (such as “False Hearing
II”) that falls under an umbrella IRB project.
If you are looking at a printed version, please make a list
of terms you’d like deined (feel free to include a suggested
deinition):
30
Reading test
Lab members: If you are looking at a printed version, please write your name
below to indicate you have read the current version of the manual and agree
to follow these policies.
Date Printed name Signature
31

Navigation menu