 So the goal of this meeting is to look at Q1 priorities and although we already did this and just make sure that they're set and This is going to be the day zero for the Q1 So admin guys, are you ready to start? Yeah, I think I can speak. I Just one slide I can share the screen About that John, did you allow the screen sharing? So everyone should be able to share the screen? Yeah, I think I can. Okay, can you see it? Yes. Yes, okay. So we have prepared The project board, so it's available on the Github page here, the project number 16 where we are tracking all our Activities so our idea for the next four months is to work in on high roads to verify high roads adoption feasibility To improve development of the Pulsar network Expand GTN test automation and determine suitability of REVG for reference data management and Deploy existing tools to the CMFS network and use that Repository production so our milestones for that for Q1 or We would like to Have the use galaxy dust star service able to to switch to to load tools from the CMFS network I would like to run performance test on high roads and compare That times with with the the storage that use galaxy dot org is using now and if the test is a success It is to deploy adults To main and use for new data We'll be prepared the storage roadmap and Again Yes, that GTN automation test suite will be used also by the Galaxy so and I would like also to prepare a report on the issues and anomalies that we are collecting executing common workflows against production Pulsar site More or less is the idea that we are for the Q1 period Any question I have one question So when we're gonna switch all three galaxies to see the MFS to pull the tools We need to at some point review the tool set because actually when you look at tools at all instances There's a number of tools that need to be purged or at least moved to some disabled should be hidden. That's what I mean so I That should be one of the goals for one of the groups probably for the tools group Or maybe for scientific applications a group is to review actually tools that are currently in that common set I think we can collaborate together Thanks Jamal. I think it's Also a very good idea to actually put also something like Determine sustainable suitability of refugee into the agenda and to spend some time to evaluate that My only hint is that the D The back end group has also on their agenda a topic to Discuss more broadly object store and and storage As part of their back-end work So I would really encourage the admin group to team up with the back-end group to make a joint meeting And discuss storage and object stores together To follow up on that I will I also have a meeting And the end of month this month or maybe early February loop Loop the back end people who are interested in storage and remote storage And then I'll I'll CC the admin team on that one minute So any Objections to Feasibility of these milestones If not let's move on All right, so the back-end group is next Our project board is 11 So we have three sort of main priorities There's many more details on the project board, but these are the three main things So we want to modernize the galaxy API We've looked at fast API we've already merged this galaxy can start Under fast API now what this allows us so it's it's an async framework. It's a modern framework It's a framework at all because we didn't really use a framework before It gives us async routes and it gives us web sockets So two modern technologies where we can use to improve Things that should happen Quickly events so the Thing that we would need this for first would be history updates Job updates Things that should happen rapidly So that's what they're good is good for it's also using typing And it has a nice automated documentation generation two things that What typing we haven't done before an automated documentation always great because our documentation especially for the API Is essentially just look at biobland which is not the good strategy. I think Not that biobland is bad but Galaxy should have better documentation of its API And together with the async aspect is we need to get Some legacy patterns and how we use SQL like me our database layer We need to rework those patterns so that we can use 1.4 which introduced async and compatibility So the milestones for that part are that galaxy starts on the unicorn you become instead of paste you whiskey Optionally in twenty one or five and then we make the switch in twenty one or nine We will convert a few routes fully to fast API so Fast API can already serve the old routes, but we want to make them better And document them fully. So that's ongoing We want a web socket subscription endpoints So you can just get like in real-time updates as they happen on the server And one of the first things we need for Truly async routes is that we can do async queries with SQL alchemy So the next big priority is enhancement to how my galaxy manages data So that includes multiple quota. So if storage can come from multiple places, you need to track How much space can be used where can the job go and so on And so the kinds of storage that we're thinking about here are mostly scratch storage Take storage And so we build the API To summarize the usage and work together with the UI user Group to have a nice Visual representation of that We will enhance the Galaxy files plug-in so that you can import and export history There will be a requirement for the end of the project Two things that didn't exactly make it to like something that we will Accomplish in Q1, but that still on the roadmap is Import data from user object stores and remote object stores That Galaxy can deal with data that it never imported never generated metadata for That's required for ITCR, but that's a big project and for that we first need the quota in place But we will have regular meetings to discuss how we want to implement this With the people that are going to work on that So the milestones are that you can configure multiple storage quotas that can be displayed That sharing will be disabled if data is somewhere where It is in a private Location for storage We will have history import and export to file plugins And we will have a plan for how we're going to move forward with user object stores and remote data And then final priorities performance So that's going to be in collaboration with the testing and deployment teams So we want to do performance testing that is closer to real big servers And we want to optimize how the job throughput and the performance performance And we want to optimize how the job throughput and one of the limiting factors here is the state change So the two things here are a CI framework That we run with every pull request and that compares before and after And sort of finds what is regressing or did we make any nice improvements So that we know that we're moving in the right direction in the same way if we have Like big changes but we're uncertain of like the impact that we have a standard way to look at this We're out of time And then yeah for the second part we just link the jobs with the data set so that you just look at the job state directly instead of the workarounds we're doing now That's it Can I ask every group you're showing these slides can you put them in the folder on the Google Drive where you're a charger No questions cancer informatics man Oh folks let me just share my screen here special hello to my European colleagues let's see Okay, so this is the overall roadmap for cancer informatics ultimately we want to have a sort of flavor of galaxy portal for these analyses living at Cancer Informatics Cancer.UseGalaxy.org so the initial push will be towards that end so we want to have a GVL based galaxy instance up that can use Google login that will eventually be tied to a fence instance Which is yeah Gen 3 IDP We want to install cyclic immunofluorescent tools and workflows which is a little more complex not complex but involved in it sounds since it's not just installing tool shed tools per se but some various custom tools that live in various places and ad hoc hodgepodge things so Smoothing that as part of that goal. In addition, we need to be able to pull from disparate places that are these data stores. Ultimately these are humongous files like I don't know 80 gigabyte multi layer tips that need to be pulled in analyzed and then perpetuated somewhere the federated data promise And then from there gets a little more nebulous in terms of what we're going to do since planning super far ahead is a bit tricky but once we have an understanding of how to interact with these services will wrap that into a data browser to have a more user friendly experience than SSH and pole get on the local file system import through galaxy sort of rigmarole or something like that. Then we were also very interested in interactive tools on this instance for it's very visual process a lot of pictures and identifying regions and multi colored magenta cell slides and things like that so being able to have this interactivity is key. And then then from there I suppose once we have a stable instance we're interested in looking at other sorts of tools and data sources and analyses that community folks might want to perform so that's more in the long term scope of our roadmap. Yeah, and other canonical sources of data and CI CRDC so on and so forth. That's about the high and low of it. On your, you'd have project page, your Q one tasks are you planning to assign them to specific. So admin group did this quite yes. We are just have not gotten around to it, unfortunately. No, you probably want to get around it fairly soon, not before the end of Q one. Certainly, probably before the end of the week. So, the list of stuff that we paired it down to I think for the first quarter here. The top thing is to get it is enabled and functional in GBL and Kubernetes based appointments of galaxy. And as part of that project will end up writing up a fair amount of documentation and probably doing some refinement on how it is work. And some of the little annoyances with using them currently. Another another goal here is to be able to pip install galaxy for quarter one that will most likely mean just different selling the application. And not the not having a solution for the client just yet. But maybe for for q2 will be able to come up with a nice install method for the client. The for GVL we'd like to be able to switch the data set store to Swift, whereas three back storage this gives us the for the groundwork for pulsar to direct stage to and from the object storage systems without galaxies the intermediary. And then, finally, in order to have more defined installable galaxy, such as with different stall galaxy, we need a more defined galaxy version. And so we need to come up with a procedure for creating point releases so, you know, 2021 one dot one dot two dot three. And an easy system for, you know, the people who are going to be in charge of creating those two to create them and have all the packages built and pushed out. And that is it for deployment. So the purely stylistic things here so the link there's no link to this project from your charter documents as far as I can tell. And also can you stick it on the community hub page. So it's that link that Dave shared so it can be easily jumped to. You know, like with cancer informatics you don't really assign things to anybody. So that probably. Yeah we're going to so we tried to get a meeting together. You know from the notice on Tuesday but weren't able to find times for everyone in the in the group by today. So, we will do that within the next week. So basically three things add project to the Google Doc added to the hub page and assigned tasks. Okay. The question for native this time. Please. So, regarding the last point in the list. So the point releases is the idea to basically replace the way where we didn't basically keep the branch and suggest to admin to keep the branch of data moving to tags, or is this more connected with the people installable galaxy and so by by packages. I think if you're going to, if you're going to use a clone it would probably still make sense to just use the release branch, especially because we're, you know that's that's gotten higher and higher quality over time so I don't think we need to worry too much about people not using an exact point release on there. But certainly if you want to be very deterministic in in your galaxy and its version. Then we will create get tags for it and you can use those. So it's kind of connected with the pipe by installable galaxy. Yeah yeah because the goal is so you know from these you can also build system packages if you need to have a galaxy installed on your cluster in order to to run metadata and that sort of stuff. So, for that. We need, we need actual versions and stuff. Thank you. Yep. Okay. That means human genetics. Hello, sorry. This is basically the same one as last time. We haven't assigned people like my name but basically every person or almost every person in the group is in two other groups so we're going to have a lot of collaborating with other groups. So, for example, one, I mean, yeah, the envelope tool set, we're going to do with the tools group is just getting a list of tools that are verified to be working and then setting up the testing infrastructure to make sure that they stay working. The integration is going to be with back end groups, mostly the and volafas plugin which works but is going to have to have some optimizing done and then enabling writing back through the plugin. Interactive tools with deployment group. It's going to be a little bit different in the GKE context just to have some GKE native things as opposed to the things that we do more genetically for Kubernetes with the deployment group so just translating that to GKE specifics. Deployment. Those one specific thing or I guess two specific things that are only for and or the galaxy cube man chart which is right now what the ploys the entire stack of NFS Postgres CVMFS in Galaxy onto GKE for Anvil. So that needs to be maintained and updated with when the new galaxy home chart comes out for 21 or one. So I want to create a testing ecosystem to make sure that at any given time galaxies deployable on Anvil so we can set up crown jobs to run every day or something and make sure that on any given day, if somebody goes to Anvil they can still launch galaxy. And we're already working with the blue team on some optimizations. And we've talked about some things that need to be done on the Leo side. And then some like maybe a little bit that we can still do on the galaxy side, although we've gotten started up to already be like about I think three minutes. We're working with everything from scratch on galaxy side so the bulk is now the seven minutes on the Leo side to deploy the cluster, which we need to cut down. And then finally just the more science stuff of actually developing workflows and more use cases for Anvil. That's it for me. And just like in the previous presentation there is, can you add this presentation to drive. I assume you have an though related get hub board project. Yes, I added this. I added the same things there as project board here. And we also have a, I'm not sure if it should stay private but we have a private Anvil repository right now on galaxy project. I think if you link this to the Google Doc and to have page that would be enough for now. We should try that when we should actually migrate it to the Anvil project slash galaxy repo and move that board. But then yeah, look it up. One question about tool set, is there a document I remember you were sharing it essentially as a Google Doc of the tools of curate set of tools is that is that somewhere. Yeah, I mean we still have the Google talk that you marked tools with lead and green. That was translated to basically we took, I took a dump of the currency VMFS tool shed and then removed everything that was read. But we still need to run the entire tool tests on a new Anvil instance with all the changes and make sure that those still work. And you add the link to this document to your either, you know, Google project or, or your Google Doc because this is also something that tools people need to be aware of. Because that has implications to, for example, common tool set. Okay, I'll add it to slides and to this project board. Thank you. Any other quite okay go ahead. Don't find are you presenting or I don't think we hear you or whoever is presenting. Okay, here you are. So we haven't had the name of the people on the GitHub project yet, but they are on listed on the charter document in Google Drive for the task assigned to everyone. So one of the main project is the community website that Nick is working on. We have a prototype by the end of Q1 and one of the milestone in this process is to have a document with description of the content structure and the website functionalities and setting on the system that's going to be used for that platform. And then concerning the training and outreach video we aiming to have video covering analyze data and workflow interface by the end of Q1 and include them in GTN as micro tutorials that can be linked as snippet everywhere. We want to establish a calendar for the integration of automatic screenshots by the end of Q1 to have more visibility for the next following quarters. We are migrating the FAQ to training material. We start by building a relationship map of the FAQ to have a clear vision of what can go into the training material, what are the priorities. And at the same time, we're going to develop templates for the inclusion of troubleshooting into the GTN so that the next coface we can enroll people to transfer easily from the FAQ to the templates and have it moving quickly. So the next coface is going to happen with a paper cut in February. So we need to advertise the event to prepare the agenda and broadcast the recap of what's been done by the two projects together. We want to send the GTN paper by the end of the quarter. So we also have TI AS that has been deployed in other main, in other galaxy interfaces, so we need to advertise more where is, where it is available and how to use it. We also want to rework the code of conduct because we have noticed that when we have conferences with both, for example, we have more reported case than when we are alone. So that might be due to some lack in describing how to report or how to identify problematic behavior. So we want to include some more detail in the code of conduct. So by the end of the quarter, we want to have an idea of what are the points to improve to have a new code of conduct by the end of Q2 and GCC. We also want to work with the open life science project to advertise the project that are linked to the GTN or Galaxy. We have the gallantries going on, where by the end of Q1, we should have some first results and so we need to request and process the feedback of people using it. And then we have a Galaxy developer training that we're going to schedule and that's going to be discussed at the day round table, probably this month or the next. And any question? What is gallantries? Gallantries is a galaxy for higher education, so teaching undergrads. Okay, so you have quite a few tasks. Are there reasonable lists for one quarter? Well, we have 15 to 20 people on the group, so. All right. I have one question if you scroll all the way up on this. So with the videos, so videos covering workflow, these will be automatically generated ones, right? No, we don't know when the automatic one will be available. It will just be how to, just the same as the interface fundraise data. Who is going to be making them? Me mostly. Okay, so we'll talk about that. Any other questions? Dolphin also again, we'll add the link to this project board. It's in the Google Doc. It is, but it's not on the hub. Okay, support. Hold on a second. You're very purple. I'm very purple. Oh, hello. That's what I want. I'm sorry. I don't do this very often. And I'll be quick so it'll be fine. Can you guys see? Yep. Yeah, okay, so this is just our charter. And I'm just going to add the link to the hub. But I redid it and I'll re-link that to the hub. So there's really just three of us right now. So Ignacio and Igor, we just haven't a chance to get really wrapped up yet. So I'm thinking like Q2. And so primarily what we do is we give support, right? So these are all the places where we do that. And there's a bunch of. Tools and boards and all of that that exists. And most of our collaborations are going to be with the outreach and the training group. So, you know, we need to figure out who's going to be on the team and where we're going to track projects. So that might just be inside other projects. That's fine. And then mapping that fake use into a new structure is kind of a big deal. And we're going to prioritize that because everything else is based off that. So we've started that. You saw Delfine was done on the project board. So there's two main tasks. It's to transfer the training material. This is exactly cloned off of the other working group that Delfine just showed. And so we have a card on that project board. I can link that into here. And then the second thing is that there's a webinar for advanced features. And I want to make sure that all of these topics are migrated over into the GTN before we have the webinar so that we look like we're organized. So there's just a few things to do for that. All of this is currently in the hub right now. And it looks like a big laundry list. There isn't a lot of graphics or anything else like that. So, and this hasn't really been, this has been discussed a little bit, it hasn't been started. I'll probably be working on one. Two and three. Or at least let me be half of one. So on account, I will be discussing that. And then I put this in here and I moved it to Q2. But maybe this isn't us. So. And now we wanted to curate the tool panel and we wanted to curate tools. And I really think that our tool tests are not enough. And the GTN tutorials are enough. We should look at actually, like how the tools are actually performing on the server. So are they passing or failing? You know, is there a usage problem? And so I kind of details into our. Finding technical issues. Know what to do about it. You know, target deprecated hide it, remove it, fix it. So that needs something fixed. And then go back and look at tools that have uses to issues. So that we can look at the ones that fail a lot. And then we know what kind of responses we've given to users about that. And does it need more tool help? And what can be directly incorporated into Galaxy? So. All of the, all the FAQs going into the. The, the. The GTN is as like a tutorial. That might not always be the best place. I might be better to put it on the help of the tool form itself. Or on the tool help. There's a little. Question mark. Next to tools. That isn't always utilized. And so I think we could, we could, we could leverage that. And so if you've got a problem with a. Particular tool, we've got sort of. Documents around that. Like the most common problems. I think we can include that directly in. So maybe whoever works on. This. Curation, we could be. We could help inform that with actual, like, like. Here's the numbers. Here's the versions of the tools. We could be able to do that. We could be able to do that. We could be able to do that. We could be able to do that. We could be able to do that. We could be able to do that. We could be able to do that. I don't know how many times it's used successfully or not. And here's why. So we can kind of give a break out of it. Why it's failing or why it's life. Difficult to use or why people keep asking about it. So. All of this is just sort of like a wish list of things that I think we'd need to do, but. It's, it can't. There's no way that I can do it in Q1. So there are two things. So one of them is. You probably want to decrease the volume of issues that you're dealing with. And one of the ways of doing this is that we need reliable statistics for tool usage. We don't have this form. I mean, we don't have it in the presentable form for Maine, but probably EU and AU and Australian ones have that. We can at least use this as the initial blueprint for figuring out which tools are used in which aren't. This is one of the priorities for admin group to use. So. We need to do this for Maine. That's time. And another thing is that unified tool set. So you sort of need to keep an eye on that. Right. So I think we're not going to be able to start that till Q2. So I just. There's, there's so much to get started for Q1. And I want that webinar to be well. So I, and we're going to need to get. We're going to get to have to get more people involved. Right. So I think we need to, we need to get more people involved. We need to get more people involved. We need to get more people involved. If you can help get connected with, I think we need tools. I think we're going to get need UI UX admin. And I see now there's a scientific group. We need to keep moving because we have. Number of groups left. Thank you. So. Okay. So I will. Briefly talk about scientific applications. This is the group which has a lot of people. We have a lot of people. We have a lot of people. We have a lot of people. We have a lot of people. We have a lot of people. We have a lot of people. We have a lot of people from hub. So I will fix all of these issues. The objective of this group. If I can share this document here. Is to. Is to highlight galaxy highlight real. But examples of real biological problems. That were shown with. That were solved with galaxy. So the goal is to highlight. Biological papers with a galaxy and go. And some of the immediate goals for Q one. Is finishing our SARS-CoV-2 efforts. And getting the. VGP. And pan genome related tools identified. Wrapped. Assembling the workflows. And. will they documents and create the board? For the testing and hardening group, basically it's the same objectives that we, for quarter one that we presented before the break, we put them into a project board. Marius already talked about the performance suite, but we've got that broken down into chunks that we'll be able to sort of accomplish useful things in quarter one, but sort of assemble them to the, so that we finish working product in quarter two. And then release testing is the other big thing, I guess that hasn't been touched on yet. We got 21.01 coming out, and I guess Sergey is gonna relieve the effort to get that release tested. And I think otherwise though, nothing has changed since the last time we presented. So I'll see the rest of my time unless there are questions. No questions, Mr. John, tools. All right, so we currently have one major priority and then based on how long and how big that one ends up being, we have several smaller things and part of our decision for how we're gonna deal with Q1 is actually specifically determine what roles we're taking with Ponemo and tool use, with training for new tool wrappers and a couple other things. So for example, we're looking at discussing tool, like IUC specific hackathons and paper cut days. There is a list of 35-ish tools that were listed as being used in VGP, several of which are not licensed in such a way that we would be able to wrap them, but most of them are, several of which we already have. We don't have specific names yet because we're all kind of reading through each of the tools. Some of them are extremely large from what I understand and will not be able to be put on certain servers for obvious reasons because extreme memory usage and time requirements. So to that end, we have not assigned yet, but we're planning to get all of these, or at least as many of these as possible wrapped by Q1 with the goal of having at least one of the little files that are wrapped in the VGP pipelines as runnable as a workflow in Galaxy. Just a quick comment. If you have any questions about these, I think my group has a lot of experience with all of these. In fact, we've published a few of these. Perfect. And this is, I actually wanted to ask Mike about this is, so are any of these products still used as 10x? I don't think so. I think we're in the transition period. So the company 10x has discontinued their linked read kit, but there are other more or less equivalent technologies out there that people are interested to use. So I think there's a lot of legacy data that's still out there. In principle, a lot of these tools could be used for these other approaches, but it's a valid question. And also for the tools that require a lot of memory, you're probably talking about some of the assemblers that... We're looking to wrap those and then probably make them, like put them in the tool shed, but not actually put them on any major servers that people can choose to run them locally or on a cloud instance that they can launch. Yeah, well, we have to wrap them first, I suppose. So how did this tool set? How did VGP get picked as the priority for Q1 and then the tools falling from that? It's a rapidly evolving area, which is fueled by advances in long read sequencing. And it's priority because we need to get on that train as soon as possible. Because right now, Galaxy is really good for Illumina data. It's not that useful if you have Pegbya or Oxford Nanopore. I mean, I'm talking about main tool set. And this needs to change because if we don't adapt to these technologies, we won't be able to be on the top. But what is your concern in this? Just, I mean, I'm wondering what's the, are we using tools or are we installing, we're adding tools that are sort of required by many according to popular, because every time I look at EU, there's, you know, they have a human cell Atlas version. They have the Nanopore server, they have the RNA one. There's like a dozen different servers. And on main specifically, it's frankly, I don't know, I mean, I don't know enough about tools, but it feels like the hodgepodge of things that are fairly dated. And so just, are we getting these requests from help? Are we getting them from the literature? Are we getting them from, you know, just include more of the user feedback or something? This is, so to answer that question is that we're going to do a review tool set. And so what's going to be at usegalaxy.star, CVMFS will not be a hodgepodge. The question with the multiple faces of .eu, that's a great question. I think we were sort of resistant, we can do this, I suppose, but we're resisting towards this for some technical reasons. Well, I think what we wanted to do is pursue the tool sets in the toolbox in a single instance. And that's sort of work in progress. That's not currently on our priority roadmap, but could definitely be pushed. So the idea there is to tag tools and be able to pull, for example, RNA-seq tools and so on. I don't know if we can, in a short term, to enable EU-like functionality. I'm not sure whether technically we can do this on main. That's a question to Bjorn and Nate, really. You're out of time. Okay, but technically it's not difficult. So if we wanted to go that route in the interim, we certainly could. I think we should go this round in the meantime. I think that's, we should do this. Well, let's talk about that. I don't think we can put it on Q1, but we should do it. Sure. And another thing on VGP is that we're trying to become members of this consortium, which will be a very good publicity thing for Galaxy Project in general. So, and plus it's a great project. It's an interesting open project for sequencing all over the place. And at this point, they're using commercial tools, well, commercial, the workflow tools that are using DNA and access. And what we want to bring is the oblique free distributed functionality system. System. Okay. UI. All right. Did that start sharing? Okay, cool. All right. So I took, or we took all of the priorities from our roadmap, put them on this GitHub board. The first column is the sort of meta information column that the intent is to have some information here. And then we'll, these are just the top level things. The board is going to be pretty active and things will move across it like you'd expect. But the idea is that each of these top level items in the far left column is checked off by the end of the quarter. Sorry, if you hear babies. So it's mostly the same stuff we talked about last time, the new history. We've already merged it and it's in beta mode for 2101. We're going to do a group review to sort of just walk through it, pick particular tasks, test them out and build an issue list that we will then resolve during quarter one. And then swap it in as primary interface during Q1 for 2105 release. So in 2105, the new history will be the history. The second priority is, collapse these things. The second priority is the workflow invocation interface. A lot of work has already been done on this but it basically provides all of the details about a workflow invocation in one component. So the initial PR is actually ready to go really early in the quarter. So we need to add some tests and probably do a little bit of polish and refinement. And then that's the second priority there. Batch operations is one that's maybe a little bit more ambitious because no work has been done on it at all yet. We need to figure out a list of desired operations and then implement a sort of generic operation API, kind of like in Gmail where you say, apply this to all matching emails to flag them or filter them or delete them like I do. And then we want to integrate that in the new history, not even bothering with the old one. I should note that most, all these cards actually do have people associated with them down if you dig in or almost all of them. We have a goal to get some collections UX improvements in. We decided that four items resolved out of the big project board is a good benchmark. So we're going to do that. IGV.js, we want to integrate that as a, first as a charts visualization in Galaxy. This basic single track IGV.js visualization is pretty much done, adding multiple tracks. There are some issues in the charts framework that we ran into, but anyway, so to resolve that and then have parameter driven viewport and things like that piped through without reloads is on the map. And then tool form verification. The idea is not to viewify the whole tool form. That's a big project. In Q1, we want to figure out the right strategy for replacing items, considering they're the impact they'll have across the application because multiple places use some of the widgets, right? So, and then we want to pick one element and convert it as a prototype for distributing the rest of them in Q2 and then finishing up the form. So that's just sort of a baby step towards that project with an I to Q2. The new user welcome, this is returning to that project where first time user gets, instead of the standard welcome they get a sort of a dashboard with curated content for a new user showing them how to use Galaxy. And then this is maybe a bit of a stretch goal but to really lean into per instance configurability so that you could have their own new user welcome and things like that. And then lastly, a library's UX review. We have a big board. So data libraries went through a big overhaul fairly recently with Oleg's verification there. And we also have a board that identified a whole bunch of issues with the old data libraries. But basically the goal for this task for Q1 is just to go through and get organized there and figure out where we need to take data libraries in Q2. It's not necessarily to do a ton of work on data libraries. And that's it. It sounds like a lot, but it's a pretty big group and they're pretty reasonably sized projects some of which have already had a lot of work done to them. So, yep. I think ITs like the UX around ITs is possibly missing from this list. That was not in our priorities list here and we were advised not to add priorities. I mean, it can still get done, but it's not on this list. I mean, obviously UI UX is a huge category and we're gonna do a lot of stuff that's not on this list and that can be one of those things. I would argue that this is more important than library UX because for the ITs. I think that's a different kind of project though. This is not development at all. The library UX review is not development. If anything, I would say the batch operations, we could just push to Q2 and focus on... That's actually even more important than ITs. Okay. It's very painful to use a galaxy where they have very large histories and that would address all of these issues. So, some of this stuff with ITs was waiting for the right time. I don't wanna go over. We can still, we can follow up on that and try to get it done. Okay. Well, any questions to any group? I also, because what I don't want, what I don't like about this meeting is that sort of I'm talking here and that creates an impression and it's all about Maine, but in fact the list of people here is much bigger than the galaxy. So please, any other questions from anybody else? Are we, is there anything missing? And you see any potential connections and so on. I would like to ask all groups to add their project links to the hub and to Google Docs. So it's uniform. So we can look at them. It would be nice if all the projects also have a uniform structure, but that's not necessary, but as long as everybody knows where they are. And may I ask Dave and Bea to put the meetings of all groups to galaxy calendar. So everybody knows when the groups are meeting, for example, I personally would like to participate in two meetings, for example, in UI meetings. Yeah, I can coordinate that. Any other things we're missing? Anything we can make this better? Any suggestions? I have maybe a question to the working groups. Is it working that you can define dependencies on other working groups? Can we facilitate that process or is that fine? So example, again, that the backend group needs to deliver something that the frontend group needs to consume. Is that working okay or do you need to help help in facilitating that somehow? For that one in particular, I think it helps because a lot of us are in both of those groups. So it may not be the best example, but I don't see any problems there. But in what general, when the overlap is not so high, is that still working or? I don't know that at least for stuff that I'm involved in, I haven't tried yet, but we might need something, I don't know. I think the ITs was probably a good example, right? We mentioned that we have some stuff that needs to be worked on, but then no plan to actually do that. So to support the intergroup stuff, we have the point person listed on the hub page and we also have a WG-ALL, excuse me, Gitter channel. So it's not gonna solve our problems, but it will help. Okay, so I didn't say new year because new year for the project begins right now. That's the January one for our so happy new year. And thank you everybody. And we'll post that recording so we know what was happening if we forget. Happy new year. Thanks everyone, bye.