Lab Guidelines

NYUAD SANAD Research Group Guidelines and Code of Conduct (v1.3).

This document summarizes expectations and code of conduct in the SANAD lab (PIs: Karim Ali and Sarah Nadi) to ensure a smooth and pleasant experience for everyone. It will be updated regularly. Unless a specific role is mentioned, these guidelines apply to all lab members, including PIs, postdocs, and students.

Last Updated: July 23, 2025

Content

1. Inclusivity, Diversity, and Emotional Well-being
2. PI Commitments
3. Expectations of PhD Students
4. Expectations of Postdoctoral Researchers
5. General Lab Guidelines
6. Reproducibility & Research Documentation
7. Writing & Communication
8. Communication Etiquette
9. Conflict Resolution & Feedback Culture
10. Group Citizenship & Roles
11. Attending Conferences
12. Holidays
13. Service Roles in the Community
14. Presentations
15. Publications
16. Writing Papers
17. NYUAD Logistics
18. Onboarding Logistics Checklist
19. References

1. Inclusivity, Diversity, and Emotional Well-being

We are dedicated to creating an inclusive, enjoyable, and safe environment for all our group members to conduct high-quality research. Discrimination or harassment of any sort will not be tolerated. Please conform to the following code of conduct (adapted from Zhang’s lab [3]):

  • All communication, be it online or in person, should be appropriate for a professional audience, and be considerate of people from different cultural backgrounds.

  • Avoid inappropriate language, images, or jokes.

  • Be kind and do not insult or put down others.

  • Harassment includes offensive verbal comments related to gender, sexual orientation, disability, physical appearance, body size, race, religion, sexual images, deliberate intimidation, stalking, following, harassing photography or recording, sustained disruption of discussions, inappropriate physical contact, and unwelcome sexual attention.

  • Stop any behavior if someone expresses discomfort or asks you to.

  • Contribute to discussions in meetings with a constructive, positive approach.

  • Be mindful of talking over others when discussing in groups, and be willing to hear out and give credit to and amplify the ideas of others.

  • Include colleagues at conferences, have a plan for a buddy system, be proactive to include people in conversations and invite colleagues at social-professional gatherings.

If you witness or experience any issue, report it to your supervisor, who will act according to the NYU non-discrimination and anti-harassment policy. If you feel uncomfortable talking to your supervisor, please check other avenues for reporting. NYUAD also offers emotional well-being services to all its employees.

2. PI Commitments

You can expect the PIs to:

  • Meet with you regularly, and provide ample guidance.

  • Provide timely feedback on manuscripts, grants, and talks (1–2 week turnaround).

  • Support your career development (e.g., mentorship, recommendation letters, and networking).

  • Maintain a respectful, inclusive, and well-resourced work environment.

  • Be available for in-person or Slack/email/Zoom conversations.

  • Act promptly on any interpersonal or structural concerns.

3. Expectations of PhD Students

A PhD student is expected to produce a dissertation by the end of their degree and be able to conduct independent research. PhD students are involved in conducting research, writing papers, reviewing papers, supervising more junior students, and presenting their research at various venues. PhD students may also help in creating tutorials or assignments for teaching, especially for those interested in getting teaching experience for their academic career.

3.1. Progress Expectations

  • Finish coursework in New York by June 1st of year 1.

  • Choose the first project/topic by June 1st of year 1.

  • Submit the first paper by December 31st of year 1.

  • Publish at least 4 full peer-reviewed conference/journal papers to graduate.

  • Continuously keep up with related work and become an expert in your area.

3.2. Workstyle Expectations

  • Take ownership of your research and gain independence over time.

  • Meet weekly with your supervisor (and/or postdoc mentor if assigned).

  • Drive meetings with a clear agenda, updates, and discussion points.

  • Plan ahead, identify bottlenecks, and propose solutions.

  • Collaborate with external researchers when appropriate.

  • Maintain all data/code in group GitHub repos and document your work.

  • Mentor undergrads or junior students at least once during your time with the lab.

