Lab Policies and Work Practices

A research lab is a small community, and I strive to foster a collaborative environment where every member can not only succeed, but also grow and shine. As such, I provide this post, adapted from Tamara Munzner’s lab policies, to help distill my own lab policies and work practices which you can expect to experience in my lab. This will be a living blog post which I will continue to add to and edit as time goes on.

The Big Things

• Support each other. Even if you’re not directly involved in a project, lend a hand when you can and be a kind, supportive presence for your lab members. Science thrives on collaboration (one of the reasons I ask that you work in-person for the majority of the week), not competition. When you support others, they’ll be there to support you too.
• Respect one another. Be mindful of your lab members personal space, preferences, and identities. Respect differences in culture, religion, beliefs, and sexual orientation. Everyone deserves to feel welcome and safe in the lab. Discrimination or harassment of any kind will not be tolerated. If you are facing discrimination of any kind, please come talk to me.
• Speak up if you’re struggling. Science, a graduate program, and moving half way across the world, can be challenging, and your well-being matters. If you are having a hard time, please talk to someone. This could be me, on-campus resources, or city-wide resources. Whatever you are facing, you don’t have to face it alone.
• Work with care. Avoid rushing through tasks; it often leads to wasted resources or avoidable mistakes. Mistakes are a natural part of science, but we should aim to minimize them through thoughtful, careful work.
• Own and correct mistakes. If you make a mistake, especially one that affects shared data, collaborators, or lab equipment, be honest, communicate it, correct it, and move forward. Transparency builds trust and keeps science reliable and relationships intact.
• Maintain integrity. Scientific honesty is non-negotiable. Plagiarism, data manipulation, and fabrication are never acceptable. Negative or unexpected results are still valuable. We’re here to do meaningful, rigorous science, not just flashy science. Academic misconduct, those mentioned above and in all other forms, will not be tolerated. Depending on the circumstances, this can lead to expulsion from the program. If you are unsure what is academic misconduct, such as what constitutes plaigarism, it is best to come talk to me to gain clarity.
• Address conflict early. If you experience conflict, tension, or discomfort in the lab, it’s important to address it promptly. If you are not comfortable raising it directly with the person involved, or if the issue is escalating, please come talk to me (you can even leave an anonymous note under my office door if you’d prefer).

Work Time and Patterns

In the real world, you are judged by results and not effort. If you are delivering results, meeting deadlines, and succeeding at the level expected, then I will afford more flexibility in work patterns. However, to start, I will expect you to be on campus and in the lab during regular work hours throughout the week. This is done for a few reasons:

1. I will frequently stop by the lab for one-on-one check-ins to see how things are going, offer advice, and answer any questions you may have. These informal meetings help keep us aligned, provide regular opportunities for you to share thoughts, concerns, and successes, and support ongoing communication.
2. Engaging in conversations with fellow lab members and other graduate students helps you make friends, stay grounded, and recognize that others are facing similar challenges. These interactions can foster connections (especially as you may have moved to Winnipeg by yourself), encourage mutual support, and contribute to a sense of community within the lab.
3. Most people work during the day, so lab tours and other visits typically occur during regular working hours. These events are a great opportunity to showcase your work, build external connections, and practice presenting your projects.

If you are producing results, there is some flexibility to the above, however, I will always expect that you spend a reasonable amount of time on campus and in the lab (i.e., three or four days a week for at least a few hours during the regular work day). That is, I will not allow a fully, or even majority, remote work experience. If and when we get to this point, we will discuss a plan together which outlines which days you will be on campus and other work expectations.

Generally, you are not expected to be in the lab, or working, during the evenings, weekends, and holidays. While there may be a period of time where you enjoy spending all of your time working (or feel like you must to meet a deadline), it is important to offset these periods with other relaxing and/or fulfilling endeavours. This is something I struggled with during my own PhD, and now strive to do better. While I still don’t necessarily always strike the perfect balance, I aim to make time for the things in both my personal and professional life that bring me joy. To this effect, I also encourage that students take two weeks off throughout the year, on top of the reading breaks during the fall and winter semesters, as well as the holiday season towards the end of the calendar year. When taking off time, it should be requested and discussed with me as soon as possible and prior to any time off.

Equipment

Treat equipment you use like you are borrowing it from a friend…they are probably going to be quite upset if you don’t return it in the condition you borrowed it in. Largely, you will be assigned and responsible for a piece of equipment to use throughout your degree (e.g., an Apple Watch and Mac Mini). However, for the equipment that is shared amongst the lab members, communication will be needed to ensure it is not doubly booked. I have not yet come across the need for a booking/reservation system, but we will cross that bridge if needed. Finally, if something isn’t working, let me know as soon as possible!

Meetings and Communication

