Onboarding checklist for new students

Welcome to the lab. This page lists the things you should do in your first week or two, so that you can start contributing to your project quickly and communicate well with me and the rest of the group.

1. Read the lab guidelines

Before your first project meeting, read the following. They describe how I expect us to work together, and following them will save both of us a lot of time.

Guidelines for project meetings — how to prepare for, run, and follow up on our weekly meetings. If your project is new, also create a new shared PPTX file for your project's running meeting notes, and share it with me.
Scientific debugging your project — how to report and analyze results, especially negative ones.

2. Join the lab Discord

The lab uses Discord for most day-to-day communication, including a channel dedicated to the weekly paper reading. If you do not already have a Discord account, register at discord.com, then email me your Discord handle (username#0000) and I will add you to the BBVisual Lab server and the weekly paper-reading channel.

3. Weekly paper reading

All BBVisual Lab members are expected to read technical papers each week to stay sharp, broaden their knowledge, and discover relevant tools or methods. Whether you are still exploring research ideas or already deep into your project, regular paper reading is essential.

Each week, report the most valuable paper you read in the previous week via the submission form: paper reading form. If there is a paper you would like Prof. Minh Hoai to read to make future discussions more productive (and avoid repeated clarifying questions), be sure to indicate that in the form.

4. Create your project repository on the lab GitHub

For every project you work on in the lab, code must live under the lab GitHub organization, not under your personal account. This makes it much easier to hand over projects, share resources between people, and keep the lab's outputs discoverable after you leave.

The lab organization is BBVisual on GitHub. Ask me to add you as a member of the organization, then create a new repository under it for your project. Add everyone actively involved in the project as collaborators.

Do not start on a personal account with a plan to “move it later”. Moving repos after the fact is painful, breaks links, and often does not happen.

5. Collaboration — what is fine, and what needs my approval

In general, I strongly encourage discussion and mutual help. It is completely fine (and expected) to:

Talk about your ideas and methods with other lab members.
Explain your approach out loud, practice elevator pitches and presentations, and get feedback on drafts.
Help others by proofreading their writing, giving code review, or discussing their results, and ask others to do the same for you.

None of that needs my approval, and none of it makes anyone a co-author.

What does need my approval is co-authorship or any deeper involvement in the project. Casual discussion does not automatically entitle the other person to co-authorship, and you should not offer or agree to it on your own. Co-authorship carries a very different level of commitment and expectation, and there are often issues around project confidentiality, intellectual property, and prior agreements that you may not be aware of. Before adding anyone as a co-author, or before letting someone take on a substantive role in your project (running experiments, contributing significant code, writing sections of the paper), check with me first.

Similarly, if you are a full-time PhD or MS student on a lab scholarship, you cannot work on another research project without letting me know first. You are being paid to focus on the lab's projects, and I need to know what your time is going into. In general I am supportive of side involvement, but I must know about it before it starts, not after.

When in doubt, ask. It is much easier to answer a quick “can I do X?” than to untangle a situation after the fact.