4. Expectations of Postdoctoral Researchers

  • Lead or co-lead at least one research project within the first 4–5 months.

  • Initiate and propose new research ideas aligned with the goals of the lab.

  • Mentor PhD and undergrads.

  • Limit external collaborations to ~20% of time/output.

  • Submit at least 2-3 publications per year, whether as lead authors or co-authors.

  • Participate in developing courses or training material (e.g., talks, tutorials, labs, assignments) but not expected to grade.

  • Maintain open communication and high standards of documentation.

5. General Lab Guidelines

5.1. Work Hours

  • Work primarily from campus at least 4 days per week, unless otherwise agreed.

  • Core availability: 11am–3pm.

  • No expectation to work weekends or holidays.

  • Occasional, agreed-upon remote work is okay if it helps productivity, particularly during the summer.

  • Honor deadlines even if they fall on a weekend/holiday (e.g., by planning ahead and submitting your work before the weekend/holiday).

5.2. Meetings

  • Attend weekly in-person standups.

  • Attend monthly research presentation meetings (a title and abstract must be ready 1 week in advance).

  • Attend the monthly reading group (paper chosen 1 week in advance).

  • Prepare for end-of-term retrospective meetings.

  • Notify 24 hours in advance if canceling a meeting.

  • Use Geekbot on Slack for daily asynchronous updates.

6. Reproducibility & Research Documentation

  • We strongly believe in open science. As such, all our research should be accompanied by open-source tools, experiments, data, and artifacts. These tools/artifacts should be shared in a GitHub repository in the group’s Github organization (in addition to an archival link on Zenodo or figshare)

  • Whenever you start a new research project, please make sure to organize your tool code, experiment scripts etc. in a GitHub repo.

  • Keep this repo up to date, even with intermediate work. Do NOT wait to commit and push your changes only until you are done. The git history is important and helps us remember why certain changes were made.

  • Follow collaborative software development best practices and use GitHub issues to discuss design decisions, document and keep track of bugs etc. Use branches and pull requests to work on features and integrate them into the main branch when ready.

  • Work in small increments and ask other team members to review your code and changes.

  • ALWAYS have a well-documented README file that allows other team members (and eventually the world!) to run your code and reproduce your results.

  • Automate all experiment steps as much as possible. Ideally, we can re-run the whole experiment by issuing a single command, and all numbers, tables, figures in the paper would get automatically updated.

7. Writing & Communication

  • Write something every week: blog, tutorial, paper draft, etc.

  • Maintain high clarity and accuracy in all writing.

  • Present ideas as a story. Use visuals to support your message.

  • Be receptive to feedback and iterate often.

  • Avoid filler expressions and passive voice.

  • Practice and rehearse presentations with peers.

  • Promote open science through preprints (e.g., arXiv) and artifact sharing after acceptance.

8. Communication Etiquette

  • Use first name to address other group members, including the PIs.

  • Use Slack to reach other group members quickly or for project discussions.

  • Use email for any communication that we may want to go back to in order to dig up attachments, remember what was agreed upon etc. In general, email is a more “documented” format of communication.

  • Use email for sending documents that require signature etc. An email sits in one’s inbox until resolved so it serves as a “todo” item. On the other hand, one may read the message on slack and then forget to go back to it to sign the document etc.

  • Do not use phone calls, text messages, WhatsApp messages for any work-related business unless it’s an emergency or the other person has explicitly asked you to use that for faster communication (e.g., they are traveling and might miss email). This allows us all to separate work from personal life.

  • Be courteous in all your interactions and communication.

9. Conflict Resolution & Feedback Culture

  • Speak up if you’re upset with how something was communicated or executed.

  • Resolve disagreements and conflicts early on; don’t let it bottle up.

  • If you are uncomfortable addressing someone directly, speak to the PIs.

  • Retrospectives are meant for mutual feedback and continuous improvement.

