Defining a career path is what helps us identify and advertise the experience we have gained in a way that is understandable and comparable to those inside and outside of our community. It is a structure upon which many other aspects of our job and life can depend, including access to new roles, pay scales and ambitions. Without it, we can find ourselves in a position of uncertainty with no way of defining progress. 

Despite this clear importance, the idea of a career path for Digital Research Infrastructure(DRI) professionals is murky and undefined. Since the inception of the RSE Society, the picture is looking clearer for RSEs but there is still a long way to go. With new job roles and team sizes being formed, such as AI ops and data oriented roles, the opportunities for new career paths are opening up.

In this blog post, we will explore all the constraints and complexities involved in defining DRI career paths.

Multiple Possible Roles and Expertise

RSE careers and job roles vary in many ways. We range from researchers who code to full time software engineers. We can embed RSEs within a research group or RSEs in central teams often as part of IT services. All these different RSE jobs are valuable and need to be considered when discussing RSE career paths. 

There are also challenges for career progression as you climb the ladder. Often the only way to progress from a senior level RSE is to go into management, which is not what everybody wants to do. Progression into technical leadership roles exists, but opportunities are limited. There are also other leadership roles that need to be recognised such as community leadership that are valuable to the profession as a whole.

Multiple Stakeholders to convince of our career path

Unlike software career paths outside of academia, we have multiple stakeholders to convince of the validity of our career path as a whole and how far along that path we are. In addition to our employer institution, we also need to convince the funding bodies and communities that are springing up around the theme of RSE. This can be a difficult challenge when each has its own ideology, rates of change and economic scale. Many RSEs' time is covered both by project and central university funding.

Institutions and funders have historically defined RSEs under professional services contracts with very little progression or variety in job titles and descriptions. The grade is often tied to a project with no flexibility for the duration of the project. When projects span multiple years this can be a barrier to the progression of RSEs on the project.

The RSE society is one of the biggest RSE communities and was built around the definition of RSE as a role. Other communities exist including domain or geographic region specific. Any sustainable career path will need to be aligned with these communities to ensure consistency across regions and research domains.

No standard skill requirements

The role of an RSE can span many different technologies and applications. With this comes a very broad skill set requirement that is often unique to the project or team. Creating a baseline set of skills for each role and career stage can improve consistency across the community but also risks degrading the diversity of skills that are covered.

Larger RSE teams have more scope in this area to enable more specific role expertise requirements similar to a commercial sector team. 

Multiple Entry Points

People might become RSEs from a variety of other roles and levels of experience: graduate student, postdoc, internship or from industry.

The early career entry point appears to be less common, our group perceived that it is common for RSEs to start their careers after some time in research. 

There are a couple of initiatives that aim to expose students and early career researchers (ECRs) to the option of an RSE career and provide an early entry point. The Imperial College Research Computing Service is running an HPC and RSE Experience Programme. It is effectively an internship ​​that provides a short term contract for ECRs wanting to dip their toes in the world of HPC and RSE. The N8CIR is also running its first summer internship scheme this year (2024) which aims to bring RSE skills to those new to research in three academic themes (Digital Health, Digital Humanities and Machine Learning). It is driven by the academic theme leads at each institution who will help identify the projects and candidates that are most appropriate. It is also supported by the RSE leads at each institution who will assist in the use of local and regional HPC.

Maintaining the diversity of the role

One of the attractive aspects of the RSE role is the diversity of work involved. How do we maintain this if we create more restrictive job roles and descriptions?

Fluidity of career path can be beneficial (see portfolio careers), and may lead to you taking up other software infrastructure roles that suit your interests, or that you may already be doing as an RSE. Progression is not limited in the same way as with some chartered professions.

On the other hand, with a well defined professional progression path it could be easier to build a justification for promotion, boost recognition and compensation for RSEs with our respective employers.

Conclusion - a way forward

To tackle these difficulties in defining a career path we need to establish flexible role definitions and make these widely available to the community. We need to help RSEs track and manage their career development in a way that can easily be communicated to different stakeholders such as institution management and funding bodies.

Some key actions for moving forward…

