As the PI of the Carpenter lab (a.k.a. Broad Institute Imaging Platform, including the CellProfiler team), people often ask how I manage so many ongoing collaborations: we discuss 50+ external projects each year so it is a lot to track! I am happy to reveal our secrets.
First, let me describe the problem we are trying to solve: we need a way/place to post project updates, raw data, and emails about a given project, so everyone in the lab can have access to info (most commonly, the project lead in my group and myself, but also future lab members who may join a project later). When someone emails me out of the blue, I want to be able to check on the project and get a sense of the project status. Or if someone asks if we’d successfully done X with Y cells, I can search for keywords to see if any active projects are in a given area. Or if someone asks a question about our published paper and the relevant team members have moved on from the lab, I can dig through old emails with details.
Option 1: Copy everyone on all emails
This is an okay solution but fails when someone new joins the lab and takes over a project; there is no way for the prior project lead to find and forward all emails about the project conveniently. It is not a very orderly solution as it is not easy to skim all emails pertaining to a particular project (though this could be mitigated by using Gmail tags; see Option 3). But it also causes WAY too much traffic; we want the 30 emails about metadata and plate layouts to be stored somewhere for reference, but I personally don’t need to see every email as it flies by.
Option 2: Wiki project pages
For the first 10 years of my lab, we set up a wiki, readable only within the group, and had a wiki page for each project. This worked pretty well especially in cases where project leads used it as essentially a lab notebook.
Pros of project wiki pages: you can includes all kinds of files and data and emails, and arrange the material as you like so it’s human readable. For example we put consistent sections at the top such as: Collaborator contact info, example images, current status, location of Github repo, location of images on AWS, and so on.
Cons of project wiki pages: it’s not trivial to post emails to a wiki page. We wrote scripts so that emails forwarded to a certain Gmail address would get processed and converted to proper wiki formatting, and we used Gmail tags (see Option 3) to clue our administrator in to which project page it should go on, but it was still a manual process to post the email to the page. Plus, when pasting an email to its proper wiki project page, you need to assess which parts of the email chain/thread are already posted. Or you get lazy and post the whole thread – over the years we realized that most pages were ending up a dump of email threads that were not very nicely searchable. We are not taking advantage (much) of the wiki as a lab notebook. It was time for a change, leading us to Option 3!
Option 3: CC a shared Gmail account with tagging
We came up with a way to organize information in Gmail so that the whole lab can read past email threads, even if they join the lab ten years later.
We made a new Gmail account (like, OurProjects@broadinstitute.org). Note that broadinstitute.org is a Gmail-powered account.
We keep a Google spreadsheet listing an official tag for every project:
|projectname1||Joe Collaborator||Institute of X||Neuron tracing|
|projectname2||Jane Collaborator||University of Y||Adipocytes|
OurProjectsfirstname.lastname@example.orgSo now, whenever anyone in the lab writes or replies to an email on a project, they use their own email address to do so. But they also copy the shared email address using those tags, like this (the plus is a literal plus sign interjected into the address):
and so on.
Adding “+text” in there does not affect the destination of the email; it still goes to the OurProjects@broadinstitute.org account. It just allows searching later!
All lab members are set up as delegates for the OurProjects@broadinstitute.org account and thus can view and search all that account’s emails when logged into their own account! You just enter the project tag as a search term “+projectname1” and find all past emails about the project.
As a bonus, in Gmail each person working on a given project can assign a name like so:
so that if you start typing ProjectName1 it will autocomplete to the right project.
Pros of a shared Gmail account with project tags: everyone in the lab, current and future, has access to all details of a project. It is very minimal effort to maintain the system: just decide on a project tag at the beginning, then copy that email address on all correspondence (and forward email or other notes if someone forgets to copy the right address): done! You don’t need to pay any attention to the shared account at all except for when you want to search something someone else might’ve sent to the address. Gmail is the best at handling threading and not showing redundant parts of emails so skimming emails for content works great. Gmail has excellent search functionality.
Cons of a shared Gmail account with project tags: Each project is now represented only in email format, so if we want some standard info (as above, Collaborator contact info, example images, etc.), we need to force ourselves to remember to send an email with that info and an appropriate subject line, preferably at the beginning of a project. Another downside is that anyone can delete emails, affecting the whole group, but this risk can be minimized by setting up auto-forwarding to a separate email account where only the PI has access, for example.
For electronic lab notebook purposes (tracking data analyses we run, including hypotheses and results), we now use Confluence; but this Gmail system works great for capturing and sharing email-based traffic about projects.
The credit for our current system goes to Shantanu Singh and Jeanelle Ackerman. Thanks to its efficiency we can focus on science!