Photo by Martin Bargl on Unsplash

By Daniel Hobley (editor), Alison Clarke, Philip Grylls, Mateusz Kuzak, Louise Brown and Alessandro Felder

This post is part of the CW20 speed blog posts series.

Research software communities (RSC) consist of like-minded people with the goal to share and evangelise best-practice in research software. Growing by word of mouth with a core group of committed individuals organising events, they have quickly gained momentum amongst researchers who work frequently with software. Growing beyond those people who self-identify and join the group is the primary hurdle for many RSCs. It is therefore crucial for RSCs to strategise how to advertise to the broader research community, many of whom use software or code daily but do not identify as someone who needs to be within a Research Software Engineering (RSE) community.

We identify this drive as stemming from two aspects. Firstly ‘the carrot’, advertising the benefits to research that can be gained from learning more about software from activities run by RSCs such as code surgeries, software carpentry workshops, community lunches, pizza4python, etc. Secondly, ‘the stick’, using the momentum developed by RSCs to build checks on best practice implemented at a policy level similar to that found in data management plans. 

This speed blog presents a possible way of thinking about engagement with those who use code in their day-to-day research, but are not “plugged into” these RSCs. We see there being three concentric rings blocking these researchers from engagement. First, they must know that these communities exist. Second, once they know this, they must be motivated to engage with the communities. Third, even once a prospective learner knows about and is motivated to engage with a community, there are still a number of obstacles. This speed blog reviews these ideas.

Getting the word out

Photo by Aaron Burden on Unsplash

Large numbers of scientists who use code for their research are not aware of the existence of modern best practice that the SSI advocates. Partly, this may be because they are self-taught, or because they are trained by someone who was themselves self taught - this was certainly the case for several of our group. Finding ways to let these people know that these kinds of tools and techniques exist is the first step to reaching out to them to make them aware of the pools of expertise in their universities (e.g. RSEs, drop-ins, discussion groups).

One suggestion for getting the word out is to host meetups or lunches for people engaged in research software. However, some people may find it daunting to attend such meetings, as they feel they don’t have the expertise to join in the conversation. Perhaps we could stratify such meetups, for example having one meetup for HPC, another for social scientists, yet another for researchers from arts and humanities.

Another outreach tool that has been tried by some institutions is to host drop-in sessions, where researchers can come along with a problem and be helped, or pointed towards the place to go to find out more. Members of our discussion group have sometimes found it difficult to advertise such sessions, though, as they need to reach a wide audience across an institution. Word-of-mouth can be helpful, but is likely to miss many people who could benefit from the sessions.

Perhaps a better solution would be to go into individual departments within an institution to talk about communities of practice: this could be by attending departmental seminars or meetings. However, it can be very time consuming to go round every single department of an institution. If it were possible to identify key people within each department who are engaged with the research software community, that may be a more effective way of reaching out to the rest of the department. Bringing together these key people could also help identify the Research Software Engineers (whether so designated by job title or chance!) within each department, and linking them more tightly to the broader local RSE community if they are not already aware of it.

Beyond outreach in individual universities, the UK research councils could provide a good means of reaching researchers with these kinds of information. Requirements to provide descriptions of sustainability as a matter of course on proposals will serve both to motivate and inform on these issues.      

Ultimately, building an understanding of the basics of best practice at a very low level is probably required to have long term effects. This may involve reaching out to teachers of programming at the undergraduate level and persuading them to emphasise the sustainability side of programming (GitHub, version control, basic testing, etc) at students’ first engagement with code.

Motivating engagement

Once researchers are aware of research software sustainability and good software practice, it is key that they are motivated to become and then stay engaged. There are various options for achieving this.

Above, we mentioned that drop-ins and other lunches, seminars, carpentries etc. can help advertise the existence of best practice in universities. However, this doesn’t mean that the target audiences will be motivated to go to them. It is important to pitch these at the right level. Engagement can be enhanced by tailoring the training course to a specific discipline, e.g. “Python for Geosciences”, and by adapting the wording to what people already know - for example, more people will probably have heard of “GitHub” than those that have heard of “version control”, and “access your code from anywhere without edit conflicts” might be more appealing than either. This may increase engagement with typically less “techie” disciplines like social sciences or arts and humanities.

Researchers who have already learned and used the tools that help with making research software more sustainable and reproducible can be good mediators between the “software people” and researchers who are software novices - they are approachable and less prone to domain-related blind spots. Seeing examples of how the tools have helped a real-world project can help people to realise the potential of the tools. Persuading researchers to share their experience can be an issue, though. 

There can also be an issue when researchers are keen to adopt practices such as version control but supervisors or principal investigators (PIs) don’t see the benefit of adopting such practices. It is therefore important to engage with researchers at all levels. As it becomes more common for software management plans to be a part of research proposals, PIs may have more incentive to engage.

Highlighting the advantages to their research will help to keep researchers engaged and provide motivation to engage with good practice. For example, using GitHub to store their code enables researchers to create a tag and Zenodo DOI to reference the software used in a specific paper. Seeing this as something that will make their research more visible and able to be cited may provide incentive to adopt these methods, making the science more reproducible and increasing its impact.

Further obstacles for learners and teachers

Even once researchers know about and are motivated to pursue good practice, there are still obstacles in the way of wider uptake.

Some of the target audience is likely to find engagement with RSEs or other knowledgeable techie types daunting. This may be an even worse problem for more senior and thus influential prospective learners, e.g., PIs, due to a greater investment in less-than-perfect practice in their past research. Clearly, a judgement-free attitude and focus on future goals will help here. However, as noted previously, a subject- or department-specific approach led by or partnered with local colleagues may also reduce the intimidation factor.

Both learners and teachers have limited time available to them. For researchers, going to a workshop and learning new skills often will compete with doing research, spending time in the lab or doing data analysis. It may be especially challenging if the PI does not appreciate the importance of good quality research software developed according to good practices. That can be overcome by raising the PI’s awareness, which could be achieved through promoting the open science and reproducible research principles at the faculty - as well as by advocating for requirements at UKRI level.

It is easier for young researchers to commit their precious time if they can get course credit (e.g. ECTS points) for either attending or teaching at the workshop. Another way to approach this is to make training a part of the research projects. This will lead to the allocation of time and money for training in advance. It could also include money for the local Research Software Engineer group to organise training and help with mentoring around good practices for research software. 

Such an approach could be especially successful when the funders and consortia would expect inclusion of a training budget in the projects be a common and desirable practice. Some organisations and funders have been slowly introducing Software Management Plans, similar to Data Management Plans. That way applying good development practices is not an afterthought anymore and time and money for training are allocated beforehand.

Finally, the demands created by running training and community events present a real challenge to the people at the heart of RSCs who may have limited time and money to put on events that are highly demanded and encouraged by universities. Further high level support for such key personnel is key to growing our communities.