• Promote a more diverse entry point to the RSE career path through internships and apprenticeships.
• Work with institutions and funders to make contracts and funding more flexible for RSEs.
• Continue to promote community projects such as the RSE Competencies toolkit that aim to help define key skills and levels of experience.

Original image by djoanis from pixabay.

Over the last decade, there’s been a consistent effort to lower barriers to the accessibility of research software. This has included translating educational resources from English to several languages (The Carpentries, since 2017), offering training in other languages (e.g. Software Carpentry in Ukrainian) and collaboration opportunities between the UK & other countries (The Turing Way, OLS, The Carpentries). These great initiatives have been aimed at diversifying access and working towards democratising knowledge.  

However, there are still cultural and technical gaps which should be understood and considered when supporting international community-building. While established software communities are centred predominantly in English-speaking countries, more communities are emerging around the world (e.g. Latin-R, RSE Asia). 

In the following sections, we’ll discuss some of the technical and cultural gaps, introduce successful case studies and look at how, by starting a conversation to address them, we can benefit from the richer and more diverse perspectives that multilingual and international communities can foster.  

Barriers to multi-lingual and international openness 

Access to infrastructure such as electricity, computers, internet, and cloud computing is needed to drive research and software development. In some parts of the world, these resources can be difficult to access, creating barriers preventing people in those areas from contributing to software communities. 

Historically, educational materials have been created in English and later translated into different languages. While many non-native speakers tend to learn English as part of their primary education, not everyone does. If this education is available, it is typically for everyday purposes, rather than research or software-related purposes. This limits the utility of English-language educational materials for potential contributors to research and research software, including the ability to understand legal usage terms in e.g. a software licence, or jargon used in a pull request review.

Translation and localisation (adapting the material to local customs) are key to enabling multilingual communication. Tips for working with translation technology for open education resources have been published in another blog on the SSI website. Here, we emphasise the need for good documentation and guides to crowd-source contributions, such as e.g. the contributor guide to the Glosario project, available in English and Spanish, or this guide to translating carpentries into Ukrainian.

Open practices were developed in the Global North. It must, therefore, be acknowledged that they are not currently designed to allow diverse perspectives and contributions from an international point of view.

It is important to note that this language barrier is not unidirectional: people do, of course, conduct research in languages other than English. In these cases, language becomes a barrier not only to accessing English-language resources and research but also to researchers’ ability to contribute and exchange knowledge outside of their native language (and this also limits recognition of their contributions).

Case studies addressing these barriers

Bioinformatics Hub of Kenya Initiative

The Bioinformatics Hub of Kenya Initiative (BHKI) is a community of researchers and educators interested in the study of computational biology. BHKI was founded in 2019 and is a self-organised group based across Kenya that shares knowledge in different bioinformatics skills within Kenya and surrounding regions. Bioinformatics researchers constitute a big group of the RSE community in this region. Through partnerships and links with organisations like OLS and the Carpentries, they are able to introduce RSE and open science concepts and distribute resources that aid in reducing the knowledge barrier. The BHKI community is an example of the successful establishment of localised communities to address international barriers.

Catalyst Project

The Catalyst Project is a Chan-Zuckerberg Initiative funded project aimed at developing collaborative cloud infrastructure services for the biosciences in Latin America and Africa, which are historically under-served by large-scale cyberinfrastructure projects.

The project has provided reliable and sustainable research infrastructure for BHKI, amongst other communities, in the form of JupyterHubs in the cloud, managed by 2i2c, who is one of seven core team members of the Catalyst Project. The digital hub serves as an accessible space for community members from across the world to create and share computational knowledge and best practices without the need for complex local installations and hardware. For example, researchers and educators can teach students on a shared platform that offers a reproducible software environment, or researchers can collaborate on work around large datasets in the cloud that are common to biosciences research.

Hub administrators are trained by 2i2c on how to make the best use of their digital hub and benefit from mentoring by the Open Life Sciences on Open Science leadership and Train the Trainer workshops provided by The Carpentries. This skills training is designed to permeate and disseminate foundational skills to the wider community so that they can independently manage their digital infrastructure within a collaborative open science framework.

Building bridges across the world

Drawing on the above experiences in international community building, we found it is important to consider these general points.

