Our code of conduct

Listing our projects here

Table of Contents


Welcome to the Biodata Analysis Group. This manual was developed by me, Fotis Psomopoulos. It is intended to represent my vision for how the lab should function and to complement existing CERTH and INAB policies (which take precedence). Upon joining the lab, all lab members are required to read the lab manual and sign a form indicating that they have done so. I expect that more information will be added and some sections will be revised as the lab grows and develops. If you have any comments or suggestions regarding the contents of this manual, please tell me.

The BioDAG manual was inspired by other similar works. In some places, I have adapted or reproduced content from the Peelle lab manual, the Maureen Ritchey Memory Modulation Lab manual and the The Wright Lab CoC. This work is licensed under a CC Attribution 4.0 license.

Lab member expectations and responsibilities


Big picture

  • Do work that you are proud of. Do work that others will care about.
  • Double-check your work. Being a little obsessive is essential to good science.
  • Be supportive of your labmates. We are a team.
  • Work independently when you can, ask for help when you need it.
  • Share your knowledge. Mentorship can take many forms.
  • Respect each others’ strengths, weaknesses, differences, and beliefs.
  • Science is a marathon, not a sprint. Take personal time/ vacation when you need it and cultivate a life outside of the lab. Respect that other lab members also have a life outside of lab.
  • Communicate openly and respectfully with other members of the lab.
  • If you have an issue with another lab member that cannot be solved by talking with them about it, please talk with Fotis. If you have an issue with Fotis, please reach out to another Researcher or the Institute Director who can intervene for more serious issues.
  • Academia may feel different from other types of jobs, but it is still a job. You should treat coming into lab with the same respect that you would treat any other position. See Hours.

Small picture

  • Do not come into the lab if you are sick. Stay home and get healthy, and don’t risk getting others sick.
  • Notify me if you will be out, either due to illness or vacation. Make a note on the lab calendar. If you are sick and you had meetings scheduled that day, notify your participants or collaborators and reschedule.
  • You are not expected to come into lab on staff holidays or if you’re taking your vacation time.
  • Lock the doors to the lab if no one else is around, even if you’re stepping out for a minute.
  • Keep the lab tidy. Food messes should be cleaned up promptly, dirty dishes taken home with you, and common areas should be kept free of clutter. Items left unattended may be cleaned, reclaimed, or recycled. If you’re using lab equipment, put it away when you’re done.
  • The dress code in academia is generally casual. My only request is that you look semi-professional when interacting with participants and when presenting your work. Jeans are fine, gym clothes and pajamas are not.
  • Arrive to lab at least 15 minutes before you have any meetings scheduled, so that you will be there to greet the participants.


All of the above, plus you can expect me to:

  • Maintain a vision of where the lab is going
  • Provide the funding necessary to keep the lab going
  • Meet with you regularly to discuss your research projects. The definition of “regularly” may change over time or over the course of a project, but for now, I mean once a week or more often as needed.
  • Give you my perspective on academia and issues related to professional development
  • Support your career development by introducing you to other researchers in the field, writing recommendation letters for you, providing you with opportunities to attend conferences when possible, and promoting your work in talks
  • Care about you as a person and not just a scientist
  • Maintain “office hours” for the lab. See Hours.
  • Maintain the lab paperwork (e.g., archiving consent forms).
  • Oversee the hiring, scheduling, and training of new lab members.
  • Assist with participant recruitment and scheduling.


All of the above, plus you will be expected to:

  • Develop your own independent line of research
  • Mentor undergraduate and PhD students on their research projects, when asked or when appropriate
  • Apply for external funding (e.g., EHA, Marie-Curie). I will hire postdocs only when there is funding available for at least a year; however, applying for external funding is a valuable experience and, if awarded, it will release those dedicated funds for other purposes.
  • Apply for jobs (academic or industry) as soon as you are “ready” and/or by the end of beginning of your third year as a postdoc.
  • If you are planning to pursue a non-academic career, treat your postdoctoral research as seriously as you might if you were pursuing an academic career. We can discuss ways of making sure that you are getting the training you need, while still doing excellent research.
  • Remind me (the PI) that different scientific opinions can co-exist in the same lab!

