CW21 - 2021-03-30

Bagpuss - CI2-CW21

Participants

  • Sorrel Harriet (Chair)
  • Teri Forey (Scribe)
  • Diego Alonso Álvarez
  • Heather Turner
  • Alexander Konovalov
  • Ilian Todorov

Ideas:

  • _Tool or mechanism to add comments to code, or annotating the code with feedback without creating a pull request. Better space to provide guidance. _
    • _Nothing wrong with paired programming or code review, but it’s synchronous (have to find time that’s convenient to everyone). If it’s in a document there’s no easy way to link it to the line of code. Almost need a google docs for code. _
    • Limitation with PR is you’re not reviewing the whole code. And you’re not wanting to change the code.
    • Need something more simply than the code review packages and tools that are out there - more like editing a paper and providing a comment.
    • https://github.com/ropensci/software-review/issues/24 - still need to copy the code chunk.
    • _Output could be a review of existing tools. _
    • Can click on ‘plus’ in github to create an issue with a preview of that line of code, doesn’t work with a chunk. It’s a workaround not a solution. Could end up with loads of issues which isn’t great
    • Collaborative calculation in the cloud - Version of jupyter notebooks which is almost like google docs where multiple users can work together. Not sure if you can have comments though - but people can add markdown cells. CoCalc.com
    • _Could suggest a feature to an existing tool. _
  • _How do we fund software maintenance? _
    • _Almost want a kickstarter or gofundme for software, instead of something epic per funder. _
    • _Alternative model to finding software! Contribute to your open source. _
    • _Open source tool funded by kick starter - _
    • _Github sponsors and javascript asks for donations. _
    • _How do you then channel that small funding stream into an project? Is it time? One day for an RSE? Needs to be planned in. _
    • Improvements and maintenance funding options do exist
    • _What about a shared pot that projects can apply? Would need a plan - but keep it lo-key. _
    • _Some funding could go to central RSE folk, keep the software the department is creating can be maintained. Subscription to the central RSE team to keep the software maintained. Provide it as an actual service. _
    • What happens when the PI (or whole lab) leaves academia? Should it continue to get maintained? Where are the benefits to the university?
  • Technical debt on projects. How do you keep track/monitor? Keep a record? Give an idea to the current health of a project?
    • Some tools can provide a guidance - like codecov
    • Where decisions have been made but aren’t documented or compromise some part of the project - workarounds and easy choices that weren’t necessarily the best.
    • https://ropensci.org/r-universe/
    • Activity on the github repo. How do you trust a project? Are the developers established?
    • _It’s easy to make mistakes and hard to review everything. Snapshot of whether there’s potentially a problem. _
    • _If software grows organic it’s hard to keep track of what decisions where made and by who. _
    • _Needs to be no judgement - understanding that not all developers are working at the same level. _
    • _Technical debt can also come from a reasonable decision at the time, but then goes out of date (like versioning). _
    • Self evaluation of your tool, without fear of repercussions. Health check list. Make it open and visible.
  • _How can we improve carpentries and training to include sustainability? _

_Could be an imaginative idea, or based on a real problem. Could be an idea what doesn’t go in hack day. _

_ _

The Research Software Sustainability Concordat

Context / Research Domain

Research Software Maintenance Funding. Covers all domains of research.

Problem

How to encourage and ensure software maintenance gets sufficiently funded.

_Creating software is good, but not enough: unlike research publications, which do not require maintenance, the software, to remain useful, needs to be maintained, and that requires funds. _

_Inspired by various Concordats, e.g. The Concordat to Support the Career Development of Researchers (https://www.vitae.ac.uk/policy/concordat), The concordat for research integrity (https://www.universitiesuk.ac.uk/policy-and-analysis/reports/Pages/the-concordat-for-research-integrity.aspx), we would like to introduce the idea of the Research Software Sustainability Concordat. _

Solution

_The solution is to generate models for funding research software maintenance, then to write a white paper that is shared with funders and universities. There would be a commitment or pledge that they would sign to agree that they’d follow these principles: the Research Software Sustainability Concordat. _

Possible models include:

  • Have a public source of funding (similar to gofundme etc.) that institutions and funders could donate to and the money would be then made available to projects on application.
    • _Any sized project could apply, from small single-maintainer projects through to language core-developers (e.g. Python Software Foundation). _
    • _Application form would be very lightweight and community reviewed. _
  • Change the funding application form to include a section on what open-source tools will be used, and what proportion of the funding requested will be going to their maintenance (1-5% for example would go to python foundation, numpy, matplotlib). This source of funding could go straight into the plan above (instead of directly to the specific projects). In other words, this introduces a notion of Software Overheads.
  • _Central RSE groups generate a subscription plan where projects can set aside some funding for continued maintenance, or where core funding can be set aside to support the maintenance of any software project applying to it. _
  • Generate awareness of the software and engage with or create a community of practitioners that can provide effort, funding or contribute to proposals to ensure the sustainability, maintenance and further development of the project. This should take into account that different projects would have different critical mass of a community, as well as different stages of the software project lyfecycle, from active development to reaching the end of shelf life.

Diagrams / Illustrations

Funding lines.

Licence

These materials (unless otherwise specified) are available under the Creative Commons Attribution 4.0 Licence. Please see the human-readable summary of the CC BY 4.0 and the full legal text for further information.