Our lab uses Slack to stay in contact with each other and M365 for calendar invites and scheduling. Upon joining the lab you will be invited to join the lab’s workspace and shared calendar. On Slack you can direct message me, other lab members, and take part in public and private channels (often used for specific projects). One such channel is the #standup channel which students use weekly to update me on their progress. This invovles highlighting the work accomplished the previous week, expected work goals for the current week, and anything blocking you from progressing.

Depending on my teaching schedule and lab members’ class schedules, we hold a 15-30 minute in-person round table each morning (i.e., typically at 9am each morning). This offers the chance to let me know what you will be doing that day, to answer any questions you may have, to keep other lab members attuned to your progress and goals, and allow for impromptu discussion about anything that is necessary. This ensures you have some face-to-face communication with me each day, irregardless of my schedule. Most days, I will aim to drop-in on the lab throughout the day to further chat with you about your work and anything else that needs discussing.

Once a week, our entire lab will meet for a group meeting. Sometimes, as necessary, we will schedule more meetings (e.g., around a big submission deadline). This meeting time changes each semester to accommdate everyones schedules. When not in paper writing mode (i.e., doing a pre-paper talk as discussed below in Project Lifecycle), we typically read other published papers, present them, and critique them on a variety of different aspects (e.g., methods, paper writing, meta-ideation, etc.). Other times we will do work-in-progress talks which allow a student to share what they are working on and to invigorate discussion, I may bring in an oustide speaker or present myself on something pertinent, or a student may practice and elicit feedback on their conference presentation talk. Throughout, it is expected that students, and I, take the time to prepare for the meeting in any way requested by the presenter and that we all contribute to the discussions that take place.

I will schedule one-on-one meetings with you typically for an hour a week, with additional meetings scheduled as necessary (i.e., during a build-up to a paper submission). This is primarily an opportunity to dive deeper into your project and its progress, giving us time to address any questions you have and discuss any concerns, whether related to the project, the lab, or even something more broad.

I also expect you to attend each of the Applied Computer Science Speaker Series presentations put on by the department. These are typically once every two months, and bring in external researchers to discuss their work and findings. In our weekly lab meeting after the presentation, we will discuss our impressions and thoughts about the presentation. As a bonus, there is free pizza and pop at these presentations!

Project Lifecycle

As a project idea begins to develop (i.e., as we informally discuss an idea), one of the first things that I will ask of you is to put together a pre-project presentation which you will give to the lab. This will involve giving a 20-30 minute presentation that covers most main elements of a paper (i.e., introduction, related work, anticipated study design, anticipated results). Presenting, rather than writing, at this stage helps to invigoriate discussion, articulate contributions, distill critical methods, create early figures, and put us all on the same page, all without getting caught up in the more difficult process of writing.

Once we are happy with the direction of the project, we can begin working towards conducting a study (or studies). Depending on the project, this could mean working on application development, study implementation, preparing focus group materials, interview practice, etc. One thing that most all projects will have in common is the need to apply for ethics approval to run our studies. This process can take up to 6 weeks at the University of Winnipeg. As such, it is something we are required to do as early as possible. I will offer you templates of past approved ethics protocols (ideally sharing one that has a similar methodology), have you fill in a new protocol application, and we will then review the application together prior to submitting for review.

Upon completing, or nearing completion of your study (or studies), I will again ask that you prepare a presentation for the lab, this time a pre-paper presentation (i.e., a more refined version of the pre-project presentation). While at this point, you should have been working on writing throughout, a pre-paper presentation will inevitably allow us to discover and discuss places to make it better, including clarification of the contributions and reordering of arguments. You can think of the pre-paper presentation as rapid prototyping for your writing, without the actual writing. We will iterate on the slide deck through our one-on-one meetings, until we are both satisfied, prior to you sharing with the lab. After the lab’s feedback (ideally and inevitably there is substantial and useful comments despite all the work we put into the pre-paper talk phase), we will keep iterating on the paper writing (see more about paper writing below).

You can expect a project, from idea inception to submitting the paper, to take anywhere from 8 months to a year. While there are projects that take less time, this timeline offers flexibility in the project lifecycle. Things such as debugging implementations, running pilot studies, submitting ethics ammendments, waiting for application reviews, recruiting participants, re-analyzing data, or refining your writing/presentation, all while perhaps taking courses, being involved in extra-curriculars, and/or doing an internship, inevitably take more time than you’d think. This is okay, and expected.

Paper Writing

Writing is a process that takes an immense amount of time, even more so for non-native English speakers. As such, in an extreme yet often used approach, writing a shell of the paper and slowly filling in information and details (e.g., introduction, related work, study design, and even some expected results to report) is one of the earliest things you do in a project. I will then ask that you continue to write small portions throughout the project’s lifecycle until it becomes the main focus closer to the submission deadline. Writing earlier like this has a few positive impacts on the work. First, by writing an introduction and related work, we can decide if the project sounds strong enough to even be doing it (i.e., do we have a strong motivation, a clear gap of knowledge, a foundational research question that has not been answered, etc.). Second, it is a lot easier for us to discuss and critique ideas as well as to find gaps and concerns when they are written down. It has happened many times where I realize something is missing or needs changing because of the fact that I saw something on paper and read it aloud. Throughout, we will take a combination of a bottom-up (work up from the results) and top-down (work down from the master plan) approaches when writing.

