Prof. Kristin Stephens-Martinez

A shared inbox was a tool I started using when I was the hybrid chair of the SIGCSE Technical Symposium. It was extremely useful then, and I have since incorporated it into my teaching processes. So, this blog post covers why I use a shared inbox, considerations when using one, and two case studies of how those considerations played out. [ Also posted on medium. ] Why use a shared inbox? In short, efficiency! If more than one person in a group can respond to an email, the speed of response goes up while no one repeats work. I’ve lost count of how often I’ve seen multiple people get an email and respond simultaneously. Or I’ve been that person who started writing and thankfully didn’t send it before the other person hit send! But there are more efficiency gains than just that! There’s clarity on the context, on who is responsible, and in the email responses themselves. If the entire email thread is in the shared inbox, everyone has access to that context, and no one has to find an...

It is important to have documentation for people to reference as they learn how to work in a team. One document I use when I'm onboarding a student onto one of my codebases is my GitHub Rules and Expectations. The basic idea is to give them a clear idea of how to interact with everyone when it comes to the codebase and step-by-step instructions on what to do in certain situations. Below is the current version of my document. And yes, the "Rationale for Rules" is a section under the rules, so the students understand why I'm asking them to follow the rules. [Also posted on  medium .] Rules The main branch is only for final work and has a clean commit history Do not directly commit to the main branch Work In Progress (WIP) branches Use these for all initial work Tiny commits on these branches are perfectly acceptable It is fine to use a WIP for a pull request (PR) if its commit history is clean. These can and should be pushed to the repo to have backups of work. Clear co...