 I mean, you're going to start a pre-recorded version? Let me see if I can... Okay, well, so we had, well, Natalie, thank you. So yes, we're going to have the meeting in Baltimore, and it's the first time this meeting actually has an agenda, and the activities involve more than darting in med bar. So that's quite an amazing first for this project. So we had an excellent working group presentation last week, and I think, I don't know if we expressed our kind of feelings about that. I think it was great. It's really nice to see that working groups framework is working. So what we wanted to do is we basically stole all the bullet points from working groups. That's why we make you make those slides, so life is easier. And I think all we really did is did some rearrangement of this. So this roadmap for, I don't know, maybe two years existed at this HackMD document. After this meeting today, we're going to put it on hub. And so it will live on hub and all the future editing will be happening as a part of that hub page, because I think it's time to let community know what the roadmap is. So we're just going to go through some of the priorities by working groups. So I'll start with UI, then I think Bjorn will continue with backend and so on. So starting with UI, I think for UI group, if you see this, it's basically the same that in your slides, just slightly rearranged. I think there's been enormous amount of UI work in the past year, even more than, and it's, well, I use all, you know, I use EU and Oracle essentially on a daily basis. And I can tell that it's a pleasure to use. So the way we wanted to rearrange this priority is that I think obviously in order to achieve everything, starting with number two, we need to invest in underlying infrastructure. And, you know, UI group has the list of things that they want to do. The history is already very much reworked. It's very nice to work with. I think one of the historical problems with history from the beginning was that it's linear. But in fact, the analysis that we do are rarely linear. So I think we're getting to the point where graph view is becoming very, very, very close. And that's going to be the major, major development for people who do complex analysis with, with, with Galaxy and with Easter in general. And that's, so in, when I was making this, when I was editing this list, I was trying to also make connections to other groups. And I think UI works very tightly with back end, because, you know, these things are impossible without each other. So the graph view, the new scroller for large histories, it's, if you work with, with histories with a lot of data sets, with a lot of collections, it's also nice to be able to have some kind of a checkpoints in the history that you can quickly go to. Another thing I don't know if you guys in UI group thought about this a lot. We still have this for obvious reasons, I guess, difference between the individual data sets work. I compared with collections. For example, if you look at the individual data set, you have this button allows you to see the inputs. So the data set, which gave you that data set and also the subsequent what came out of this data set, it, we need to start thinking about doing the similar things for collections, because that's impossible for collections right now. But just if you, if you look at the collection without actually going into collection to be able to know what created it and what was created out of it without diving deep in the data set. So this is kind of a general making sure that collections behave somewhat like data sets in these kinds of situations. That's very, very important. And it's in particular for, for debugging workflows, for example. So activity bar, I don't know how many have you've seen that that I think streamlines the use of Galaxy very much. And this in combination, if we going to have notification framework would be wonderful. I think my personally, for me, one of the kind of a key uses for identification framework would be to highlight new features. If we can, I guess, if I understanding notification framework correctly, because notification framework will also be, you know, will also be able to give you things like, you know, your scratch history is about to expire and things like that. But do I understand this correctly? Is this something that would allow us also to, you know, these are new features here? Is that how it will, will that allow us to do this or something else? Yeah, sure. I mean, anything the admins would want to send a notification about you could say like, here's, you should check out the workflow interface now or something like that. Because still thinking about the problems that we have, the biggest problem is as usual, we don't let people know enough what we have. There are all sorts of hidden features that are amazing, just people don't know about them. So that's, so in terms of visualizations, I brought the IGV on top, because we need to have full feature genome browser finally. We have, what's the, sorry, escapes my memory. What's the name of the genome browser that we have there right now? Prexter? No, no, no. Prexter is long dead. I mean, the one from Berkeley. Jay Browns? Yes, Jay Browns, yes. So we have that, but it's not, it kind of behaves in probably suboptimal way. So the IGV.js would be would be fantastic. Well, the data set view, decluttering the actual, you know, the data set view and allowing to do things from that tap interface in the middle pane. I don't know if, do you guys in UI group, do you have a discussion with backend about this new things, how we would go about scratch history, how to, how to create one, how we'll be able to do history archival. For example, on dot org, once we finish all this acrobatics with irons, it will be able to archive histories on someone. But I don't know if we, is there a plan in UI group for the interface aspects of that? We haven't discussed specifically the scratch history. We did talk a bit about how the actually, I actually don't remember if this happened in the UI group or the backend group since so many of us attend both. But there's a lot of communication there about the archival history and how that should work. You know, we presented that we were not going to have the full freezing this next cycle, but we'll work on it down their own. Scratch histories in particular, I don't think we've discussed a good UX for, but we should. Yeah, I don't know if that's, you know, I guess we just need to come up with live, or perhaps we should talk one of the, one of the next UI meetings about that. So in terms of UI simplification, this is something that came up yesterday during our PI call. So the idea there is to enable in some cases, so in the cases of analysis for which we have good workflows. So I think this relies on a lot of infrastructure, which workflow the two group will also be doing to perhaps think about how we can allow really naive users to simply, so suppose we have a subset of high quality, really tested workflows. We don't have that many of these yet, we have some for VGP, for example, we have some for code, we also have some great workflows in GTN world, which we can use for that. What we were thinking is that let's pick one workflow and see if we can make a prototype of the interface where you basically choose workflow, drag files, click a button, and it just triggers this analysis and gives you outputs without without immersing you into any complicated details. So this will only work for for really well curated workflows. It will only work in the cases where we, well at least user can guarantee that the data is good. But there are a few user cases where this was help us to bring people in Galaxy without giving them kind of extended lectures on how to use it. Once they see how this works, I'm sure they will want to learn how to create workflows themselves and how to use Galaxy in complicated ways. But maybe for some workflows, we want to try to do that. I don't know if it's possible in this cycle, but we can talk about this in the UI UX group. And personally, my priority for the next, I don't know if it's possible before GCC, but I'll try is to write a paper on new UI features. And by new, I mean the past six years, maybe we have never published, for example, collections, we have never published any logic behind the rule builder. And this all needs to be popularized because I frankly don't know any other sort of a GUI driven platforms that allow as much flexibility as we do. So are we missing anything from the UI UX? And also I would like to ask, if anybody wants to speak up people who are not directly involved in the working groups, perhaps the community at large, are there things that are not here but are really critical? Looks like we're doing a great job in capturing everything we need. Okay, I was talking about UI for five minutes. It doesn't do its justice. UI has went through fabulous transformation. And so let's keep on it. Bjorn, explain the back end. Can you scroll down a bit? Okay. Yeah, so similar what Anton said. So it's very impressive to see what we did in the last six months, especially with all the underlying infrastructure work that also I guess enabled a lot of what the UX working group has then taken over and enabled them. And we would like to encourage to do that also in the next period. So work on the underlying infrastructure, moving the face fast API port forward. We think that addressing the limitation of the task framework has a high priority since we need to get that probably deployed on orc because there are many features that kind of depend on the task execution framework now. And if we want to have users on orc and AU also using that, I guess we need to streamline that and identify and fix the missing things to deploy salary or whatever task execution framework we want to use. And the same goes then for SQL, I can be and the fast API work, especially for workflow APIs that might be interesting and was requested also then by the workflow working group, etc. So yeah, I think the progress was just tremendous and it feels from, I mean, from the outset, it feels that we really accelerating in our development and the features that we're adding. So yeah, thanks a lot for that and feel encouraged to do that in the next months as well. The other thing that we identified and that we hope that the backend team working group can help us is we have a real, yeah, a capacity problem with admins currently and deploying and keeping our infrastructure up and running. I mean, that's already, we have this problem since many years, but it got more emerging, I think, because of things happening. And one thing to address a capacity problem is either to educate more admins and hire more admins and we are trying to do that currently. We will run a new admin workshop and some of the other thing is that we maybe try to lower the barrier to enter and get rid of quirks that our admins are currently using to keep the system up and running, but that maybe should move into the backend or where we should just add better documentation. All of these stuff really help to build admin capacity and we would like to ask the backend group to really assist the system working group even more and we appreciate that you already did in the last cycle, but keep that up and going, please, and help us fixing this capacity problem in the next months or years. Specifically, and we have talked about that in other meetings, the IDC, the Intercollective Data Commission for our reference data, the backend team has done great work in the last cycle for that, but we are still not there, so we need to get that done. I think it would be cool if we have that for GCC when we are in Australia. They are still POSAR hardening. POSAR is for many deployments an integral part by now, especially for the Australians. So we consider this as an important piece of our infrastructure. And the other point is what we call these meta scheduling. So we have agreed to use TPV that is developed by Newell and the Australian team so that we can converge against that system so that we can, at least again, building capacity in the sense of we share all the job definitions and the allocations of memory and CPUs and so on. Yeah, if you can help there, that would be phenomenal. Also with a new toolshed, we are pretty excited and we would like to get that deployed, but I guess we need to have backend help or the backend team helping the system team to do that. Yeah, and then streamlining this thing. André, can you go up a bit? Thanks. The next big item is the user-based object stores. Yeah, we have that since many cycles on the roadmap. They are two very promising code requests by the backend group that are close to be merged, that goes a long way into this direction of having the user-based object store. And we think that should be a priority of the backend working group for the next cycle as well to also enable then something like the scratch histories that Anton talked about where hopefully the front-end and working group can pick it up and design and implement a nice user interface on top of that. Federated data local computing on commercial clouds is requested by a few brands. Yeah, so that is also on the to-do list for the next cycle. I think Jeremy will talk about that later a bit. Yeah, and the merge and hardening of the toolshed replacement. So we can finally tick that box off. And yeah, we really look forward to this work and also then learn more about that as we go. Last but not least, we had the question kind of what is actually needed to label ITs as stable so that we can actually distribute them with a toolshed. So what is missing? How can and can we fix that so that we can also make a very nice and close story about ITs, how we distribute them, how we advertise them. And with the new work of the front-end working group that we see also with ITs, I think that's a very nice story. And if we can close it by finally labeling them as stable, yeah, that would be nice. And it would at least be nice to know what is missing and how much time that would take to close that off. Yeah, I mean with that, all what I can say is it's really impressive. I would really like to understand what happened in the last year that we accelerated so much, added so much new features, particular with all these, maybe the work that are not put into features like the fast API work that enables now and typescript-generated clients and so on. We would encourage you to talk about that more or maybe write a blog post about that more. I think these are important milestones that we have reached and that we should really communicate to a broader community and you can all be very proud of that. Yeah, is there anything else from you that you would like to add to the back-end working group roadmap on the community side? Any questions? Nothing? Okay, people will be able to do PRs against Hub page if they will. Can you scroll down a bit? Should I do testing and hardening as well or? Yes. Yeah, testing and hardening, so the working group. So what we have seen is, or let's put it that way, the release testing and the support that you give to the community I think is very, very valuable and I mean follow from the outside the release testing procedure and talking to a few people that have been in these groups is I think a big success. So it's good that we have this release testing. It's also I think very good how it's organized and it brings the project further. So we really encourage you to continue with that and to support other working groups in adding more tests and better tests. So I think that's a crucial part and probably also a crucial part that takes us a little bit further than other projects and that we have so much testing. What we would like to see maybe is really expanding testing tutorials a bit more so that new contributors have it easier to understand it. But we also appreciate that there's a lot of different testing frameworks currently that makes it hard. But I think as I mean maybe we drop some over time and then we should really keep the tutorials updated and make the onboarding procedure to write tests easier. But just seeing outside contributions from really community members that actually adds cool tests is really encouraging. And the same goes for ongoing work and testing infrastructure. So please keep that going. Testing is and will be important for the project. And I think the rest is actually from your slides so and yeah we like it. The same as for the backend group please talk and write more about the testing efforts in Galaxy. This is also a hidden treasure where we should talk more about that because there is a lot of work going into this and it should be appreciated and it should be also put into our outreach efforts. Yeah thanks a lot testing and hardening group. Any things to add? Okay next one. Okay tools and workflows. So in the past well it's probably already more than a year there was one effort to which I was paying particular attention that's VGP. It's interesting because it's kind of a mega workflow project. It's a situation where you cannot have one workflow. You have to have multiple workflows because you know you start with some workflows depending on what kind of input data you have. You also parameterize subsequent workflows from the for example QC matrix which some of the workflows generate and so on. So it's a very complicated thing and it raised a lot of issues which I think workflow group is addressing head on and one of these issues was sub workflow maintenance because for example in this case again going back to EGP it's 10 workflows. They kind of exist in five different groups and many workflows within each group each group sometimes have two three workflows. They all have common pieces and all these common pieces are packaged as sub workflows but when you're actually doing the polishing development and debugging of this you're kind of not sure if you change here what happens there and how it's all linked together. So the simplifying workflow maintenance will go a very long way because I think we will be able to simplify a lot of things dramatically. It's just it's not always clear how the different snapshots, the versions of workflows propagate but I think all these points address that so this is very important. I think this would this would grow significantly audience of people who will take advantage of that. So in terms of a second execution of workflows and two tests so does that that's probably a question directly to Mario. Does that relate to the the fact that we cannot test workflows that unavoidably have large test data sets? Yes but I think it's like yeah multiple multiple different things we can address with this. I do breaking up things that actually we can generate. Because this is again I think VGP raised that issue that we want these workflows to be in all the main repositories. I mean Dockstore and Northclough Hub. We want them to be up to the IWC standard which is actually high bar but just the nature of assembly is such that you cannot have small test data sets so some of the tests even if they don't make any sense even if they just check the tools work still requires substantial compute and that kind of complicates life of a workflow developers because they want to satisfy IWC but they not always it's not always possible. I guess Mario is typing that it's possible to generate small test data for assembly. Let's talk about that offline yeah. So again it's interesting that the job caching framework so we have an interesting situation which is happening on EU at this point. It will probably be happening on Oregon and Australian instances soon. So there are people and we love these people obviously who are crazy enough to do training sessions for assembly. I mean I'm sure most of the people on the school understand what assembly is but there is a workshop that is going on on the EU right now where they're assembling well essentially human size well it's not quite human size it's about half of the human size but it's a large vertebrate genome and they're doing this in a class with multiple people doing it. So far the interesting result and the result of that is that we don't see any complaints. I think Bjorn is probably monitoring what's happening but it looks like it's working but it would work probably so much better if we had job caching enabled because basically all these people download the same stuff they generate the same intermediate data sets and they're very large and so that would also that's key. In terms of JavaScript expressions I actually I'm really curious to see how this would look like but that obviously will simplify life of workflow developers because they will be able to do things by typing rather than connecting and actually I don't know what IWUC thinks about the website for IWUC workflow. Are you guys thinking of some kind of an automated way of generating? I don't know using the maybe bio conductor version of bio conductor lingo how do they call that snippets or there is a word that they use but what's I actually want to ask IWUC how do you see that website development? Actually Myers might be having a case of bad internet right now because right now we're doing this manually but we again we have some wonderful workflows and we want to make sure that we can generate colorful you know documentation pages which are maintainable because so far I was doing this thing of writing it myself. I like doing this but it's ultimately unmaintainable and in the year it doesn't make any sense and I would like to have a better way of doing that. Yes vignette exactly. Thank you Jen. Yeah the workflow development these are all obvious things if you if you if you develop workflows for the editor you know them and versioning included. In terms of high importance tools and workflows I don't know if that's the sort of a final list I think it should be I think the real approach here should be sourcing community and also going through GTN picking workflows from there and making them into production because GTN is full of great great great great workflows I don't know if all of them can be used in production but probably with minimal modification. So the standalone graph you it also relates to number five website for idables you work close it would be nice to put it there as well. So yeah everything else is more or less verbatim from idable you see slides but what I want to emphasize here is that idable you see is the newest working group and I mean the workflows have become first class citizens sort of a relatively recently in galaxy in the sense I mean they've always been on galaxy but in the sense that we are now starting to push them as complete analysis solutions so it's very important to our growth because in addition to all the functionality in the end people need to understand that you can do these complex things with galaxy and there are stable versioned curated workflows that allow you to do that. So any other comments on workflows particular from people who are normally outside of our meetings some yes a few if you're shy enough you can always do PRs but systems Bjorn you want to go over that or do you want me to do it? I can if no one else wants yeah as I said we have a capacity problem with our admins and then can you go a little bit but nevertheless I mean our the first and primary goal is to keep the the big instances up and running and to support our community to to spin up more galaxy instances nationwide institutional wide and so on so that's that's for sure but for example the systems working group I mean as Anton said the workflows were important and one strategic goal is to get these vgp workflows at least on the three big galaxy instances and we know more and we know that a few national instances are also interested in so deploying that and sharing again the the resource allocations that we figure out as we go this is one important milestone. The other one for ORC is to hardening and and the deployment of the iROAD server and hopefully I mean with the next release then in summer it gets also easier to test that with the object stone work that is pending and will be merged yeah and the other thing is that the systems working group will or should collect all these pain points or hacks or however you want to call it so the work arounds that we keep around for certain things that can be improved in galaxy and I think we should make such a list convert them into issues and and really prioritize that so that over time the systems working group needs to yeah streamline can streamline their deployments and with that yeah gain capacity potential candidates for that is for example the toolbox handling currently which is a little bit still a little bit awkward I think data managers that that loops back to IDC but also better error reporting might be very helpful for admins and also the support persons yeah and then yeah handling of reference data that also goes back to IDC in the slides we actually had this nice figure I think from Nate we have more or less just very little downtime these days and I think that that speaks for the project as a whole right both the back end systems working group but the entire team that the services that we actually create and actually run on our infrastructure are more stable than ever I would say with more users than ever so that's actually I think a very good thing and systems working group thanks a lot for that and I think that image is is very telling for our community right and our services that we provide and we appreciate all the effort that goes in but we also recognize that there is yeah a capacity problem and we would like to to fix that and yeah that's what we will work on as as the galaxy board as much as we can questions or anything that we forgot for the systems working group anything that we should add that is priority what you think should be added you know one thing we should probably have on road map is to actual steps for what it would take to bring the three big instances in complete sync so that sort of red bar here about the U.S. problem is that we also frequently lack in having the latest versions of tools which are already in IUC so I personally would like to just have a carbon copy of EU toolkit ensuring that the versions are synced as well I I don't completely understand what keeps us away from that problem needs question it's a it's a rhetorical question that you have to answer now we'll talk about it later there's a question yeah Carol from from Canada from Quebec yes I'm new to your meetings so welcome very informative I beyond like I exchanged my email with beyond so I was curious like about the resources actually you mentioned the limits and resources I don't so what's what do what kind of resources do you have on each of the use the use galaxy like the dot org like what kind of cluster do you have in back so as like for the audience here I jumped in in the in the program like I was in gin up and we were instant having several instances of gin up of a galaxy within our infrastructure in Canada and as you probably know David more which which was with us but he left a couple of months ago and I I was leading the gin up as a but now we're moving the project to have on the long-term and use galaxy like another public server but I need to make a case I need to make a case and I would probably bug you with some some some stats there but one one information I would I need to like what kind of resource do you have in in the back you see you are lacking some some some resources there but what is it what is it like well there are three instances obviously have different resources so in us we rely on on infrastructure which was provided but something that was called exceed before it's a national NSF funded network of supercomputing center but most of our compute comes from Texas advanced supercomputing center but we also use for example JetStream cloud which has been taken in DNA and in in in EU it's different that's the German bioinformatics network plus there are European country specific compute centers in Australia it's they have their separate scientific cloud so so but in essence it's all public it's all publicly funded clouds that yeah but if you're asking from the standpoint is that's enough to serve Canadian users then the answer is yes well more I was more curious about what's the size of these resources that we we are going to have like an allocation for our projects and like for the first phase so actually we're waiting news for that so but I'm curious to see the size like what's the figure of the like when you have a US galaxy running what kind of size are we looking at well there is this nudely figure from Nate the main sysadmin of the org which we can send you it kind of explains all the resources I'll do this after the call oh yeah yeah but it's very nice meeting you so we're not that far are you located in here in Quebec or in Ontario I'm in Quebec in Sherbrooke so that's great so it's a chance to practice kibikwa so perhaps that would be fantastic so let's I'll email you after the call so that's just because we're in the same time zone so it's easy to ask questions but I can I can provide you with enumeration of what we have okay good thank you so great thank you for asking any other questions so goats you know the this is uh it's one of the most critical things to the functioning of the entire project and so there are it's a it's a great success story because you know for example GTN as a poster child I mean I think every time every time you want to highlight galaxy you point people to GTN and one of the problems with GTN right now is that we need to seriously think about next funding period and because this is kind of a geographically so GTN the people who lead GTN are actually in Europe this is Sasuke and Helena so we need to think about how to help them to obtain that funding but we can so we're we're thinking about this it's also part of the exercise that our executive board is is is doing right now so yes keeping GTN keeping our user support I mean obviously people like Jen who does support for the for the dot org is under immense load and same thing for you same thing for for Australia uh and it's not necessarily only goats go to uh to grow the galaxy event horizon it's in general we need to go to more conferences and we need to go to conferences where we outside of our comfort zone for example in us there's there's a number of microbiology conferences galaxy has some spectacular tools tutorials GTN tutorials and workflows for doing very different kinds of microbial you know anything from the wastewater monitoring to you know variant calling in in all sorts of viruses but I don't think these audiences know and it requires a sustained effort because when you go to a new conferences first time you never get you know maybe you'll get a poster name you want so that requires sustained effort we need to identify people who can do that and help them go to these conferences and that's we should really improve that in the next year um any comments about uh yes and at least on the on the us site hopefully we'll have a new communication specialist which will increase our uh activity in informing people I think you and you are doing great job already in anime so um if um anything else anything I'm forgetting about GTN but at least from my standpoint funding is go it's funding GTN is for me is the top priority okay um so next we have two things which are very important for branching galaxy into um into human data and in in cancer genomics as well so Jeremy would you like to start with ITCR it's from the spell here yeah I'd be happy to Anton so as Anton noted and maybe I can try to make this clear that both what Ennis is going to talk about next in terms of human genetics in anvil and ITCR and cancer applications are in some ways this bridge to new communities think of us as power users potentially so analogous to BGP or something like that where we have scientific goals and I'll share some of those and then based on the scientific goals we have things that galaxy could do better that would enable us to achieve these goals and I view these as synergistic because the goals drive the galaxy development and when the galaxy development happens and we can use them to accomplish our goals or work towards our goals better in the cancer space in this instance then it's a virtuous cycle and it's it's really powerful and that's how I present it when I talk to the cancer community and I think it's a really nice story about why things like galaxy are needed which believe it or not are not it's a discussion I constantly have with individuals about how much infrastructure you need and what type of infrastructure needs to be put in place to accomplish things so scientifically from a cancer perspective the things that our group is pushing on the things that our collaborators are pushing on the things that I talk about when I talk about galaxy and the cancer space are multimodal and spatial analyses of molecular data sets so we're still talking about DNA and RNA and protein not so much about anatomical imaging such as MRIs or CT scans or something like that right now but these molecular data sets increasingly have a spatial component too and you saw some individuals from our group share some of this at the last GCC and I think I have a slot in an upcoming galaxy community call to go into this in more detail so I'll show you some beautiful pictures that we have a single cell data where you can see tumor cells right next to immune cells for instance but we want to be able to process all of this quantitatively so that's our goal sometimes these are simple workflows sometimes these are complex workflows machine learning is a big part of cancer data analyses at this point the ability to connect what we're seeing at the molecular level back to the patient level is really important and two really simple examples I can give you of things that we've done over the past couple of months is we've used RNA seek data to predict response to therapy so you get patients tumor RNA seek data or gene expression data you say will this patient respond to this therapy or not and we build a machine learning model for each of the drugs that we have available to us and we try to identify the drug that's most likely to be effective and a second example is a little more technical but it's still really important oftentimes when you look at a tumor from a molecular perspective you care about how quickly it's proliferating or growing because that tells you a lot about how aggressively you have to treat a patient and to do that you can actually get down to the level of individual cells now and say is this cell proliferating or not based on a protein marker and we can use machine learning to look at the image of that cell and say yes or no and then finally Anton hinted at this before the idea of trying to analyze these large cancer datasets which are oftentimes located on these commercial clouds because that's where the National Cancer Institute is asking everyone to put their cancer data and you can't easily take the data off these clouds for two reasons number one is this gigantic and it would be really expensive and time-consuming to try to take these terabytes of data and move it off but secondly oftentimes it's protected as well which means you've got to be able to analyze it on the cloud because it's not authorized to be moved off the cloud so with those scientific goals in mind I'd say that over the next 12 months 2023 here that these are the things that if we were able to make advances in Galaxy would make the most impact in the cancer space. Bjorn and Anton talked a little bit about this along the way the idea of simpler user interfaces and activities. Galaxy is a fantastic tool everyone is excited when I first talked to them about it but it's hard sometimes to pull them in and say here's how you run a tool in 30 seconds or a minute rather than here sit down with this tutorial and then after you run this tutorial then you can start to run tools so a simplified user interface the concept of activities and quickly guiding people to a workflow that they can run in a couple quicks by dragging their data into their web browser would be fantastic. We use a lot of tabular data in Galaxy and Galaxy's support for tabular data is challenging at times especially with a large number of columns and especially when you want to edit that text a little bit so I guess I would make this is more I think smaller improvements that could be bitten off pretty easily but the idea of better tabular data set support I'm happy to share some concrete examples where we struggle often times it's a large number of columns that we struggle with but the inline text editing is huge to be honest the ability to change a couple small things in a file whether it's the name of a column or add a header or something like that would be really valuable and I know we can do this with a text editing visualization but it's not the most intuitive to get to that place and then get back so just some small cosmetic fixes would go a long ways to working better with tabular data sets in Galaxy. Bigger asks data local processing so I hinted at this before the idea that if you sit on usegalaxy.org for instance that we can run analyses on AWS and GCP and that data stays on AWS and GCP all the way through. If I understand correctly what this requires is setting up a Pulsar client on one of these commercial clouds and somehow tackling the billing questions that come along with it and then user-based object storage so that you can put everything back in the cloud rather than having it route back to use galaxy.org for instance. We're working on and we certainly would love to work with the community on simpler machine learning tool suites. We have some ideas here we talked a little bit about Ludwig I'm still really excited about this in particular where you can write some small YAML files to create really complex machine learning models and building up a model repository is really important in Galaxy as well so people don't have to start from scratch it's totally analogous to workflows in that sense where you have this component that you could use maybe from a galaxy data library that says here you want to analyze your image data here's a machine learning model that's available and then workflows examples tutorials this hooks directly into GTN that Anton talked so nicely about before about a couple key aspects of challenging analyses that we're working on right now that would be really valuable to the cancer community multiplex tissue imaging I think we have our first version of a GTN tutorial up now and published and then several machine learning tools have tutorials have been published as well so I think the latter two in particular in our play and maybe the first four for instance would potentially have interest for the galaxy developer community and we have just a couple minutes left so I should quickly say I'm happy to discuss offline take questions but let's turn it over to Anna's for human genetics and anvil yeah thanks so I'll uh I'll rush through this so we uh respectable of uh people's schedules um but it goes along the lines of what uh Jeremy said that um the sort of view of galaxy on anvil is largely the consumer of galaxy as it comes um it does try to you know make a case for galaxy in this human genetic space um so predominantly the ability to operate on protected and private data uh to be used as a test platform and an integration platform for the uh growing and popular uh for GHAPIs um and to support large-scale analyses that people may not be able to do on public servers due to quotas um and so some of the things that would sort of help us um along the accomplish those goals is to better analyze how galaxy is used uh so we did that through some initial passes at cost modeling because cost is a major concern for these users running these queries on the large use galaxy databases is slow and time-consuming especially being done regularly so having a read-optimized copy of the use galaxy database that gets updated every month or so would be great to keep users up to you know up to date with most recent data um all the tools on anvil run in containers which by containers is great but we do have substantial sort of failure rate on the automated test um so seeing those be more consistent would would help um and then translating that to the end to work flows um similar to what Jeremy said about being able to operate on data that originates in a bucket uh and returns to a bucket without ever really uh touching the shared or no need for a shared galaxy file system um would be great help on how to set this up as Bjorn said and we spent the last six months trying to get some of the latest changes on galaxy deployed on anvil um for a variety of reasons and so some of these things well developed if they don't come with documentation is almost useless um this is looking at further forward is optimizing startup it still takes close to 10 minutes to get galaxy on anvil running if we could have something that is instant nobody wants to wait for 10 minutes right so if we had the ability to uh just reduce the number of dependencies uh as the current server client model works or ultimately if we could serve the client in a static fashion when you get a semi-functional instance of galaxy that then is backfilled um as the server comes up would be would be great and again um sort of continuing to play with the GA4GH um crowd to support more of the APIs is that's one of those things that TNIH is particularly pushing for strongly and and working with the some other clouds from cancer to uh lung and things like that so anyway we're out of time so um I would I would say that we're already doing pretty well doing some job in implementing GA4GH uh I mean GA4GH APIs and I think we're probably one of the few people who are doing this so it's but yes we need to do more okay so um I guess what we'll do we'll sit in it for another week and then we'll push it to hub and then please uh submit PRs complain update and ask questions um it's yeah it's already one hour so any other questions okay well if not I really really really want to thank all the working groups again it's it's been after we established this what two years ago or three years ago this this this has been uh great so we are really uh we really appreciate what's happening all right if nothing else then I will close that and uh there is a recording so if you want to hear this again you can if not see you at the next community call in a few weeks bye everybody bye everyone