 Welcome everyone to the Visible Research Software Interest Group first year anniversary. We are here together to discuss some news about how to make research software more visible, hear from the community and discuss what are the current activities. My name is Paula Martinez and I'll give you a short introduction about the group to start with. First, I'd like to acknowledge the traditional owners of the land in which I live and work, which are the younger and turbo people and Brisbane. And I pay my respects to the elders passing present and I acknowledge any descendants of our original Torres Strait Islander people. So for those of you who are new to the Visible Research Software Interest Group, I like to show you a bit of the landscape and if you could use the reactions just to let me know. If you knew any of the blobs in green or you were part of them before joining this group. So I put them in an access where people are change makers and also those groups that are discussing research software. So you can see here, Sri Lankan Research Data Management Community, the Data Management Plans, Interest Group, Data Librarians Community, the Data Repositories Community of Practice. Those were groups that currently exist and they are talking about something similar to what we want to discuss but we really wanted to move the conversation more towards research software in this region. And there's also the Research Software Interest Group, Tech Talks, Haki Hours and Software Citation. Those in grey were pre-existing groups that are not running anymore, but maybe you were part of them and we also try to revamp those groups into this new interest group. And that's how we found our space in the landscape, which is the Visible Research Software Interest Group. And our goal is, our goal and aim is that we want to affect change by boosting the visibility of research software in a way that it's more and better cited so people can recognize the efforts of the developers and the containers and it's published so it's not hidden in one of the computers of the researchers and it's also fair. So we are going to discuss about Fair for Research Software, it's one of our first presentations and then you can ask more questions about how to make software fair. Again, for those of you who haven't been with the group for a year or since our both, I want to let you know that there are some resources that were built through this community. And these are small victories and we want to be celebrating those this first year. So we have a website and I think that everyone knows the website is the Visible Research Software Interest Group. Through the website you can find the list of resources that I'm going to mention here, the terms of references, who the hosts are and also who the members are. So if you have signed up for this group, there was a little form at the beginning asking you whether you want to be displayed publicly in our member list or not, and that's also in the website. I think another small victory is that we attracted the right audience by clearly stating who should join the group. So we want people who have influence in decision making about, for example, institutional policies or changing how software can become more visible. So if you're working in a repository, you can also state what the goals of this group are and you can share those news. If you are a developer, you might have different approaches that you like to be considered for you to share your software, so you're also welcome here. Another thing that we did when we started is to create an open online discussion forum and that's still ongoing. It's via GitHub where people can add any of the suggestions or ideas about what things we can do together to make research software more visible. We also now recently this year opened the mailing list so if you are more used to answering emails rather than going to GitHub for discussions, you can now post directly on the mailing list to share your news and become more engaged with the group. And the report that I put up here, it's called that I only have the battle. And this is the report that initiated this group. It has more than 380 downloads at the moment. And I think the double of views. And it's a list that we collected with the community about different types of guidance to make research software visible. It's more than a year old now so you probably need some updates but it's a very good starting point. If you are new to this area, I really recommend going into that report and seeing the different parts of it. We have seven authors who came with the expertise in their own domain so there is a richness in that report. Another thing we did during the course of this group is another report that ARDC Commission is understanding how researchers find research software for research practice and it's been downloaded 200 times. This has asked researchers how do they find software and we have now some initiatives to move forward into talking with infrastructure providers and how we can enable better findability of research software. And now I'll go very quickly through announcements that I think the community should know about. The 411 annual conference is happening next month between the 18 and the 20 of April. And there is some talks about software that you might be interested like a lightning talk supporting software citation without reinventing the wheel from Crossref. And there's also a panel discussion implementing for fair workflows. This might be a bit hard for Australia but they're probably going to put them right afterwards but you can also share with your communities. Then the research software alliance has a task force ongoing about research institution policies to support research software, and they don't have to be specific documents they can be part of a data management policy for example. If you are aware of any of this please share them by the link that I'm sharing in the in the slides and we'll be happy to collect those resources to things that are happening in Australia or Australia. The research support community day has been announced for the middle of the year at the end of June and expressions of interest are due tomorrow and Jerry is going to invite you to put a proposal together in just a few minutes. We also have the Australian Museum Eureka price for excellence in research software and applications will close on the 14 of April. Please encourage any submissions or nominate people that you think are suitable for this price. And then research Australia happening in October we need to put some abstracts before the first of June. So that gives us two months to think about what we can do within the community in that time. And this is more about international events that had happened before, but I think I was knowing if you are part of this group. So there is psychos the consortium of scientific software registries and repositories, and now they have published their presentations through a YouTube channel. There is presentations from even from last year that were not public before and I welcome you to watch them they are very short, about 15 to 20 minutes so there's also a lot of things to learn from in there. There was a recent workshop on Friday about guidelines and metrics for metadata curation that was part of the research data alliance and the recording is now available on YouTube. And also the fair points ask me anything happened in February. And as it was a very similar event to what we are running here locally and the recording is also now available. Okay, now opposite to Jerry to introduce himself and I'd like to welcome him as the new co-host of the interest group. Thanks Paula. Hi everybody. Yes, so I'm new to this group. I'm just going to give a brief background about myself and where I fall into the, I suppose, the software area. So I'm currently my role on my research data librarian at UNSW. I started that role about six months ago. But originally, I suppose, many years ago now I started out as a climates and atmospheric science researcher. And at the time I was a computer modeler. So I spent a lot of time programming models of the atmosphere models of clouds and how those clouds interact with the chemistry of the atmosphere. And back then it was a lot of, it was mainly Fortran 90 if anyone's had experience in the programming language. I don't think I've got fond memories of it. But yeah, but whilst, yes, I have my complaints about the language itself. The good thing about that time was what I did learn. And as I said, this was 15, even 20 years ago was good software practices, or at least at the time, the software practices, and really, at least from my perspective that was a lot of that was around, for example, using SVN, the version control, and the advantages that brings. So even back then I was able to see firsthand the advantages of developing software in a proper way. And the advantages that that then came with that when it came to collaborating with the many other people who were developing the cloud in that space. So, from my own perspective, yes, it was great and I could see, early on, the advantages of doing software properly. I moved away from direct doing research itself, I moved into the more of the research support around climate modeling, and in particular that was around developing metadata systems for how to properly document climate models. So, researchers all around the world, developing climate models and atmospheric models, but also they're all working with each other. They're all particularly in these large global climate modeling studies. Institutes around the world that all had their separate climate models would, as part of these large experiments CMIT, the IPCC, which I'm sure you're all aware of. They're doing the same experiments, but with their own software, their own models. So it was key that this was done properly. And what we did as part of this next role that I was referring to was developing the standards, the metadata standards, the vocabularies, the schemas that all these different research centres could adhere to, so that we knew that the comparison of model outputs were accurate. And again, it was another, for me at least it was another venture into doing software properly. From there, I moved to Sydney. I moved to Western Sydney University out in the Hawkesbury here area of Sydney. I was a data manager in that role and I did various roles around data management, helping researchers just to essentially manage their data properly. Whilst I did a lot of different roles in that job, one once I did want to highlight here, because I think it's quite relevant in this space, was we did a lot of, our researchers at least did a lot of co-development, software development around genomics, gene sequencing, pipelines, all of that area of science. But we really did see firsthand whilst that isn't my specialty. In supporting them, I was able to see firsthand the fact that when software isn't done correctly, how difficult it can make things. So for example, we, in helping those researchers and working with the researchers, we often found it was hard to find code in that space to do the science that these researchers wanted to do. Particularly for example, when we knew that that code did exist, we knew the journals were out there, they were written, the science was done. But when we, or if I wanted to help those researchers, reuse that code, getting access to that code, finding it, we find that notoriously difficult. But even beyond that, when we, when we could get access to code or scripts or whatever it might be, we very often find it was just that either we couldn't understand it to be able to reuse it, or just getting it to run. So essentially to rerun the code we often find very difficult, and then that led to the inevitability that we would then try and just develop the software ourselves. So a lot of the time we knew we were wasting effort, because as I said we couldn't find the code or we found the code and just just couldn't get it to work. So we knew we were just rewriting stuff that was already done. So we started streaming from that when we did write the codes, getting the proper practices then for getting our code out there. We just didn't have the, the knowledge of how to do that properly. So, yes, as I said I think through that we, we discovered that there's a lot that we need to learn to make this whole process a lot more efficient. I suppose that takes me to where I am now, as I said I recently started at UNSW. I'm working with the UNSW's institutional repository with a focus on data, my, in the data space, but also around, we will be beginning a new drive around the NTROS, the non-traditional research outputs, and getting them into our repository and getting them out there and getting them made discoverable reuse all of that, but that very much includes software. So we're very keen, I'm very keen to learn myself about how we can utilize this community, what can we use that's out there for really improving once, for example, taking software, using our researchers and how to get their software outputs into whatever system it may be, but eventually into our, a record of which into our own repository, and then make it using our repository to make that that software as discoverable as possible. So, as I said, this community should be a lot of huge benefits to that. So is there any questions on that or want to know more about any of that side of things? Feel free to put your hand up or certainly ask me afterwards. Thank you, Jerry. I'd just like to add that Jerry is joining after Vanessa Crosby, who has been our co-host for a year, and it's also representing UNSW Sydney Library. And so it's a reminder for the community. If you'd like to be more engaged, like being a co-host, it's an open position that you can join at any time. Shall we go to the next one? Actually, I have one question. And so I came in a little bit late, so you might have already covered this and I apologize if that's true. What is a co-host position? Is it just co-host or is there more? As a co-host, so we are three co-hosts at the moment. Johan Gustafson from the Biocommons, Jerry from UNSW and me from the Australian Research Data Commons. And what we do is run the interest groups. So we take care of who joins the group, we welcome them, we send the news, so we get together and decide what news I get to share, and we put together two events a year. That's so far what we are doing at the last co-host. Did I answer your question? Yeah, that was great. Okay, Jerry, do you want to say a few words about our CD? Yeah, so this is just a call out for the RSCD. So this is happening at the end of June. I think it's the 27th of June for two, three days being, I think it's hosted at QUT. But really we're looking for people to, in interest in this area to really, to step forward, really anything that you can add to the community and get knowledge out there, put in an abstract. We're very keen to hear what stories are out there, what problems are people having, what wins are we having, what new ways of doing things are we having. So actually I'm just going to quickly drop the link into the chat. But I mean if anyone wants to talk in advance with any of us about their ideas, maybe they are interested in presenting here. Absolutely come and talk to us first with your idea or post it through our web pages. If you wanted a little bit of discussion around it. Yes, I'll be putting forward a my own presentation. I can talk a little bit about essentially at this stage the idea around that if that's of interest at this stage. But otherwise, as I said, feel free and we really do hope that people will put things forward for this. Thank you. So now we will go to the presentations part. I'll ask questions while I change my screen. Yeah. Okay. Yeah, I have now a few minutes to talk to you about fair for research software. This is a presentation that I've gave before, you can find the do I and the slides and I'm going to be short through the history of the fair for research software and highlight a few things that we can do to support visibility research software. I did the acknowledgement already. I'll skip that. And I want to talk about fair is findable accessible interoperable and reusable. And it's an acronym to support research outputs to be more, more impactful to make translation and innovation easier. So fat is not the end goal. The end goal is to make research more impactful and also in the way we can probably improve the quality and that's our hope as well. I also like to point to this paper from 2021 10 computer codes that transform science. It's a really good read it's short. It's in nature and it says that really computer codes are changing the way that we do science and it's been essential for science to be innovative and to accelerate. And they are citing software research software that is changing the way we do science and how we can improve it if we continue this path. And there's some good quotes in there that I like you to be aware if you want to motivate other people to make research software more visible as well. Now I like to go into different features that research software have that are different from data and that's why we have different set of principles for research software. So, research software, it's not just a type of data, it's been taken like that from some time, but we want to acknowledge that it's a result of a creative process and as does if you have met any artists for example that they never consider it an end result. So there's always something you can improve and change it. So it's always going to be changing and iterating. It evolves over time so what you have today might not be what you have at the end of the month or at the end of the year. It also has different components. So it has very complex dependencies. It's usually not a standalone card that runs by itself. And also we have source code as part of research software and also we have the executable part depending of what kind of user you are you deal more with the source code or more with the executable. So these are things to consider when we when we are talking about making research software fair. And these features have been highlighted by an Elena Lamper in a paper from 2022 that it's called Tollworth's first principles for research software. Now to get a bit of a definition. There was a working group part of the fair for research software working group that put this definition together. So what do we mean when we talk about research software. So it's, it's a kind of software it's not all the software in the world, which purpose is it's been created for a research process, or to support research. These include code, algorithms, scripts, computational workflows and executable so all of these different names are included in the definition of research software. Now I'll go a little bit of the history highlighted some papers that you can cite or read if you are into it. One of the first ones to develop this movement was the software citation principles in 2016, when we are recognizing software as a different scholarly output, and that it needs to be more visible so this principles were were made politically available. Then there was a spring that many organizations international came together in their domains to have some guidance about how to make data and software more fair in simple steps so it's a guidance for specifically for research developers, 10 points you can do to improve the fairness of your output. And that's when we started talking about software as a different type of digital output. Then it's the paper that I just mentioned from an Elena towards first principles for research software. It was written by a small group of people where we compare the data principles and we discuss how this could be adapted to research software. And we wanted to validate those principles with the community and that's how the fair for research software working group was lunch with three journal organizations the research data alliance, the research software alliance and force 11. So during two years and a half we had a lot of discussions with the community about 500 people provided input into these principles into guidance into how we are able to support this principle after they are published. So all of this has completed last year with the publication of the first version of the fair for research software principles that I'm going to describe very shortly, and also there is a nature publication that I'm going to highlight in the next slide. So from now on, if you are talking about research software, please reference these principles and and have a look about the discussions this document has a lot of the description of the discussions that we had in the group, why we've taken those decisions. And one of the members of the group it's Daniel Katz, and he is the author of a paper that is part of the group outputs it's taking a fresh look at fair for research software and, and he said I'm quoting. So the fair principles for research software I stepped forward on the path to recognizing software outputs in academia. And the idea is that it will produce better research so that's how I started this presentation and I want to really emphasize this because that's the goal, the goal is not making things for them, the goal is making better research. So if you go to the fair principles for research software document. I want to point to four discussion points that we had during the group in order to come up with the new principles. So the first point is that the intent of the fair guiding principles or the data principles were taking us a starting point so we are not deviating too much from them. If you are very knowledgeable about the third data principles, then you know 90% of the fair for research software principles, then the third principles are aspirational, it's not binary. Whether you are fair or not fair is something that can be continuously improved and that's why metrics are a bit difficult in this space, but there are many groups already working on giving a metric of facts. And then that software encompasses many forms it's the by that I mentioned in the features of software, but for the purpose of making research software fair, we recommend to use the type of source code, because source code it's something that uses, as in people can see recognize and understand, and also machines can see recognize and understand so because fair is for people and machines, we recommend to make fair the source code, not just the executable. And something to keep in mind is that there's a lot of best practices in developing software that will create a better quality software, but these are not part of the third principles. They're addressed separately so we haven't gone into best practices recommendations, but we encourage people who are developing software to have those in the same space when you are considering improving the quality of your software. This part is to show how software can become increasingly accessible and findable. So without going into each of the principles. I like to give you a few examples. If your software is in your computer or in your users computer and no one has access to it. It's not fair at all. If you are an individual that says you can contact me to get access to the software, whether you have it in your computer in an internal private repository or in a public platform those are steps that you can transition to make your software more visible. And next step will be to make your file files downloadable. And it could be linked from your personal website. It can be linked from your group website or for from a server that anyone could access, but still have any mind if they don't have this access point they won't be able to download your file. And then going towards a bit more accessible and findable is to have it in a public accessible code development repository which is now very trendy for people who are developing software. Those are like Bitbucket, GitHub, GitLab. Those are code development repositories where you can put your code in a public manner and anyone who wants to explore could find software there. The difference is in that these are specifically for retaining code, but not so much about the metadata. So it's a bit more difficult to find things in there. To enable metadata search there's all the generic registries and they are mostly linked to this code development repositories. For example, a registry could be a synodal fixture. The positive of this is that you can get a persistent identifier such as a DOI that won't change and even if you change your code it will link to the version that you cited in the first place. And to make it even more fair it's to have it in specific registries and repositories that are for your domain. So it could be a domain in your computer language or it could be a science domain and there is at least being curated by the Netherlands Science Center. It's called awesome research software registries. Two of the principles that I like to highlight here is that in the data principles they just said you have to have your data with a persistent identifier. But because I mentioned before that software can have different components, we are recommending people to have an identifier for each of these components and also for each of the versions because software evolves over time. So that's something different from the data principles and inaccessibility. It's the ability to retrieve the software again by users, people and also by machines and to enable this, we could be using standard communication protocols instead of saying you can contact the author to get access to the software. And to make software increasingly interoperable and reusable. We have to avoid any manual steps. So if you, if you need to do anything such as putting a path to run this software that you cannot do automatically that's a manual step so if we can cut any manual steps that will make more interoperable and reusable. We have clear provenance that describes what you need to run the software as an infrastructure so what hardware you need, what all the libraries you need and what all the tests and data sets you need. And if this all components are attributable and citable with their own PIDs and citation, that's even better. The output that you are out taking from your software machine actionable, that will make them more interoperable so they can feed all the software in a change for example in a workflow. And then for reusability that many features as well how it can be reused in different settings so it can be reused if it's understood that means you need to have good documentation it can be reused if you can modify it so if it's in a language that other people can also use. And it's not proprietary or it doesn't have our restrictions, for example, it could be built upon so that's the the part where we can actually improve the way we do science because we don't have to reinvent the wheel. And it can be incorporated into other software so these components the the smaller they are and the better interoperability they have, they could become a larger ecosystem of software tools. And the principles are dependent about upon community standards so we also recommend that if your community uses specific data types or specifically metadata fields that you take this into account. And then there are many examples from specific communities and these are still being worked out. The few principles that I want to highlight here is using API for exchanges, whether it's data or other software. The reusability that I just explained, it can be improved if you have a clear accessible software license that. I'm going to introduce you what are the terms and conditions for reuse. And these are different from the data licenses that's something that people who are supporting all the people to make software visible need to have very clear. These are distinct licenses and they have their pros and cons. In a fair setting licenses could be proprietary or not, but a recommendation is to use open licenses to make reusability broader. And the references that I gave in the example, anything that it's part of provenance or not only the other software components but also the references to other objects like data sets that are needed to run the software are to be included in the metadata fields. That's all from me and if you have any questions I'm happy to answer and then we'll go to the next presentation. If anyone wants to ask a question just feel free to unmute your mic or if you prefer you can just post your question into the chat. The slides that you just went through with all the DIYs is that available on the teams site somewhere. I will send them by email. Because this is a presentation that I gave before it's also in the link from the registration link on Eventbrite. You can access in there. Anyone else question at this point for Paula. I was going to ask a question myself but I think I'll keep it for the discussion part towards the end it was more around the discoverability, but I think as I said we can keep that for the the end piece. I think Paul we have a question here from Emily. Concrete example of how we might build interoperability into existing legacy codes. What should we prioritize in nut space. Yeah, thanks Emily for the question. This is something that has been asked before and I heard the answer which I think it's very good answer that I'm going to repeat. There's something called the software heritage. It's international repository of code, and they have the code of the first spaceship that went to the moon. So it's called that it's legacy code that it's not run running anymore but because it was stored as source code, people can still read it and understand the parts and I think that's the part that enables interoperability. If you understand how the algorithm runs, then you can translate it into other programming language that it's currently in use that will enable interoperability. So one of the priorities that I will cite is saving it. And so it's not lost after it has been working for what the second one will be saving it as source code and having a license that allows to be modified and build the bond. Great. Any final questions just for Paula before we take a very short break. Yeah, let's do a five minute break. Yeah, I think we're running slightly behind schedule so maybe we can take a little four minute break and come back at 1150. Give people a chance to just stretch their legs. Great. Talk to everyone in a few minutes. Can you see the slides. Yes, perfect. Okay. So my name is Johan. I'm from the Australian by commons. And I'm going to be talking a bit about fair specifically for computational workflows. Presenting this was inspired by a previous fair points. Ask me anything webinar where Carol global from workflow hub spoke specifically about fair workflows. And so the first point I really wanted to make is that workflows are important. The example I've given here is production level workflows that underpin the galaxy or the global galaxy effort to analyze and process SARS COV2 data. And also software with a level of abstraction. So this is an example, best practice workflow that exists in a registry. Things to note, it makes use of a workflow management system. It's a very precise specification of control and data flow of the steps held together by that language. And the composition can be really complex and diverse. Right. So they're very, they can be very, very complicated artifacts. They can also be described in many ways. So today, there are more than 300 different workflow languages that provide that level of abstraction for computational workflows. So an incredibly complicated ecosystem. And they're also numerous. So if you look across registries like doc store and workflow hub or at the big instances of the galaxy platform, you can see that workflows are already being used at scale. Or at least for those that we can actually find. So that that's, that's going to be a big topic for this presentation. There are multiple places that you could find workflows. So there are platforms and community repositories. So the two examples I've given here a galaxy and next flow core. You can obviously go directly to repositories like GitHub. For many researchers, they will naturally go to the published literature to find exemplars of workflows that they might want to implement. And by getting more and more, the, the one solution that most people will actually go to is a search engine. So that means that everything needs to funnel through the most popular option like a search engine. So the more you can do to increase findability of workflows, the more success you'll have. There's also fair notes. It's, it's fair to know that workflows can also be complex time consuming things. So as we saw before, the complexity can be significant. This also means that they're really maintenance heavy. They can be really difficult to find. And often difficult to redeploy. And there's a lot of replication across research groups. And these are really the drivers behind why workflows. It's critical for them to be fair. There's a huge investment by researchers into the into workflows. And so the question is what does fair actually mean for workflows. So the key one is a common workflow description that's actually independent of a platform to workflow languages are given as examples here. But it also means standard machine readable metadata. This metadata should also be common, including for things like tools, input parameters. And they should also be the ability to package that workflow up into a digital object. So it's that concept of persistent identifiers. Now registries will actually make a workflow more fair. And from a user perspective. And this is what I'll be going into in a bit more detail from a user perspective. Making use of a registry makes a lot of sense for these reasons that are listed here on the right. I'll go into them in a bit more detail. The two options at the moment in terms of registries are docks or and workflow hub. And if we come back to this list, we can go we can go through them one by one. The first key element is that they're central their convergence points for communities and communities have domain specific expectations that can drive things like whether that's a particular license or a particular workflow language, for example. They're also integrated. And so what that means is that the registries don't replace development environments, their value adds to those development environments so developers can directly import into these registries. And there's also the option to use applications that developers can install that automate upkeep of those registries. And so it's easier to keep your workflow fair and keep track of versions. They're also standardized. And so this is where that standard metadata comes into play. Not only than a metadata list, but the registry guides a user through making use of metadata. They're also sightable. So they have the ability to generate digital object identifiers and package up workflows that have been created right so all of a sudden a workflow becomes a sightable object that can be put into research publication. And this integrates directly with standards within the community like the citation file format. And so there are examples where the closer you align to standards in documentation, the easier your job becomes when you when you approach a registry. It also means that there's a level of inter-operation. So the example I provided here is some training material where there is an embedded URL that will take you to a deployment location for a workflow. It will import your workflow and present it to you ready to start. And the user of the workflow doesn't know that any of that happened, but it's based on fundamental standards that the registry has, including things like the tool registry service standard. And finally, all of these things together make searching for the workflow much easier. So the fact that there's standard metadata, the fact that it can be a sightable object, the convergence or convergent nature of the registry means that whether you search within the registry or whether you go to a search engine, the workflow becomes more findable. And so we have this concept then of a fair checklist or the things that you might do to make a workflow more fair. And it's things like belonging or joining a community. It's standardizing what you do. It's using a workflow management system, having a focus on reuse, documenting everything that you can and annotating really, really well. And all of these things could happen in isolation. But if you go through the process of registering a workflow, you're already addressing a majority of these requirements. And so for developers, I think this really incentivizes making use of something like a registry. So some acknowledgments. I want to acknowledge Carol Goebel. She gave a great presentation or fair workflows at that previous event and I've included the link here. I also wanted to thank the workflow hub team and also all of the partners of the Australian Biocommons have been included in our projects, like the bring your own data expansion project. And happy to take any questions. I think you have people will be keen on maybe getting a copy of those labels that you just presented. You mean that you mean the last checklist levels. Yeah. Yeah, they were, they were great. I just wanted, I'll say it verbally, not just in the chat, but you know, principles are abstract and difficult to interpret, but I like the way that you've sifted the things into action labels instead. And that's, you know, that's a much more consumable way of dealing with that. So yeah, nice work. Thank you. Anyone else got any questions for Johan? I see Pauline's put a few links in to the charts that may be useful. I feel the right ones. I just did a bit of searching. Great. Johan, there's a question in the chat from Susan asking if workflow hub is available to all users. So anyone can register for workflow hub. I think I think it's most useful for developers or people who want or people who want to reuse workflows. So, yes, is the answer to is the answer to the question. I think it's it's value to end users, I think is the level of integration and interoperability that something like workflow hub has with other platforms. So the example I showed the galaxy workflows where you can have a user click a link and it opens the workflow ready to execute on galaxy is incredibly powerful for putting that in the hands of an end user. The end user can also go to the registry and that they can in effect do the same thing by clicking a button for that on the page for that workflow. Can I ask a question? Actually, go to the one in the chat. Oh yeah, so you're on another one if the workflow hub is only specific to some disciplines. It is not so it is agnostic to domains and disciplines. It's also agnostic to workflow type. So if it's a computational workflow, it can be registered there. Tom, did you want to ask your question? Yeah, I'm curious about I mean if you go to some other disciplines that have workflow like components in the way that they were like astrophysics where they might instead talk about data data pipelines. More. A lot of this is tied very closely. In fact, there are a lot of tools that developed that are tied very closely to instrumentation. And I'm wondering if the same thing happens here and therefore is there maybe another purpose in surfacing these workflows is actually as a kind of evidence of the connection between the use and value of an instrument and the research outcomes. So if there was a link to articles or other research outputs along the way. It's a really good question. I think it reflects the, the two sides of the coin. So on one side you have the workflows that people want to have reused. Right, so they're the ones that you want to be portable and people make use of them to further their own research. And then you have that concept of provenance. That's the other side of the coin where you're wanting to make sure that you retain something because it's been the foundation for research and I think both the uses of registry are equally valuable. It just means that how the end user is making use of the registry is a bit different. Well, can I add another one too, because I think if we can imagine ourselves into a future where software is more visible, including workflows. If I were the author of one of the tools that was a component in a workflow to me being able to see how my tool is used. What are the common patterns? What are the things that are sequenced before and after the use of my tool. These are really useful bits of information for me to perhaps I prioritize bug fixes or optimization in parts of my tool based on consumption. Perhaps I look at altering functionality because they see that people are very, very commonly combining two steps together, one after the other and so on and so forth. So there's so much reuse potential in this stuff. Yeah, that's that's an aspiration of the tools ecosystem in elixir actually to underpin resources like workflow hub with other registries like bio.tools such that you can see here with the components of a workflow. And an end user might say well I don't know very much about workflows but I know this is one of the tools I want to use. So I could filter all of the workflows available just based on just based on a single software tool. And while we're riffing on that, the other way that it might happen in this not necessarily just with workflows is that people go from the data so they see the tools that we use to analyze data linked to those data sets and say oh okay yeah I hadn't been using that or I might be I don't know what that tool is I might go and read about it so that I can see or understand what the researcher was trying to achieve. Yeah, exactly. Any final questions for your hand before we move on. I think we're good Paula if you want to move on to next talk. Yeah, we have one short presentation from them honeymoon. And then we also have time for questions. Sorry about that. I've just lost seconds. Alright I'm going to try and rip through this as quickly as I can. I want to start with a little bit of context, but for those that don't know me, I'm the program manager of the ARDC research software program. And so let and I'm going to talk about the activities that we're doing to help the community make software more visible. The things that we've done in the last year the things that we're in the middle of doing to give you an early heads up. And not so much of what we're planning to do on the near horizon because I've run out of time. But so everything that we do is framed around this thing called a national agenda for research software, which was something that we drafted several years ago now validated with the community and then released in March of 2022. And really we've been tailoring activities to this this piece of work ever since then. It is a piece of work seeking recognition of software as a first class output of research. And under that we really identified three big cultural challenges that drive change towards this. These are a shift over time to more transparent practices in research, enabling broad impact through quality software. And the lack of support for research software infrastructure. We express these in the agenda as a set of goals and actions. And we use the mnemonic see shape and sustain research software to talk about different clusters of related activities. Each of these are working towards a separate goal and collectively they're working towards that recognition of importance and value. So our ideal state for visibility of software is that we would see research software when it's shared published or otherwise made available upon creation, which often isn't. It's cited or identified in reuse and it's captured in data provenance or workflows. So that should be pretty much overlapping with what we've been talking about today already. And within the agenda we broke down the tasks to be conducted by different segments of the overall sector. So this is not something that one organization is going to achieve. This is something that everybody has a part to play in in order to for the change to actually happen. And I'm very glad to see you all here today because forming a community around these concerns is something that wasn't really there before. And it's a really critical part of addressing the change to make software more visible. So turning to how the ARDC software program takes this agenda and turns it into a program of work, we use an abbreviated version of the Center for Open Sciences Strategy for Culture Change, which is much beloved by research infrastructure folk around the world. We consider what infrastructure makes the change possible, what guidance makes it easier, what communities normalize change, and what advocacy work we can do to introduce incentives and drive policy development all towards addressing in this particular case greater visibility of software. So this is our program strategy on a page and we actually run activities against every single cell in this grid. I'm not going to read out this slide nor am I going to tell you every single thing against them, but it's there in the slides if you're interested. So I'm going to focus on the first row, which is just about visibility of software to let you know what we're doing. So developing infrastructure to enable greater visibility is something we've broken down into phases. During the validation phase of the developing the research software agenda, we unearthed some interest in new discovery infrastructure at a national level and also some interest in collaborative code development infrastructure. But we really wanted to be sure that this fully aligns with researcher needs. And as part of that, Paolo mentioned the work that we did last year to develop a survey and we engage Dr. Frankie Stevens to do some analysis of the results of that survey on how researchers find software. And I really encourage you to dig into that if you're either in a support role or if you're in a infrastructure development role, because there's lots of clues in there about the different ways in which researchers prioritise different actions in order to discover software in the first place. It can tell you a lot about some of the nuance that exists in that very diverse community. But as a second step of that work, we've actually just very recently commissioned two members of the US Research and Software Sustainability Institute. So that's Dr. Kartik Ram and James Howison to conduct focus group sessions with specific slices of the sector to identify and prioritise areas of infrastructure development that make sense at a national level. And they're going to deliver that as a report sometime in July. And the phase that would follow that is actually to start to implement some of that infrastructure. Last year we did a massive refresh of our website materials on publishing, depositing, citing and making software citable. If you're in a support role, then you may like to check out this single landing page that we've made for Making Software Visible. And there are individual landing pages for a lot of those topics. All of our material is there to either link to or it's CC by. So please just grab the material, change it whatever way you like. And all we ask is a tiny little attribution would be very nice. Thank you. But that's there to make it easier for you to do your thing. This is a bit awkward and a bit meta. But our involvement in setting up this community is actually part of delivering on normalising practices. I want to say thank you very much to Paula Andrea for her excellent leadership in this, as well as Johan and Vanessa and now looking forward to seeing what Jerry is going to do. To my thinking, community is really actually the heart of change. And so the people who are here in the room at the moment are making the change happen. So thank you for coming along today. And finally, in advocacy work, we've been doing policy analysis for both actually doing a lot more than this. But we've been doing policy analysis for institutions and publishers. And we're in the middle of getting closer to releasing a policy implementation guide. We saw a big gap in the software policy landscape for institutions around Australia. And so we've got a guide with some materials within it to assist the development of policy in that space. We're also involved in two international task forces via the wonderful Research Software Alliance, looking at institutional policies. And the scope of that is a bit broader than visibility. It covers off other topics as well. But also another task force looking at publisher policy standardization around code availability, the work of which we just presented at RDA at the Research Data Alliance plenary very recently, and which we're looking to develop into a framework and to actually work more closely with publishers around standardizing code availability policy. And then finally, we have some activities that don't actually fall under the cluster of software visibility, but which nevertheless actually, you know, you can say enable visibility nonetheless. We are in the business of commissioning a report to take measures of new software produced by Australian institutions under research funding. We don't actually know how much of it is actually created each year, particularly software created for other people to use in research. And that measure will be useful in advocacy work for sure. There is a wonderful series of stories on our website, which I've linked to there, interviewing researchers who code or research software engineers, people creating software for other researchers to use. We look about what the significance of their work, what practices they bring to their work, and what communities they value in doing their work as well. And if you've not had a dig through that series, again, I have to acknowledge the wonderful work of Paula there in getting that up and going. But please have a look. We have a raft of awards, which have already been flagged at the top. So I'll just skip over those. I'm trepidatiously putting in a link to a badging tool that we've developed or are developing with the Netherlands eScience Centre to badge software for fairness. And the target there is for people, particularly who are developing tools for other people to use or putting them up on GitHub. And badging is very common behaviour there as a signifier of the quality of the code that you're putting up. So if you're interested in that, have a look at the Alpha release. You can lodge pull requests or issues on the GitHub site to make changes or get in contact if you're interested in that work. And yeah, I think I might leave it there actually because some of the other stuff has been mentioned already. Thank you. Great. So again, questions for Tom, anyone? And no polling in the chats. You've got the correct link in place. The slides are there with the links. If you wanted to dig into any one of those things, please get in contact with Paula or myself. If you wanted to talk about any one of any single one of those initiatives, whether you're in the policy space or whether you're in support, whether you're developing infrastructure, there's quite a broad range of things that we're dealing with. Or if you want to talk about it without me going at a million miles an hour. Yeah, Tom, just a quick question. And I'm sorry, I realise everyone probably wants to wind this up. Just on the policy side of it, are you seeing institutions starting to build in some guidance into their policies around fair software? No. That is the shortest answer I can give you. Yeah, I was just curious. I can tell you our strategy on the publisher policy front is to find those publishers that have already mentioned the relevance of the fair principles and to say, okay, hey, as a next step, you might want to introduce some reference to the fair principles for research software. So it's an incremental change that we're proposing in that case. But other publishers reference other policy instruments as well. So it's a bit of a complicated landscape. But in terms of institutional policy, no, not much really. Certainly not fair principles for software. Yeah. Okay. No, I was just curious. Obviously it's still emerging. But yeah. No, thank you. I might just add, Susan, the research software alliance has now a task force on institutional research software policies. And there's a few examples, mostly from overseas, and then some of them are not for the whole institution that might be for a faculty. But yes, I'll encourage you to have a look at the list as public. So if you go to the research software or tax sources. Thanks, Paula. That's right. Thank you. Yeah, sorry. Yes, I was only answering for Australia there. So Paul, we're probably good to move on to the next section. Yes. Thanks, Tom. Thanks, John, for great presentations. And now I'll stop the recording so we can ask more questions between ourselves. Thanks everyone for joining the video part of this.