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
IT suggestions for new faculty
This is the official web page for the James Fraser Lab at UCSF.fraserlab.com
David Zaslavsky
in reply to El Duvelle • • •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
in reply to El Duvelle • • •El Duvelle
in reply to JanGebauer • • •@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..
Ian Sudbery
in reply to El Duvelle • • •@JanGebauer
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.
El Duvelle
in reply to Ian Sudbery • • •@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.
@JanGebauer
Redish Lab
in reply to El Duvelle • • •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. :)
El Duvelle reshared this.
El Duvelle
in reply to Redish Lab • • •How can you make sure that your system remains up-to-date as time passes though? Yearly review to clean it up and try to improve the parts that can?
Redish Lab
in reply to El Duvelle • • •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.
Albert Cardona
in reply to Redish Lab • • •@adredish
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).
#academia