• It is important to be aware of the power balance and historical context in the interactions between Western, more wealthy institutions and international and multilingual communities, especially when trying to promote top-down ideas.
• A focus on research infrastructure can empower localised communities. While individuals and organisations active in the space of community building should be aware of ideological and practical restraints, a focus on resources over practices means that there is flexibility for local communities to come up with their own best practices and contribute novel ideas.
• These novel ideas can then benefit other communities if there is space for them to connect and share experiences and knowledge “horizontally”. It is therefore also essential that conversations between localised communities are promoted, ensuring the facilitation of horizontal and bottom-up approaches.  

Conclusion

As a global research software community, we need to recognise that knowledge doesn’t just exist (and is not only generated) in English and that by helping build international and multilingual communities we democratise knowledge, lower barriers and capitalise on diversity. This could happen by empowering and providing support for international community builders, sharing experiences in community building, funding translation and localisation infrastructure and the people maintaining it, and ensuring international research software communities are connected in both directions, equitably.

This blog by Mike Simpson in Newcastle University Research Software Engineering on Medium.

Can task management tools, often used by our corporate overlords to exploit us, actually help us improve our mental health?

That was the question that a team of us set about trying to answer at this year’s SSI Collaborations Workshop.

Developing software for research can be challenging. Many of us work on multiple projects simultaneously, often to tight deadlines, with world leaders in fields we know nothing about, on projects that mutate and change over time. On top of that, we have to do training, keep up with constantly evolving technologies and take on extra responsibilities to advance our careers. It will come as no surprise to most Research Software Engineers that anxiety, burnout and impostor syndrome are common in this industry.

But what can we practically do as RSEs to protect our mental health at work? We have very little control over our workloads or our salaries. And telling a burned-out engineer to do some yoga or mindfulness exercises is seldom well-received (and for good reason)! As someone who has dealt with a range of mental health issues over the last decade or so, this question is very close to my heart.

My colleague, Dave Horsfall, was granted a Fellowship by the Software Sustainability Institute (SSI) to conduct a survey into mental health in our community. I’ve been helping analyse the results, and I hope to apply for a fellowship myself to continue the conversation and help provide information, tools and support to RSEs and their colleagues.

Collaborations Workshop 2024

Which brings us to May 2024 and Day 2 of the SSI’s 14th Collaborations Workshop. We were split into groups and asked to come up with potential ideas for the Hack Day on Day 3.

We introduced ourselves and discussed our various backgrounds and interests. I mentioned my plans to apply for the fellowship, and a number of people in the group admitted to having experienced mental health issues, including neurodivergence, ADHD and anxiety. A fascinating conversation followed, including several colleagues discussing how they use so-called ‘productivity frameworks’ to help manage their workload.

Many of us were wary of such concepts, as managers often employ them to try and squeeze more work out of their (already over-worked) employees. However, our colleagues explained that using these techniques allowed them not only to be more productive but to feel more productive. They adapted these tools not to do more work for their boss but to help manage their anxiety, so they could go home at the end of the day without the nagging little voices in the back of their head telling them they hadn’t done enough.

Task Management for Humans as Self-Care

We felt that these tools could be used to help people (and RSEs in particular) work more effectively - as tools for self-care and managing their life-work balance. And so, we came up with “Task Management for Humans as Self-Care”. The idea was to create a Carpentries-style course that would introduce various tools, apps and frameworks that people could use to manage their workload. But the emphasis was on using them for your own benefit rather than your boss’s. Additionally, the idea was not that “you should adopt everything from [Framework A] or you’re doing it wrong!” The idea was to encourage people to look at the ideas suggested by each solution and adopt the ones that work for them.

We pitched the idea at the end of Day 2 and then, at the Hack Day, we started putting the course together. We were very fortunate to have qualified instructors and people who had contributed to Carpentries lessons before on our team, which allowed us to hit the ground running. While the experts set up the repository, some of us worked on writing introductory content and suggesting how the course could be structured. Others researched productivity frameworks or wrote about task management tools they had used in the past.

The course is available on the Carpentries Incubator.

It’s still very much a work in progress, but what is there should give a clear indication of what we had in mind, and we hope to continue to develop it over the coming months. We focussed on the introduction and an overview of the course, and made sure that the message about it being a tool for RSEs to use for the sake of their own life/work balance and mental health was front-and-centre.

We worked away quietly once the tasks had been handed out and were so focused on our work that the judges struggled to attract our attention when they Zoomed in to check on our progress! We were then amazed and delighted when we went on to win the top prize for the ideas session and then the top prize for the Hack Day, too.

Final Thoughts

I don’t think there is a ‘magic bullet’; no single solution that can improve the mental health of everyone in the community. But projects like this - that help a subset of the community with specific problems - can make a big difference.

I also think that the fact that this project got so much attention (and won two prizes!) shows that people realise how important mental health is and that people are willing to support projects that aim to improve mental health in our community. After all, making research software more sustainable goes beyond improving our code; we have to help sustain the people writing the code, too!

Thanks to the ‘Task Management for Humans’ Team: Aman Goel, Hugo Gruson, Jez Cope, Matthew Gasgoyne, Nicky Nicolson, Olexandr Konovalov, Selina Aragon, Kirstie Whitaker, Sarah Gibson, David Horsfall.

So, you are a Research Software Engineer or a technical person. You are interested in how data is produced and in issues around data quality, coverage, representativity, or bias, to name a few. More likely, you may even be interested in the assumptions that are made while working with data and the world-views that are encapsulated in these processes. Moreover, you have a series of technical skills that you’ve applied before in other contexts, such as developing tools or manipulating data, and you may have a preference for interdisciplinary research and working with others. You’ve heard about citizen science approaches and, unsurprisingly, you’re attracted by their potential to produce novel, high-quality data while being inclusive and reducing bias. You want to use your skills and expertise to contribute to an existing project or even initiate a new one.

Regretfully, reality is way more complex than it seems. You soon notice that, pretty much in the same way that there are not two RSEs that are the same, there are multiple ways citizen science can take place. What is more: the actors involved can differ enormously and, to make things worse, you notice that some people may have more than one role simultaneously! Understandably, you’re lost and start to wonder what you are doing in a process like that or what is expected from you. Fear not because in this blog post we’ll guide you through this process. We’ll do so by explaining what citizen science is and the different roles involved. We will also delve into how RSEs fit in this maze and the benefits of involving RSEs in projects like these. Last, but not least, we will give you some advice or tips for any RSE who wants to be involved in a citizen science project.

What’s Citizen science, then? Why does it matter?

Citizen science is a term used for a vast set of different practices across a similarly wide set of scientific domains. This can range from crowdsourcing the collection or processing of data to fully co-creating research projects with a community from start to finish through participatory or community-based action research. Regardless of where on this spectrum a citizen science project sits, what unites them all is the engagement of volunteers in the process of doing science. Two famous crowdsourcing examples are iNaturalist and Zooniverse. The former is an online platform for collecting a large database of geo-referenced natural observations of animals and plants. The latter is a large-scale platform for the processing of data, e.g. annotating images or videos, transcription texts or other microtasks. On the other end of the spectrum, projects like Making Sense co-create pollution monitoring solutions from the start, including the monitoring hardware, to finish. 

At this point, note that these examples are more than being a mere platform where citizens contribute to providing data, which can be considered problematic for some. Instead, volunteers were also involved in their co-design process, playing an active role in defining and validating the tool and, therefore, influencing the process. This is more than a subtlety and highlights two key challenges of citizen science projects. The first has to do with the many reasons to engage in citizen science: Large groups of volunteers allow the collection and processing of huge amounts of data, and co-creation approaches can ensure that research software fits user needs and considers data protection and other ethical requirements of participants. The second has to do with the role played by participants, especially acknowledging that there are many types of participants and ways of contributing. 

Roles and contributions in Citizen Science projects 

Like in any participatory process, citizen science can be complex in terms of assigning roles: on the one hand, it’s important to ensure the project is appropriately resourced and the roles are sufficiently well-defined that there is accountability and progress can be sustained. On the other hand, leaving roles open to participatory contributors is of intrinsic value to participatory research, as it is helpful to remove barriers and diminish hierarchies. There should be minimal gatekeeping and maximal upskilling and onboarding opportunities. With this in mind, some of the core roles are: 

• RSE: people with the technical knowledge and skill set to make and maintain the tools needed to operationalise citizen science. For a citizen science project, it is useful to come to it with an open mind and curiosity about the community you will be working with. It can be immensely rewarding to work with the people who will ultimately benefit from your work and it is an excellent opportunity for bidirectional learning. 
• Community manager/facilitator: a community manager is responsible for supporting community members, facilitating meetings, onboarding, and doing outreach. They should focus on creating an inclusive and welcoming research environment so that people feel comfortable joining in with tasks or contributing to decision-making processes. This is an important role as inclusion cannot be taken for granted: there should be an active process of dismantling barriers and supporting diverse inclusion, and this takes time, skill, and resources. 
• Project manager or PI: someone with an overarching strategic view of the project, who is able to manage resources, oversee critical tasks, bid for funds and ensure the project makes progress and reaches goals. 
• Researchers: people with a scientific or academic background to write papers, disseminate findings in academic settings, and ensure that the participatory work has an impact. 
• Designers: people with knowledge of design and translating user needs/preferences into tangible outputs. User testing is also critical. 
• Writers: this could include writing for a website if you are creating an online citizen science platform, but also writing blog posts, disseminating findings, newsletters, and articles, for instance. 
• Community members/volunteers: the core of a citizen science project. Community members must be equally recognised as other members of the project and have direction-setting and decision-making powers. This is a slippery category, as this group includes many people with overlapping skills, so creating the space and support for citizen scientists to be involved in all aspects of the project is ideal! While this can benefit both citizen scientists and the whole research team, it can be more complex than more conventional projects, as voluntary input can be harder to manage in terms of keeping accountability. Conversely, it can add a huge amount of additional insight and skills to the project as a whole. Where possible, find routes to reimburse citizen scientists/participatory researchers for their time. Conversely, if funds are not available, this could also be in the form of opportunities, upskilling, and reflecting their priorities and needs in the outcomes of the project. 

That said, the barriers between roles are more porous than it may seem and some roles may overlap with others (i.e. the writer role may be done by a researcher or even a community member, and there may be researchers in the volunteers who can contribute to the academic findings, or designers, or coders), but this is still a useful and frequent categorisation. 

The value added by RSEs in citizen science projects

We already covered what RSEs can do in citizen science projects, but what are the real benefits of involving them? In other words, how can RSE skills on a meta-level (i.e., technical skills; flexibly adapt these to different settings) bring value to these types of projects?

One of the most obvious but nevertheless critical, is that many citizen science projects are fundamentally impractical without software development, and others are substantially harder. As an example, it would seem tempting (and even sensible) to use existing tools like Google Forms, spreadsheets, or hand-annotation, but using them in this context can often be clunky, scale poorly, or otherwise impede research. Conversely, RSEs can either develop the ad hoc tools needed to collect, process and share data or to interact with existing ones and streamline workflows. As an example, for projects that make use of an existing platform like the Zooniverse, RSEs can help with defining the data flows into and out of the platform, and ensuring that these are automated and repeatable.

This is particularly relevant in some projects, where non-technical audiences can have a high barrier to participant entry if the tools available are not a good fit for the project. Therefore, bespoke platform development can lead to more participation, as well as better informed participation.

Another way RSEs can add value to citizen science projects has to do with their expertise in open-source development techniques and open science best practices. Many of the working practices that we use in research software engineering, particularly in open-source software development, can help with citizen science projects.  A clear example is that making information explicit and easily findable helps a range of people to find the project and participate. The most useful software projects have documentation like README files, notes about common usage patterns, advice for extension, etc. Using these helps us ensure that all decisions are made in the open and that all project participants have access to the evidence used to make project decisions. These are good practices to carry into citizen science projects.

And last, but not least, it’s worth noting that RSEs can act as an ‘informed layperson’ during the project design process. This is, a person with a research background but without the domain background of the researchers, who is able to raise flags and issues that might otherwise go unnoticed until deployment.

Final considerations

By now, you will have a better understanding of what citizen-science projects are, how RSEs fit in the different roles involved in these types of projects and what are the benefits of having them involved.  

Hopefully, as an RSE you will be even more eager to join, or initiate, a citizen-science project, so if that’s the case, we will end up with giving some final considerations that can be useful in that context:

• Understand the different types of citizen framework projects there are and where the proposed project fits. It can change from 1 type to another over time. 
• Don’t overengineer the framework as community participants may not be comfortable with RSE tools, including GitHub, and may want many ways of engaging. Examples given have included GitHub, emails and collaborative documents, all as ways of collaborating on the same project.
• Understand the GDPR regulations you need to work within.
• Funding and grant applications - how will the project be developed in the first instance, and then maintained?
• What are the expectations of the project from the different stakeholders - the community most importantly, but the RSEs, the funders, and other collaborators?
• Community involvement - how will the community involvement work? Meetings? Real or virtual? Synchronous or asynchronous? The community may have different ways of wanting to engage

Original image by Dan Asaki on Unsplash

The Collaborations Workshop 2024 (CW24) brought together researchers, developers, innovators, managers, funders, publishers, policy makers, leaders and educators to explore best practices and the future of research software. CW24 took place as a hybrid event. The in person aspect was hosted at Scarman, Warwick Conferences. 

This blog post was first published on the website of Research IT, Manchester University.

Back for its 16th year, the Collaborations Workshop (CW24) recently took place at Warwick University in Coventry. The workshop is organised by the Software Sustainability Institute and brings together researchers, developers, funders, leaders, educators and research software engineers from universities and industry.

We had the great pleasure of participating in the workshop in-person and taking part in the engaging discussions over a course of three jam-packed days. As the name suggests, the CW24 has a strong focus on encouraging communication and collaboration between participants, offering many opportunities to network and meet old and new members of the community in the form of meals, social sessions and coffee breaks.

The themes for this year’s workshop were Environmental Sustainability, Artificial intelligence (AI)/Machine Learning (ML) tools for science and Citizen Science. We were also encouraged to propose our own topics and develop discussions around them. The keynotes gave opportunities for experts to present on the workshop themes, while panel discussions and breakouts allowed participants to critically engage with important questions about the future of research software engineering.

The first keynote was by Arfon Smith from GitHub, who talked about how generative AI tools, such as GitHub Co-pilot, are going to completely change the way research software engineers (RSEs) work in the next 5 years. With most people in the room having many concerns over this potential future, he shared his five principles for building generative AI products: no decisions, design for failure, ground in reality, invite only and “explain like it’s me”.

The second keynote was by Lucy Robinson from the Natural History Museum, sharing with us her experience creating advocates for nature through community science (not citizen science) programs, such as the Natural Education Nature Park Project and iNaturalist UK. Finally, Kelly Widdicks from the UK Centre for Ecology and Hydrology discussed the hot topic, if you excuse the pun, of the climate impacts of IT infrastructure. While there is widespread acceptance that we are in a climate emergency, tools for assessing the emissions from IT infrastructure are currently limited and not often considered by researchers or funders, although these will become increasingly necessary as Net Zero targets are implemented.

Most of the other sessions during the conference ran in parallel, allowing each of us to focus on a variety of topics of interest such as environmental sustainability, portfolio careers, community building, and best practices among others. There was also a series of lightning talks during the workshop, where Scott talked about the “Climate Just” project. On the final day of the workshop, we participated in the Hack Day, splitting into groups to build proof-of-concept projects from ideas discussed in the workshop.

In preparation for the Hack Day, during one of the Collaborative Ideas sessions, we had a discussion about mental health and productivity in the context of research software engineering. Our proposed solution was a Carpentries-style lesson discussing the mental health benefits of organising one's thoughts, tasks and commitments into a trusted system to reduce stress related to workload, and open the mind up to creative thinking.

We developed the idea further during the Hack Day and were able to successfully initiate a Carpentries lesson for the same, which also ended up winning a prize at the workshop! The lesson is a prototype and a work in progress, and we aim to develop it further into a full-fledged lesson and resource over time.

The other Hack day project we participated in was on building a database of education history of UK members of Parliament, such as which University they attended and what they studied. Amazingly, even though this information is publicly available, there is no easy way to find all this data in one place. We built a prototype that scrapes MP’s University attendance from Wikipedia and presents it through a simple front-end map.

Attending CW24 was an excellent learning experience, which not only helped us reflect on the work we’re doing, but also gave space to new ideas and conversations. We were able to start new collaborations in different capacities, and are looking to build them further. At the team level, we hope to include important conversations such as environmental sustainability, use of AI and mental health in our day to day practices.

