jonathan@researchcomputingteams.org
Hi, everyone!
Mainly taking the week off from the newsletter this week (for positive reasons - some family celebrations); things will return to normal next week. But there were some things I wanted to share with you.
First, on the discussion from last week of planning for hybrid distributed/local work, we heard from long-time reader Adam DeConinck about what he’s learned:
I’m fortunate at the moment, because my current team was fully remote before the pandemic started. That said, here are a few thoughts based on some of my recent experience.
Several of my past roles have already been “hybrid”, where either some employees were remote vs some not; or where employees were split across many offices in multiple time zones, which often led to similar communication challenges.
The general philosophy that has seemed to work has been to split “location” by team. I.e., everyone on a team should either be remote, or should be co-located in the same office. This basically works to allow each team to find their rhythm.
In the cases where teams have been split across different work “locations”, I’ve mostly seen the effective formation of “sub-teams”. E.g., while the [city X] and [city Y] offices may in theory both have members on the same team, they tend to split responsibilities to minimize overlap. Or, if there’s a core group in the office but a few remote folks, the remote team members form their own “team” where they mostly collaborate with each other.
Based on this experience, I suspect organizations which are large enough to have a lot of teams will go through substantial re-orgs over the next year!
Granted, this is a lot harder for orgs where there are fewer teams, or where they’re smaller or harder to split. In those cases, unless everyone can make it back into the office, I think the only thing that works is to go the “remote first” model: everyone works as if they were remote, joining video calls individually and putting most communication in text. And then in-office interaction is purely social.
This is really valuable; thanks, Adam!
On the other hand, I also heard from readers whose institutions are decidedly not moving to hybrid or remote work but instead expect everyone back as soon as possible. In a way that’s a lot easier, but it certainly ties a hiring managers hands behind their backs in recruiting new hires, or retaining those who have come to like not having to commute every day.
If your team manages systems, you’ve probably heard about the really pretty bad privilege-escalating polkit vulnerability that affects RHEL8, Fedora 21+, Debian testing, and Ubuntu 20.04 If you haven’t, you’ll want to update (a fix was released last week). The post is a really detailed overview of the bug and the proof of concept exploit.
Titus Brown generously shared the core of a Chan Zuckerberg Initiative (CZI) Essential Open Source Software for Science grant application in a blog post which you can read here; the proposal aims to make their package sourmash more of a community code by moving towards more community engagement.
The post is interesting both if you’re interested in CZI grants but also to see how a PI quite experienced in research software development thinks about building community engagement.
As a side note I’d love to see more research computing and data grant proposals being made public!
There’s a call for papers due on Monday, 14 June, for a workshop on Resilience in HPC Clusters, Clouds, and Grids; the workshop is held in conjunction with Euro-Par 2021, to be held on-site in Lisbon.
And that’s it for this mini-roundup. Please keep feedback coming in, and welcome to all new readers.
Have a great weekend, and good luck in the coming week with your research computing team!
Jonathan
