Here are some very interesting suggestions for having a good IT system in your lab (Github, Wiki, website, emails etc.). I’m sure the Mastodon crowd will love these:
https://fraserlab.com/2024/04/22/IT-suggestions-for-new-faculty/
Source: future PI slack, from the #FraserLab
@elduvelle ugh AWS
I have to admit they have a point about it being a big company that isn't going to disappear, but it hardly seems like the only choice
I was more surprised by the recommendation to put everything in your own personal account rather than using university resources
@JanGebauer for the private emails, I think it makes sense: even if the PI stays there forever, most other lab members unfortunately come and go and most universities unfortunately close your email access when or a short time after you’ve left. It’s nice to have some email continuity…
I agree GDPR might make things more difficult..
Pretty sure my contract states that all university business must be conducted through university email accounts. And research, and particularly grabt funded research (where the university is the contracting party, not the PI) and management of research staff (where the university is the legal employer) definitely counts are university business.
@IanSudbery probably… and this is probably country-dependent. The link is for a US lab where the PI seems to be considered more of an independent “entrepreneur” than, for example, in Europe.
These are good ideas.
Just a warning, though. When you build your lab, you will have a great IT system. It will be elegantly designed, and will be light-years ahead of your PI's structure. And you will wonder how they ever got along without it... until 25 years later, you realize your IT system is now a hodgepodge of duct tape and out-of-date systems that are not nearly as good as the new faculty are designing, and you will realize that updating it would require taking the entire system offline for more than a year and none of your postdocs would accept the new structure...
Of course, that doesn't mean you shouldn't do your best to set things up as carefully as you can when you start. Just a view from down the road. :)
TBH, I don't know. I think yearly review would be a good technique to try.
What I have done is added things over the years. It's not so hard when it's an entirely new thing. For example, we added a Wiki about a decade ago. That worked really well. I recently added checks to the lab database so that new stuff at least is in a consistent format... for a while. In my experience, the problem is less one of adding as much as deciding when to retire something or deciding whether it is worth fixing legacy structures.
A major issue is when to let go of data taking hundreds of terabytes of space, and no one in the lab remembers what exactly it is, and the associated metadata and documentation (a wiki page) was lost some time ago or no longer makes sense. One never has time to go through these.
I do not have a good solution. The solution I'd want is an annual review of data, tied with the 5-year cycle of data servers (that's how long they're expected to last).
@adredish @elduvelle Please stop talking about my lab infrastructure in public! 🤣
One messy part for me has been: We moved to having all new projects on github. But we still had the old subversion server and repos sitting on a machine we maintained, and a few TB of data sitting around on local servers. Someone would need to triage all of that ... which means a lot of it is still in a now-ignored subversion server. sigh.
Also .. (1/2)
Also, just a reminder that your university email account is owned by your university, so you should have a personal email account for your personal life and try your best to keep the two emails separate.
Also, I've had to update backup solutions every five years or so. Do not assume that the backup solutions will remain stable. That is something you will need to assess at regular intervals. But make sure you do have a process that is backing your data, code, and other lab components (notes, meta-data, procedures, papers in process, etc) regularly.
El Duvelle
David Zaslavsky
JanGebauer
Ian Sudbery
Redish Lab
Albert Cardona
Eli Roberson (he/him)
David Andersen