10. Group Citizenship & Roles

  • Participate actively in group meetings, Slack discussions, and lab lunches.

  • Maintain workspace hygiene and keep shared areas tidy.

  • Respect focused time and ask others about their preferred method of communication.

  • Share protocols, tools, and insights with others.

  • Help onboard new members and support their integration.

  • Contribute to group service roles (e.g., webmaster, reading group coordinator).

11. Attending Conferences

  • You published a paper? → You get to travel to present your work! (subject to budget availability but every effort is made to make it happen)

  • Didn’t publish something but want to attend a conference? → You will have at most one event to attend without a publication (subject to budget availability)

  • Actively participate in the conference by asking questions, talking to people during breaks etc.

  • Make the most out of your trip by attending as many relevant co-located events as the budget allows.

  • Share accommodation when possible to reduce travel costs.

  • Sign up and attend mentoring workshops such as PLMW, SMeW!

  • Sign up as a student volunteer!

12. Holidays

  • The number of vacation days varies according to your role, and is governed by your HR contract.

  • Submit vacation day requests on Workday at least one month in advance.

  • Please be mindful of any deadlines we agreed to catch when planning your holidays.

13. Service Roles in the Community

  • Providing service to the international research community is the best way for you to expand your academic network. As such, we may ask you from time to time to review papers or participate in an organizational role for a conference (e.g., serve as web chair, social media chair etc). We may also suggest your name for program committees that allow PhD students or postdocs.

14. Presentations

We are very picky when it comes to presentations. Make use of the group’s presentation meetings to present your work frequently and to also learn from others’ presentations. While you will eventually see the patterns in our repeated feedback, here are a few tips to keep in mind:

  • Your presentation must tell a story. You need to guide the audience through a logical flow of events/info to avoid losing them.

  • Your slides are visual aids. You are the presentation. Design your slides to help you clearly present the info. Do not expect the audience to read a bunch of text (this isn’t a paper!)

  • Keep your slides as visual as possible with minimal text that highlights key info.

  • Always have slide numbers.

  • Do not have a generic “thank you” slide. Keep the last slide as a summary of the most important messages of your talk. Include your name again, artifact link, contact info etc. This slide will likely stay up on the screen while you answer questions so make use of that screen time with useful info!

  • Use large fonts. We aren’t all blessed with great eyesight 🙂

  • If there’s something you put on a slide and then say “this is not important” or “you don’t have to understand this” then ask yourself: do I really need this slide?

  • Your presentation can always be better than the paper describing the work. If you find a better way to present the info, do it! You don’t have to stick to the same tables, figures etc.

  • Be enthusiastic! Speak loudly and clearly. Rehearse, rehearse, rehearse!

15. Publications

  • To be an author on a given submission, you must have made enough contributions to the work. This could be in the form of design feedback, data analysis, tool implementation, running experiments, writing etc. Please see ACM Policy on Authorship.
  • Authors are ordered according to their contribution. Supervisors/Faculty members are typically at the end of the list, also ordered according to contribution. If contribution is equal, the main supervisor of the work is typically listed last in the author list.

16. Writing Papers

The following are concrete guidelines related to writing papers. Also see this guideline for additional info.

