Long-term maintenance and handover

[kennethrioja]

What is the topic of the new content?

From the Research Software Quality Toolkit (RSQKit) Contentathon

I wanted to create a page about Project Management as it was identified as being the major skill RSE wanted to improve following the results from the 2026 International RSE survey. I prompted Gemini equipped with the standalone prompt and it gave me several ideas for 'project management for RSEs':

1. Planning & Scope Management

• "How do you define and manage requirements for your research software when scientific goals change?"
• "How do you estimate timelines and milestones for a software project in an academic research environment?"

2. Task Tracking & Collaboration

• "How do you track tasks and coordinate code contributions across a distributed research team?"
• "How do you run effective code and issue triaging sessions for your open-source research tool?"

3. Roles & Process Alignment

• "How do you establish clear development roles and onboarding processes for new contributors to your research codebase?"
• "How do you balance rapid prototyping with software quality standards in an agile research team?"

4. Sustainability & Lifecycle Management

• "How do you plan for the long-term maintenance and handover of your research software after funding ends?"
• "How do you manage technical debt in an active, multi-year research software project?"

I decided to go for the first point of 4 which resonates a lot with the experience I had in my previous lab!

Description of the new content

How to manage and plan for the long-term maintenance of research software and project before funding ends, and how to hand it over responsibly to a successor or into archival

Section within RSQKit for the new content

Tasks

[egpbos]

I was just thinking about this (while writing #698)! Good addition imho.

One thing in particular that I think is part of the RSE job is to also know when to compromise on the quality and software side and when to take the quick & dirty route because maybe there's a conference deadline coming up and you need results (maybe because you need something to show to secure follow-up funding). I suppose this can be seen as a practical example of your point 3.2 above, "How do you balance rapid prototyping with software quality standards in an agile research team?".