PhD students

All of the above, plus you will be expected to:

  • Develop a line of dissertation research. Ideally, your dissertation research will consist of at least 3 experiments that can be packaged into one thesis document.
  • Apply for external funding (e.g., GSRT, ???). If nothing else, this is an extremely valuable experience.
  • Do some soul-searching as to what type of career you want to pursue, e.g., academic jobs that are research-focused or teaching-focused, non-academic jobs like data science or science writing. We can brainstorm ways of making sure you are getting the training that you need.
  • Work with undergraduate students doing their diploma thesis at the lab, as well as with the short-term interns. This will speed up the coding process and give you some experience with managing and mentoring a team.
  • Stay up-to-date (and keep me up-to-date) on any deadlines that you need to meet to fulfill departmental requirements.
  • Prioritize time for research. It is easy to get caught up in experiments and coding, but at the end of 4-ish years, you need to have completed a dissertation.

Other full-time staff

All of the above, plus you will be expected to:

  • Work on your own research project.
  • Assist other lab members with data collection or analysis (typically you will be assigned to particular projects).
  • Help to maintain an atmosphere of professionalism within the lab.
  • Maintain the lab website together with the other members of the Lab.
  • Provide extra support to the lab manager.

Undergraduate students

All of the above, plus you will be expected to:

  • Assist other lab members with data collection or analysis (typically you will be assigned to particular projects).
  • Work with your research mentor to determine your weekly schedule. If you are not able to come in during your normal scheduled time, you must let your mentor know.

Code of conduct


Many topics were covered already in the Lab member expectations & responsibilities section.

In addition:

All members of the lab, along with visitors, are expected to agree with the following code of conduct. We will enforce this code as needed. We expect cooperation from all members to help ensuring a safe environment for everybody.

The Quick Version

The lab is dedicated to providing a harassment-free experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, or religion (or lack thereof). We do not tolerate harassment of lab members in any form. Sexual language and imagery is generally not appropriate for any lab venue, including lab meetings, presentations, or discussions.

The Less Quick Version

Harassment includes offensive verbal comments related to gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, religion, sexual images in public spaces, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of talks or other events, inappropriate physical contact, and unwelcome sexual attention.

Members asked to stop any harassing behavior are expected to comply immediately.

If you are being harassed, notice that someone else is being harassed, or have any other concerns, please contact Maureen Ritchey immediately. If Fotis is the cause of your concern, then please reach out to the Institute Director or another trusted Institute staff member who can assist.

We expect members to follow these guidelines at any lab-related event.

This section was adapted from: code of conduct. Original source and credit: http://2012.jsconf.us/#/about & The Ada Initiative. This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Scientific integrity

Reproducible research

Reproducible research is research that can be exactly reproduced. This is related to replicability, in that it has to do with your ability to get the same results again, but it refers specifically to getting the same results given the same set of data. I expect that all of our research will be, at minimum, reproducible (I hope that it will also be replicable).

Conducting reproducible research is more difficult than it sounds, because it requires that you are organized and possess sufficient foresight to document each step of your research process. There are two main things you can do to improve the reproducibility of your research: 1) extensive note-taking (i.e., as much as you can manage) and 2) programming workflows with version control.

Programming workflows help with reproducibility because they take some of the human element out, and in an ideal scenario, you are left with a script or series of scripts that takes data from raw form to final product. Programming alone is not enough, though, because people can easily forget which script changes they made and when. Therefore, all projects that involve programming of any kind (so basically, all projects) must use some form of version control. I strongly recommend git in combination with GitHub (see below), unless you have a pre-existing workflow. This is a hard requirement because a) it is the only way to definitively track the evolution of methods/files over time, b) it allows for easier detection of bugs, c) it facilitates code sharing, and d) it has nice side effects for workflow organization (e.g., thinking in terms of commits, branches, issues). Points a, b, and c are directly relevant to the mission of conducting reproducible research.


We will follow APA guidelines with respect to authorship:

“Authorship credit should reflect the individual’s contribution to the study. An author is considered anyone involved with initial research design, data collection and analysis, manuscript drafting, and final approval. However, the following do not necessarily qualify for authorship: providing funding or resources, mentorship, or contributing research but not helping with the publication itself. The primary author assumes responsibility for the publication, making sure that the data are accurate, that all deserving authors have been credited, that all authors have given their approval to the final draft; and handles responses to inquiries after the manuscript is published.”

Authorship will be discussed prior to the beginning of a new project, so that expectations are clearly defined. However, changes to authorship may occur over the course of a project if a new person becomes involved or if someone is not fulfilling their planned role. In general, I expect that PhD students and postdocs will be first authors on publications on which they are the primary lead, and I will be the last author.

Old projects

For projects that required significant lab resources (i.e. any study requiring a great deal of time, money, or lab effort): Project “ownership” expires 3 years after data collection has ended and/or a first software proof-of-concept was coded (or whenever the original primary lead relinquishes their rights to the study, whichever comes first). At that point, I reserve the right to re-assign the project (or not) as needed to expedite publication. This policy is intended to avoid situations in which prior effort languishes for a long period of time, while still giving publication priority to the original primary lead.

Lab Resources


Slack will be used as the primary means of lab communication, such as general lab announcements (#general), sharing links, sharing and/or discussing papers (#papers), and basically any message that can be sent without email. There are also dedicated channels for code-related issues / support, as well as for methods, tips and specific projects. Try to keep each channel on topic, so that people can subscribe only to the channels that concern them. For messages to one person or a small group of people, use the direct message channels.

Full-time lab members should install Slack to their computers and/or phones. Part-time lab members should check Slack regularly. I get Slack updates on my phone and have do-not-disturb mode enabled for evening and night hours (meaning I will not get your messages then); I encourage you to do the same.


All projects that involve programming of any kind must use some form of version control. We have a GitHub organization set up with unlimited private repositories, allowing you to sync your code to the cloud and share it easily with other lab members. We will also use GitHub for sharing script examples and hosting lab toolboxes for general use.

Google Calendar

Google Calendar is used to host a general lab calendar (BioDAG), as well as calendars for the in-lab testing rooms.

General policies


One of the benefits of a career in academic research is that it is typically more flexible than other kinds of jobs. However, you should still treat it like a job. If you are employed for 40 hours a week, you should be working 40 hours a week. This applies to lab staff members, postdocs and PhD students.

Lab staff members are expected to keep regular office hours (e.g., somewhere in the ballpark of 9-5). PhD students and postdocs have more flexibility. However, in order to encourage lab interaction, I expect that all lab members will be in the lab, at minimum, most weekdays between 11am and 3pm or so.

PI office hours

In addition to poking my head into the lab regularly, I will be in my office with the door open for at least an hour every day that I’m on site (most days). Feel free to interrupt me during that time. Because I am easily distracted, I ask that if my door is closed, send me a message or try me later rather than knock.


Weekly lab meetings

Weekly lab meetings will be focused on project presentations and going over new data or methods. Lab meetings will last no longer than 1 hour. If at the end of 1 hour, we need more time to discuss something, we will either take a break before continuing or schedule another meeting. All full-time lab members are expected to attend the weekly lab meeting. All part-time lab members (including undergraduates) are welcome to attend but attendance is not required.

Individual meetings

At the beginning of each semester, I will set a schedule to meet with each full-time lab member for one hour a week. If we do not have anything to discuss in a given week, that’s fine- we can just say hi or cancel it.


If you need something from me by a particular deadline, please inform me as soon as you are aware of the deadline so that I can allocate my time as efficiently as possible. I will expect at least one week’s notice, but I greatly prefer two weeks’ notice. I will require two weeks’ notice for letters of recommendation. If you do not adhere to these guidelines, I may not be able to meet your deadline. Please note that this applies to reading/ commenting on abstracts, papers, and manuscripts, in addition to filling out paperwork, etc.


I encourage you to seek out opportunities to present your research to the department, research community, or general public. If you are going to give a presentation (including posters and talks), please be prepared to give a practice presentation to the lab at least one week ahead of time. Not only will this help you feel comfortable with the presentation, it will give you time to implement any feedback. I care about practice presentations because a) presenting your work is a huge part of being successful in science and it’s important that you practice those skills as often as possible, and b) you are going to be representing not only yourself but also the rest of the lab.