I aim for a go/no-go decision roughly one month before a paper is due. This is typically the time that the large majority of the work should be complete (e.g., studies run, application deployment complete, literature review analyzed, a rough draft written, etc.). There may still be some small analysis of data to do, however, the greater focus at this point is on the writing and presentation of the work. Most, even still myself at times, are surprised at how long this part of a project takes. Explaining your ideas clearly in writing in fact takes a very long time. Furthermore, figures, tables, videos, and webpages all require a lot of work to showcase a high degree of quality and consideration.

If your project hasn’t met this target within a month from a deadline, that’s okay. Sprinting for an unlikely-to-be-reached deadline is not a good use of everybody’s time and energy, yours and mine, and will likely result in us being dissapointed anyways. I’m also not a fan of submitting unpolished and half-baked work or the idea of the least publishable unit. It wastes a reviewer’s time and doesn’t do great things for our reputation, while also being unlikely to be accepted to the venue anyways. We aim to publish one strong, high-impact paper at a reputable venue when the work is truly ready, rather than dispersing several less impactful or overlapping papers across lower-tier venues. Simply put, if a paper does not meet my standard of quality it does not go out. Importantly, as a co-author, you also have a say in whether we submit the work; your standards and concerns with a submission will always be respected, at which point we can further discuss until we come to an agreement.

A couple weeks prior to the deadline, after we go through multiple revisions on the writing and have a reasonably complete draft, we will share it with the broader lab for comments, questions, concerns, etc. Given that multiple students may be targetting the same deadline (e.g., September for CHI, November/February/May/August for IMWUT, July for PervasiveHealth, January for MHCI, December/March for GI), we will share in the responsibility of reviewing each others work. Having an increasingly complete draft at this stage will afford a more complete and directed set of comments that a rough draft does not afford.

I will provide a lot of help and guidance with your first project, including doing quite a bit of the actual writing as needed. This, however, isn’t to say that I will write the paper for you. Instead, you will typically do a handful of smaller passes (i.e., perhaps working on a subsection here and another subsection there) with discussions about each throughout. Then, I will do a larger written pass throughout and again we will discuss. This cycle repeats itself until eventually we are just looking for typos and silly mistakes, while also being increasinlgy critical about individual wording and sentence structure. Whether you are a native English speaker or not, I will typically do the final pass to do a last proofread and to ensure no silly mistakes snuck in.

As your graduate career continues, you will take on more and more of the paper writing work yourself. For Masters students who only do one paper, there won’t be much of a progression and that’s okay. Intead, thinking about the discussions we have and the comments I include can still positively impact your critical thinking and writing skills. However, many Masters students will be a part of multiple submitted works, even if they first submit a short paper and later a full paper. Thus, the ideal approach as we progress through multiple projects is that you write a draft, I read and critique, you rewrite, and we repeat. This then pushes you closer to being self-sufficient in your writing, a skill that is incredibly important in academia and in industry.

Research Logs and Archives

Beyond my own expectations, many reserach funders are requiring that we document and archive a variety of research deliverables. This includes not only the paper that is published, but also aspects such as code implementations and collected data.

As such, I expect you to use version control for any and all source code you write for your projects, largely using git for tooling alongside Guithub for repositories. This absolutely can not be occassional zip/tar files uploaded to the cloud. The lab has a Github account which I will add your personal account to, allowing you to contribute to any project you are working on. If you have not used version control before, I will provide some resources to get you started so that you can use the basics necessary.

For writing papers, we will use a website called Overleaf. Overleaf acts similar to Google Docs (we can write simultaneously, comment, see past versions), however, it allows us to write in LaTex which offers more flexibility and control. Furthermore, it is simply the standard in the HCI community when writing papers (if not the computer science community at large). If you have not used LaTex before, don’t worry it is easy to get started and I have a template version that has lots of helpful tips and tricks. I pay for the professional version of Overleaf, therefore I will create the initial project that you then join. This offers us the ability to include multiple collaborators/authors, version control, and other features.

For all other project material we will use the offered OneDrive space through the University of Winnipeg. I will setup a root project folder, with subfolders for different elements of the project (i.e., ethics, study method materials, study outcomes and data, supplemental material, data analysis scripts, paper versions, presentations, etc.). Throughout, we will collaborate on and archive files as needed. For example, I will have you archive PDF versions of the paper at a variety of milestones (i.e., initial submission, revision, camera-ready).