sustainability (maintainers)

[TimTaylor]

It would be good to get a discussion going on "maintainer" sustainability. To expand on what I mean. In particular it would be good to plan for:

• Funded individuals leaving
• Funding running out

In particular I'd like to ensure that no-one in the community ends up maintaining something out of a feeling of obligation as opposed to real desire to stay involved. There may also need to be different policies for released v unreleased (i.e. CRAN v non-CRAN) packages.

There is also the question on how this sustainability is conveyed to end users but I'm not sure of the best approach here.

[pratikunterwegs]

Thanks for raising this Tim, I wonder whether these details are something that should be discussed more in person.

Still, at the developer level these situations are essentially the same in that the maintainer(s) would leave, and my expectation would be that they would hand over maintenance as they do so - I expect either situation would give them enough to think about so as to leave little time for volunteering to maintain stuff.

I would suggest that any discussion we have should reflect that our packages are still in development, so any backup maintainer could very well also have to be the lead developer - see {cfr} as an example.

Given this, there's perhaps a case for ensuring that RSEs are more uniform in their competencies as they relate to our packages. One area of focus should probably be the Rcpp packages. I think the way we're using C++ at LSHTM isn't particularly complicated, but what @jd-otero is doing with {iraca} is more complex imo, so I would be interested in hearing about how they're dealing with this.

[jd-otero]

Currently we haven't had a big discussion about future leaves regarding the development team. I do agree with the idea that packages with a more complex structure (like Rcpp or RStan) might need some extra effort from mantainers, which will require more specific competences than other packages. This can be difficult for some individuals when becoming the lead developer of a package (as @pratikunterwegs said), but still possible for the members of the team (just with some extra effort) . That being said, my main concern would be more focused on funding running out rather than current leaves.

[pratikunterwegs]

Some thoughts initially put forward in epiverse-trace/blueprints#77, that touch upon sustainability:

• A core Epiverse value (the top one iirc) is inclusivity. What could we do, or what are we doing, to ensure that new and existing team members have the skills to be included in the development of all packages? E.g. improving epi, maths, or programming knowledge? @avallecam is running some courses in the coming weeks - is that something worth mentioning?
• Let's say we have a lottery-win event - how could we communicate temporarily reduced support for, or development on the affected packages? Would it help to use a status badge?
• More broadly, I noticed that there wasn't a concrete committment to project or software sustainability. Is it worth thinking of fallback maintenance options/rules, as e.g., Pharmaverse do?