Lab travel

The lab will typically pay for full-time lab members to present their work at major conferences (e.g., ECCB, ISMB). In general, the work should be “new” in that it has not been presented previously, and it should be appropriate for the conference. When I set our grant budgets, I estimate €1000 per trip, so your reimbursable costs should be around that amount or less. Meal costs will be reimbursed for people who are presenting work from the lab. The lab will also pay for new grad students and postdocs to attend one conference in their first year in lab. If travel expenses are being paid off of a grant, additional restrictions may apply (talk to me). All of these guidelines, of course, depend on the availability of funds.

Recommendation letters

Letters of recommendation are one of the many benefits of working in a research lab. I will write a letter for any student or lab member who has spent at least one year in the lab. Letters will be provided for shorter-term lab members in exceptional circumstances (e.g., new PhD students or postdocs applying for fellowships). I maintain this policy because I do not think that I can adequately evaluate someone who has been around for less than a year.

To request a letter of recommendation, please adhere to the deadline requirements described above. Send me your current CV and any relevant instructions for the contents of the letter. If you are applying for a grant, send me your specific aims or a short summary of the grant. In some but not all cases, I may ask you to draft a letter, which I will then revise to be consistent with my evaluation. This will ensure that I do not miss any details about your work that you think are relevant to the position you’re applying for, and it will also help me complete the letter in a timely fashion.

Software and Data management

Storing active datasets

In general, data will be stored in one of three places:

  • Lab folder on secure Institute owncloud server
    • Data to store here: documents
  • Institute Linux cluster
  • Data to store here: MRI and EEG data (identifiable data ok)

Both of these locations are approved by the Institute ISO standard. They are all backed up regularly, which make them particularly appealing options for data storage. In general, you should not store data locally on your computer unless it is being synced with your owncloud folder (de-identified data only).

Software template

Any new software project should fork the template from the group github organization.

The structure is as follows:

  • ProjectName/Data
    • contains a folder for raw data - always keep a copy of the raw (i.e., unprocessed) data & keep it separate from the copy that you’re using in your pipeline
    • subject folders s01, s02, etc for processed data
    • this folder also contains a file documenting demographic & other summary info
  • ProjectName/Analysis
  • contains folders for each type of analysis, e.g., AnalysisOne, AnalysisTwo etc
  • ProjectName/Task
  • contains folders for stimuli & presentation scripts, as well as any piloting info/data
  • ProjectName/Resources
  • contains miscellaneous resources relevant to a project, e.g., ROIs, papers that are direct references for particular methods
  • ProjectName/Scripts
  • contains subfolders for different kinds of scripts, e.g., behav, preproc, helper, model, mvpa, etc
  • the Scripts folder is git-tracked & contains a README.md file that describes as much info as possible about the study
  • if you are using both git & Google Drive, make sure that you are not syncing the Scripts folder to Google Drive because that will mess up git. Conversely, don’t sync stimuli & data files to git because that will blow up your repo over time. Use symbolic links to tie everything together.

I encourage you to use an organization scheme like this one. When you archive the dataset, you will be required to format it like this (or something similarly transparent in its organization), so might as well start that way. For neuroimaging datasets, you should additionally consult the BIDS framework.

Archiving inactive datasets

Before you leave the lab, you will be required to document and archive any dataset that you have collected. I will review the dataset with you before you leave. [To add: information about where to archive data]

Data sharing

Not only is data-sharing the right thing to do, we are actually required to do so for any dataset that was funded by the NIH. We will make these datasets publicly available within a year of publishing the first paper from the dataset. You should also be prepared to share any scripts that you used in your published processing & analysis pipeline. Currently, the best option for sharing smaller datasets seems to be the Open Science Framework.

FAQ and who to ask

TBD. Ask me some questions.