16.1 Formatting

  • A good starter

  • Tables: right-align columns with numbers

  • Figure captions always go below the figure; table caption go on top

  • Figures and tables should always be at the top of the page. Actually, do not change the LaTeX placement for them and let it do its thing.

  • Tables should have no vertical lines. Use booktabs package and \toprule, \midrule, and \bottomrule.

  • Use thousand comma separator: 10000 -> 10,000 in both text and plots.

  • For decimal precision, two decimal points is enough.

  • For quoted text, use ``text’’ (not “text”,`blah’, or ‘blah’)

  • Always add a tilde before \cite{} → Bla et al.~\cite{X} show

    • Ali et al.~[3]
    • Ideally use \citet for this use case, either by directly using natbib or the natbib option in biblatex
  • Never start a sentence with \cite{} (citations are not subjects or objects).

    • Don’t do “\cite{123} does this and that” => “[3] does this and that”. Instead, say “Ali et al.~\cite{123} do this and that”
  • Use footnotes sparingly. If you do, the \footnote{} goes after the period if at the end of a sentence → blah blah blah.\footnote{fff}

  • Never start a sentence with any math notation.

  • For any numbers in the text, create an \empirical macro to highlight them for easier revisions. Then renew the command right before submission to remove the highlight. For example,

    • \newcommand{\empirical}[1]{\setlength{\fboxsep}{1pt}\fbox{#1}}
    • \renewcommand{\empirical}[1]{#1}
  • Never use verb contractions (e.g., can’t)

  • Use the following forms for “i.e.,” and “e.g.,” and they are not interchangeable. The former means “that is”, and the later means “for example”.

  • Commas and periods go inside quotes → “blah.” “blah,”

  • In LaTeX, “-“ is the minus sign. Use “–“ for ranges, and almost never use long dashes “—“.

  • Set your locale to US English/Canada and be consistent.

  • Define all your acronyms. Always!

  • Standardize tool names using macros/commands for consistent styling.

16.2 Text

  • Avoid filler expressions such as “As it can be seen”, “Notice that”, “It is worth noting”, “Note that”.

  • Use “such as” instead of “like” when you want to give examples

  • Use the Oxford comma: x, y, and z

  • Spell check your text!!! Never push text that you haven’t spell-checked.

  • Also, proof-read the whole paragraph after fixing a sentence (especially based on some discussion that we had)

  • Never mix present and past tense. “We started with this, then we select that”

    • Use present tense for factual things
  • Never use passive forms

    • “The epsilon parameter is set to 0.1” -> “We set epsilon to 0.1”

16.3 Plots

  • Never generate plots in excel/numbers/etc. Use scripts to generate your plots and design the scripts such that it’s easy to regenerate them as needed. Ideally, even generate your latex table such that they can get repopulated if you need to re-run your experiments.

  • Use the largest possible font in your plots for clarity

  • Make sure to export plots at high resolution (in a vector format). PDF works best for that.

16.4 Bibliography

  • Always use @String for conference names for consistency

  • Export the Bibtex entries from DBLP as much as possible, again for consistency.

  • Do not cite the arXiv version if the paper itself is published later at a conference

  • Remove useless fields from the bib file (publisher, city, abstract, etc.)

16.5 Git

  • Use a git repo for your paper; Do not use Overleaf. If you really must, then synchronize it with a git repo in the group’s GitHub organization.

  • Commit latex changes incrementally. Don’t wait to be “done”, nobody is ever done :)

  • Do not force line breaks. Just use soft-wrapping because folks use different editors.

  • Always make sure your LaTeX project compiles before committing.

  • Do not push intermediate latex files in the repo (e.g., .log, .aux). You can do this by adding an appropriate .gitignore file.

  • Each section should be in a separate file

  • Each table/figure should be in its own file that gets included in a LaTeX file using the \input command

  • Your main directory should have separate folders for “tables”, “figures”, and “sections”. Later on, it should also have “reviews” and “submissions”

  • The repo should have one file for all your macros, and another for all your packages. Don’t mix them together. That also makes it easier to port to other repos.

17. NYUAD Logistics

  • If you need to pay any equipment or pay conference registration fees etc., please talk to your supervisor to get approval and then use this form to request the CS administrator to pay the fees for you using their Pcard.

18. Onboarding Logistics Checklist

  • Add to slack workspace

  • Add to github org

  • Add to private group calendar

  • Subscribe to public group calendar (link)

  • Add group member profile to website

  • Announce new group member on social media (publicity)

References

We have consulted the following public code of conduct resources for inspiration when creating this document: