 Hi, my name is Tom Honeyman, and I'm the manager of the software program at the Australian Research Data Commons. Today I'll be talking about the draft national agenda for research software, but I'll primarily be focusing on the areas relevant to research software support. The agenda defines a set of actions to address a single change, recognition of research software as a first class output of research. These actions are grouped under three abstract and high level aims to see research software by making research software visible, shaping research software for broadest and easiest reuse, and sustaining research software by maintaining relevant research software infrastructure. All of these require a fair bit of unpacking, but more detail is always available in the agenda document itself, which is available at bit.ly-rs-agenda. The three high level aims are identified by clusters of distinct but related types of output, their stereotypical author, and the key concerns and drivers for those authors. These are specifically the concerns and drivers for change with identified authors, not necessarily the primary drivers and concerns for all stakeholders. Today I'm concentrating on C, and considering C, which is the top layer here, I'm mostly focused on concerns with what I call research data processes in research software form. Most commonly this refers to what is conventionally known as analysis code, but I would extend this out to objects not usually thought of as code in this way, including command line one liners, macros in a spreadsheet, but also the more complex scripts for repetitive tasks to do with data handling and transformation, right up to compiled software written often with a single use. But it's limited to use within a project by an individual or a project team, and likely to be discarded when the project is over. The core concern for this kind of software is that it is rarely made available. This varies by discipline, of course. This kind of software is usually written by researchers, but I acknowledge that it is not limited to researchers, and I really should acknowledge that this activity is not often captured as software at all. Most commonly the steps taken are lost forever through point and click applications that do not capture the provenance of a research result, including the underlying software components, some of which is research software, all of which contributed to the result. The driver for change here is research integrity, or if you prefer, a desire to conduct research with transparency, possibly addressed by what is usually referred to as code availability in the literature, or even as a component of computational reproducibility. Briefly, I'll talk about the other two layers of the program, but these are not the primary focus of this video. Here the software output is different, in that we're talking about software designed to be used by others. The shape layer is concerned with those new methods and models as research software, and I'm making a contrast here with accepted methods and models in the third layer. So for new methods and models as research software, these could be novel tools, utilities or libraries. They may be intended to be incorporated as a novel but reusable step in a workflow. They may represent completely new algorithms or a stepwise improvement, but nonetheless they are experimental or prototype pieces of software. The core concern here is the sufficient application of best practice software engineering. This type of software may be developed quickly in a small funding window. The author may well be highly specialized in the relevant research areas, but not necessarily in software engineering practices. Either way, the core concern is the sufficient application of best practice software engineering to ensure the software is robust, optimized and expressed at a sufficient level of abstraction to ensure broadest and easiest reuse. A secondary concern here when considering broadest reuse is the skills, constraints and applicability of identifying audiences for new software and their specific needs. I'm suggesting that this kind of software is most commonly written by authors who sit somewhere in between everyday researchers and software engineers. I've coined the term nascent research software engineers to refer to these authors, but I also note this might be a partnership or a team effort. By nascent, I'm flagging the capacity to be a software engineer rather than suggesting that all people who find themselves in this position need to be formally trained as software engineers. Because I'm assuming these nascent research software engineers are steeped in research, I'm assuming that research excellence and impact are drivers for change with this group of authors. Better engineered code should have greater impact. Robust and optimized code stand up better to scholarly scrutiny. Sustain is concerned with those methods and models as research software that are accepted and broadly used. They may be implemented more than once. They may represent fundamental concepts that have utility across a broad range of domains. Or they might just represent the well-accepted methods of a highly specialized domain. The core concern then is the maintaining, is maintaining the specialist research software infrastructure. This is a major gap in our current system and a difficult problem to solve. This code is developed and maintained by research software engineers, usually, but not always working as professional staff. The driver for change here is a cousin of research integrity. This software underpins all others and so supporting it supports the overall stability of research software infrastructure. Because if we revisit the outputs column here, we can see that these software types loosely represent a stack. Here, this is building on the scientific software stack concept by Conrad Hinson. Beneath these layers of research data processes, novel and then accepted methods and models as research software sits conventional software, then operating systems, and then finally hardware. All of these layers are necessary to prop up research software. By way of example, a researcher may analyze their data by writing some simple analysis code, which in turn uses a novel statistical method. And this in turn is built upon far more conventional and accepted ones. In this way, one piece of research software is almost always dependent on others to function. This should be no surprise to this particular audience, but it's not a broadly known thing by consumers of software. In this way, all the layers of this agenda are connected and yet splitting them apart like this helps us to understand and order the actions we must take and the way that they relate to each other. Recognition, as in recognition of research software as a first class output of research, is a cultural act. We've used the Center for Open Science as a strategy for culture change as a reference model to break apart each of the three layers into four separate areas. For each of C shape and sustain, we have to consider the infrastructure that is needed to make the change possible. And I don't mean a variety of build it and they will come. I mean we shouldn't ask for what can't be done. Guidance reduces the friction in any change. Guidance can take many forms from documentation to self-face training to consultants or service staff who work with researchers or research software authors and directly. Communities make change normative, but they also feed all other activities. They inform infrastructure and guidance needs and inform policy, which is our final area. I use advocacy here to refer to both advocacy and implementation of policy and strategy. This merges two areas in the Center for Open Science strategy and covers both incentives and requirements settings. Finally, the agenda characterizes stakeholders in action against this agenda and gives an indication of the presumed levels of interest by each stakeholder in the various actions proposed. So this includes software authors, professional support staff, which are further broken down into different types, and the managers of RSE, of research software engineering service units, which have a very broad set of realizations across the sector. In the agenda, research software support is broken down into two categories in line with the first two layers of the agenda framework. Aligned with C is what I call software informatics support. This is the support staff needed to advise or build out capability in software citation and publishing practices, as well as preservation and other archiving or informatics-related concerns, especially those related to the visibility of software. There are also roles at the intersection of data and software. For instance, curation of data and code bundles to facilitate computational reproducibility and the task of capturing software actors in data provenance. To my knowledge, we don't have dedicated roles that exclusively support the areas related only to software, but this is something I think as a sector we may be able to mature over the next decade in much the same way we have for research data. But in Australia in particular, we do have trainers, consultants, for instance research analysts, data stewards, data librarians and data managers, and other similar roles who may touch upon these areas. Aligned with shape is what I call software authoring support. For authoring support roles, a decent level of programming skills is what clearly differentiates these support staff from informatics support staff. But I recognize of course that the actual roles may overlap significantly and indeed software authoring support also crosses into software authoring itself. Institutional stakeholders include a wide variety of institutions where research is conducted from universities and research institutes to publicly funded research agencies all the way to industry. As employers of research software authors who set strategic priorities, who create roles, who credit work with promotions and direct actions with policy and so on, these institutions are a clear stakeholder in the agenda. The institutions are also often the owners of IP, or at least have a stake in it. And a nuanced conversation about ownership is actually a critical piece of work for this agenda. Publishers and funders have a clear role in policy settings for this work. They can also influence the editorial policies of specific journals and drive new initiatives. Data generating facilities have a role in capturing software actions against data generation, transformation and analysis, and potentially in a workforce that augments instrument-based data to collection with new software methods. National digital infrastructure providers provide hard infrastructure in the form of specialist compute, storage and networking capabilities, but also services built on top of these like national, general and domain specific authorship platforms, which is presently mostly Jupiter hub instances, but also identifier, vocabulary and registry services related to informatics needs. Returning to our three high-level actions to see, shape and sustain research software and combining these with the steps for culture change, a set of 12 themes emerge, all of which have corresponding actions in the agenda. The actions are more verbose, so I'll stick with these labels for now just to give a sense of the overall structure. This can be read across or top to bottom, but which way to read it usually aligns with what kind of stakeholder you are. As I mentioned earlier for software informatics support, I'm assuming that it is all of the actions to see research software or the top row of this grid that is of particular relevance in this video, but for some viewers it may well be that some items in the second row are of interest. You may like to pause for a second and read these before continuing, otherwise I'll now turn to the specific actions of the first row. The actions are ensure that research software publication, citation and other informatics infrastructures fit for purpose and ready to meet newly emerging practices. This covers permanent identifiers infrastructure, repository's infrastructure for both development and record keeping, registry's infrastructure and the emerging set of infrastructure around enabling computational reproducibility, computational notebooks, computational workflow engines and so on. Action number two is to connect researchers through support professionals to guidance on informatics infrastructure and emerging best practices. This is both the materials and the availability of people delivering support for using this infrastructure. Number three is to build and sustain a national community of practitioners interested in informatics infrastructure and in the behaviors that inform it. Communities inform and drive change, they develop and utilize shared assets and make change by demonstrating and benefiting from shared behaviors. In this video, I hope that I'm talking directly to that nascent community or those communities. And finally, the fourth action is to create the policy and incentives environment to encourage code availability. Again, I believe the addresses of this video have a clear role in driving this agenda by guiding us all into a set of shared behaviors that can be captured as policy. Finally, I want to highlight four ways in which we can see the impact of research software. The first is by citing the software used in the research within a scholarly publication. We're now seeing emerging standards addressing this. The second is to incorporate a record of software tools used to generate and transform or otherwise prepare data in its provenance metadata. The third is the formal capture of the tools used in the form of a workflow, which is really a cousin of data provenance. These are all in aid of making software visible, that most likely was not created by the author of a paper or the owner of a data set. For the authors of software, they can clarify expectations around citation and ensure that they use recognized methods and especially first class permanent identifiers. This is particularly relevant for software tools that were created with the intention that they be used by others outside a research project or a research group. For analysis code or the broader category of what I've called research data processes captured as software, providing this code as supplementary materials or through the repository is more commonly used for data right now, creates both a record of the work done by the author, but also in the form of the code captures a record of the software they have built upon. In other words, this kind of software is the raw material that connects the underpinning research software to scholarly outcomes and that is within the code itself. The next steps are that the presumed priorities in the draft agenda are to be replaced by actual measures of priorities from the identified stakeholders. The ARDC will go into planning for activities that we will undertake but that we would like to deliver with willing partners in action. Thanks for watching this video today. If you'd like to get in contact, my email address is tom.honeyman at ardc.edu.au. You can read the draft agenda at bit.ly slash rs-agenda. And if you're more interested in just monitoring activities arising from this work, perhaps you'd like to visit ardc.edu.au and just sign up for our newsletter. Thank you.