Ideas for helping with long-term maintenance

[cduvallet (Claire Duvallet)]

Hi!

In the process of updating my very old plugins to work with more recent versions of QIIME2 and after reading through What happened to Qurro and Songbird? - #4 by fedarko , I wanted to share some ideas that might make it easier for plugins to remain maintained after their creators have gone on to other careers:

1. QIIME 2-facilitated community of junior maintainers – I’m sure y’all have thought about this thoroughly, but just in case not: I feel like it’d be great to have a pool of folks interested in learning how to do software development that could help with some of the more rote tasks of updating dependencies, etc (and potentially one day take over managing some low-maintenance plugins?) I’m not sure this would ever work – I don’t know that the incentives would align, and also the sort of stuff they’d likely need to do (eg resolve dependency issues) are complex and painful, but maybe there’s a way? For example, as a grad student the incentives that got me to contribute to QIIME 2 were (1) the ability to say I did open source software on my resume and (2) a free trip to San Diego. But maybe I’m an outlier, and there aren’t enough other software-curious, sun-starved grad students out there to make this work And if this community already does exist, then it’d be great to have a way to reach out to them when issues inevitably arise with old plugins!
2. More documentation & support for those of us updating plugins – the developer documentation is currently very focused on folks developing plugins for the first time. I’d love some content for those of us who are dusting off the cobwebs trying to keep our plugins functional in as little time as possible. For example: big breaking changes you might need to know about in the past 5-10 years of QIIME 2 (y’all are getting old!! ), a brief reminder on how you might want to test that your package works with other QIIME2 dependencies, some links to the current standard package development best practices (I apparently published my plugins pre-pyproject.toml ), and most importantly: some simple artifacts to use for testing. I made some updates to my plugin but really can’t be bothered to go find an OTU table, remember how to convert it to a QIIME 2 artifact, etc etc (I’m sure I could find it in the standard documentation, but again: trying to do this work in as little time as possible )
   1. Ok edit literally after writing this post I realized I had some test data in my repos that I could use. So maybe a different way to make sure there is sample artifacts for future testing is to make sure that the developer documentation includes making test data for your plugin a highly encouraged part of the development process.

It’s also possible that all of these issues will be made irrelevant by the new plans for the library, in which case yay please ignore me!

[colinbrislawn (Colin J Brislawn)]

Hello Claire,

Thank you for sharing this. I’ve also found some sticking points when contributing to other people’s plugins, though I’m not sure if these are common or specific to my inexperience with Python.

Heng Li of bwa, minimap2, etc. had a good perspective on this:

On maintaining bioinformatics software

There’s lots of viable ways to do this, I suppose, and I like Qiime’s larger community.

[gregcaporaso]

Hey @cduvallet,

Thanks for your post! Some specific replies…

QIIME 2-facilitated community of junior maintainers

I love the idea of supporting junior developers, and would be more than happy for a junior developer community to find its hub on the Forum. I chatted with a few other folks here about this, and the consensus seems to be that maintenance is probably not the right area as it often requires expert-level knowledge. For example, if a dependency version changes (say scipy or vsearch) and downstream tests start failing (e.g., because the value 42 was expected but the value 43 was returned) does reveal a bug in code, an overly sensitive test, or was an underlying method improved (or not!)? This often requires deep dives into code, change logs, etc.

From my perspective, supporting this around new plugin development for people who are trying to get their microbiome (and other) data science methods out into the world might be the right fit - especially given that we now have the plugin development tutorial and content supporting new development. Thoughts on this? The incentives are the hard part to figure out including what are they, and how are they funded. I need to scratch my head over this a little, but for the more junior developers out there (and the people who pay their salaries, if applicable) - what incentives would get you involved? I know free travel is a motivator to some - what else?

More documentation & support for those of us updating plugins

This is a great idea, and something I can start putting some notes together on. I agree that this is a missing piece right now. I think a single document on this might not stand the test of time, but with the rewrite of the QIIME 2 Library, changes in Python package structure (e.g., using pyproject.toml), and the addition of the Copier template this is a good time to consolidate information on how to update old plugins. If you end up compiling any notes as you update your plugins, I’d love to see them if you don’t mind!

y’all are getting old!!

Hey, hey, hey! I prefer wise.

… can’t be bothered to go find an OTU table…

Don’t forget that lots of relevant artifacts are linked from the documentation too. For example, the gut to soil microbiome axis → tutorial has lots of fresh artifacts in it!

Thanks again for your input - it’s always welcome!