Overall, the SSI CW is a great opportunity to discuss everything about research software, form collaborations and network with the community. Its unique structure, which actively encourages interaction and discussion, seems to attract engaged and interesting researchers, creating a friendly and lively atmosphere. We’d highly recommend attending the workshop in future years and would love to go again.

We are thrilled to announce that the upcoming Collaborations Workshop 2024 (CW24) will be sponsored by Wellcome and The Alan Turing Institute.

Our platinum sponsor, Wellcome, funds research into life, health, and wellbeing. They are taking on three urgent and interrelated global health challenges: mental health, infectious disease, and climate and health. Their Data for Science and Health team shapes and funds data science initiatives to advance Wellcome’s mission. Data and software are at the heart of modern science and health, and they want to ensure these tools are designed, built, and governed in trustworthy ways. 

Our gold sponsor, The Alan Turing Institute, is the UK's national centre for data science and artificial intelligence. Their mission is to create significant advancements in these fields to change the world for the better. The Institute has three goals: advancing research, building skills for the future, and driving an informed public conversation. 

We are grateful to have both Wellcome and The Alan Turing Institute as sponsors for CW24, and we look forward to their valuable contributions to the event.

Collaborations Workshop 2024 will be held online and at Scarman, Warwick Conferences on the University of Warwick campus from 30 April to 2 May 2024.

Collaborations Workshop 2024 (CW24) will take place as a hybrid event at the University of Warwick, UK, from Tuesday 30 April to Thursday 2 May. Submissions for contributed mini-workshops and demos and lightning talks are now open.

Registration for Collaborations Workshop 2024 is now open via Eventbrite.

Collaborations Workshop 2024 (CW24) will take place as a hybrid event from Tuesday 30 April to Thursday 2 May 2024 in Warwick, UK. 

The Software Sustainability Institute’s Collaborations Workshop series brings together researchers, developers, innovators, managers, funders, publishers, policymakers, leaders and educators to explore best practices and the future of research software. 

The themes of CW24 will be:

• Environmental Sustainability: including how to determine the environmental impact of your hardware and code, training and education about environmentally sustainable behaviour, and activism highlighting potential improvements to existing infrastructure, processes and systems.
• AI/ML tools for science: including benefits and limitations of using AI/ML tools to write your code, ethical considerations when using these tools, and training and education around the usage and impact of AI/ML tools.
• Citizen science: including designing participatory research projects, training and education around citizen science, and the role of research software in citizen science projects.

Registration

Registration for in-person or remote participation is now open via Eventbrite. Tickets provide access to all plenary presentations, interactive sessions, communication channels, social activities and the Hack Day. By registering for this event, you agree to abide by our Participation Guidelines.

The in person aspect will be hosted at Scarman, Warwick Conferences. Warwick Conferences is based on the University of Warwick campus, on the outskirts of Coventry. Hybrid participation will be facilitated using Zoom. 

Financial assistance

The Software Sustainability Institute is committed to fostering and supporting a diverse, equitable and inclusive research software community. We are proud to offer financial assistance to members of underrepresented groups, students/early career stages, and others who may not be able to attend or fully participate in the event otherwise.

Applications for financial support to participate in CW24 can be submitted until 23:59 GMT,  Friday 16 February 2024. You can find more information as part of the application form.

Keep an eye on the CW24 website or sign up to receive CW24 updates closer to the event.

The Collaborations Workshop 2024 (CW24) brought together researchers, developers, innovators, managers, funders, publishers, policy makers, leaders and educators to explore best practices and the future of research software.

The themes of CW24 were:

• Environmental Sustainability: including how to determine the environmental impact of your hardware and code, training and education about environmentally sustainable behaviour, and activism highlighting potential improvements to existing infrastructure, processes and systems.
• Artificial intelligence (AI)/Machine Learning (ML) tools for science: including benefits and limitations of using AI/ML tools to write your code, ethical considerations when using these tools, and training and education around the usage and impact of AI/ML tools.
• Citizen science: including designing participatory research projects, training and education around citizen science, and the role of research software in citizen science projects.