 Welcome to our session Meet the Technical Advisory Board and the Core Developers. I made some slides with the Dean's help and the Dean made some slides and sent them. And the first slide is to introduce the TAB members, several of whom were recently elected. Myself, Sean Davis, Edine, Kasper Hansen, Mike Love, Levi Waldron, Davide Riso, Sheila Gazanfar, Stephanie Hicks, Lori Kern, Charlotte Sonison, Laurent Ghetto, Raphael Irizari, Robert Gentleman, and Wolfgang Huber. I don't know how many of them are on board, but a good number of them are. And so we welcome your questions and your comments. Those who wish to be involved with the Technical Advisory Board can do this by joining a working group. The working group's website is listed on the slide, workinggroups.bioconductor.org. And you can suggest and or lead a new working group and the TAB will be engaging with you to see how we can learn about what you've proposed and help you accomplish the aims of the working group. There is a Slack channel called the Hashtag Technical Advisory Board that can be used to contact the entire board. And there's also any of the members that we've listed before can be contacted to discuss issues related to the technical functionality of Bioconductor. We also have self-nominations and other nomination processes that occur every year around May. And we try to keep the community abreast of this so that individuals who are deserving of participation in the Technical Advisory Board can be elected to that board. Our purpose is to develop strategies to ensure the long-term suitability of core infrastructure for the Bioconductor mission. That's one of our purposes. And so value to the scientific community is something we need to be aware of. We need to understand the overall population of the ecosystem with packages, how it's managed. We do work on end user engagement, approaches to documentation in the web and the support site. And we do developer support and documentation. And the TAB does advise on package that should be used by the developer community. We also are engaged in the pursuit of funding strategies for long-term viability of the project. We have monthly meetings on the first Thursday of every month and the minutes are posted after each meeting. We'll get into the minutes in a moment to see some examples. One aspect of membership in the TAB is that individuals who have funding that is used to operate the project become members of the TAB. I'm one of those. And the aims that we wrote for March 2021 are maintain availability and growth of the ecosystem, enhance reliability and performance of the genome analysis infrastructure components with improved formal testing and modernization of our build system, which is operating every day to build all packages nominally. Aim three was to advance development of genomic methods that leverage cloud-scale computing and data service paradigms. I spoke a bit about some of those ideas in the opening session. And then to enhance education and community engagement processes that have been intrinsic to the project. The TAB governance allows membership of grant principal investigators and the use of the funds has to do with dealing with the balance between community contributions which are not developed by the core and the service project infrastructure packages and the deep stack that I have named in the past few years that is maintained by the core that makes the ecosystem a unified and highly effective tool for a very large participating science of the community. The core developers are here, Natesh, Marcel, Ereve, Jen, Laurie and Alex. And I talk to the core members every week. And this is a hard to see, but this is just a slice of the Trello board at this point describing various things that have to be taken care of. I don't really want to get into the topical structure because if you move this board a bit you start to see things that are a little more topical. But this is one way that the core devs manage their activities. Now the minutes of the tab meetings are available at bioconductor.org and they are under the about tab at the top of the bioconductor.org web address site. And this is an example of some minutes. So for example, we do have a rotating schedule of brief presentations for the TAB and last month we had Rafa Irizari and Natesh Buraga speaking about aspects of improving bioconductors activities in the single cell biology field and also the system that is used to build package binaries which are extremely useful in containerized analysis environments. And the nature of the discussion there is in those bullet points. Going through these minutes is quite instructive for getting a sense of the scope of the project, things that you don't often see. It's usually a meeting that we all look forward to because we are rather far flung, we have people from Europe, we sometimes have an attendee from Asia and people all over the country here get a chance to meet and see what's going on in the project which has to have a new release every six months. So there really isn't a great deal of opportunity to strategize before a new release. So here's a use case where we really need to have a broad input from TAB members and from core developers to deal with this really important asset called the books, the monographs. I hope many of those who are listening are familiar with these, orchestrating single cell analysis, the single R book and the C-Saw book are really very nicely integrated and tested software collections with all kinds of narrative prose that make them monographs. And the maintenance of these things, which are living on top of a constantly changing ecosystem involving both bioconductor and CRAN packages, is delicate. And what we can see now is that in the develop branch, four chapters of the OSCA book are throwing errors. And we know why they're throwing errors and it is a package that needs some maintenance. It's not a core package. The authors of the book are not in control of that package. They may need to change the book so that it doesn't use that package if the package authors do not fix it. And this is just an example of the kind of work that has to be done by the TAV and the core to keep key assets of the ecosystem functioning. And those are the, that is the end of the slides. I hope I have explained enough of the TAV and the DEV core activity so that we have time for comment and question. Is someone watching the chat? Chat is quiet. Chat is quiet. It's a quick question. Yes. You might have said it, but you may repeat those meetings, monthly meetings for TAV. Are they closed? Yeah, the meetings are closed to the TAV and to the core developer group. I don't know that we've ever had much discussion of whether they could be more open. It's usually a pretty packed agenda. But I'd open discussion on that topic to other members of the TAV if they have thoughts about that. At the same time, you mentioned that you provide minutes. The minutes are available very rapidly after the calls. All the minutes for both boards, the cab and the TAV are posted on their respective pages on the main bio-connector page in the about section. There's a page for each board and the minutes are on those pages for each meeting. I would say if anyone from the community felt strongly that they had a topic to address with the TAV or the cab, to reach out like on Slack or to one of the members, because there's been occasions on both boards where we do have like guest presenters or guest topics that was something of interest they felt needed to be addressed with boards. So there's always that option to have a concern that they wanted to raise. Can we build questions about the core of the TAV? Core advisory board is different from the community advisory board or anything? There isn't a core advisory board. There are core developers and we have a, what can I say? We work from release to release for the most part. And there are ideas that come up, for example, advancing containerization, producing binaries so that anyone who's using a container does not have to go through compilation process, but can simply use a binary repository with Bio-C Manager install to get much more rapid inclusion of new packages into a working containerized environment. Those are examples of the kinds of things that crop up. When technology affords new approaches, core devs may decide to experiment and do something that changes the way the core works. For example, Lori is now researching GitHub actions to see how that could, that technology could be mobilized to affect some of the things we do when we ingest new contributions, for example. So I didn't show, and perhaps I should, I thought I had, in fact. I think I showed this in the opening session. But if we take a look at the new contributions, this is a major part of the work of the core, which is to deal with the fact that people want to have new contributions into the ecosystem. And here's a good example of one which may have rather significant ramifications because it uses Rust, and we do not have any Rust using packages in Bioconductor yet. So that means that all the platforms now have to be refreshed to have all the necessary runtimes for Rust compilation. And I don't consider it a bump in the road, but it's something that certainly wasn't planned for. And another thing that we need to do is understand the flow of software into the system through the ingestion process, through the build system to error or success states over time. Because oftentimes when you see something like the errors that I showed you with respect to the books, it is not immediate to understand the cause of the error. You see an event, it's linked to some function in some package, but that doesn't mean that fixing that function in that package is going to make the error go away. Yeah, so please, yeah, please go on. So yesterday there was some discussion about, for example, once a package is accepted into Bioconductor, it's a very rigorous review process to certify the developers have applied the usual standards for documentation, for examples, for a runable substantial thing yet. Now, every so often something kind of sneaks through or perhaps regresses a little bit as versions are bumped and so forth. And one of the package developers mentioned that this was somewhat distressing because it kind of deteriorates the trust of the Bioconductor brand, if you will. And my reply to that was that it's a huge project and it's an ongoing discussion how to scale this up so that it doesn't crush the core developers in terms of review. Because with thousands of packages, it's simply not feasible above and beyond running build every version bump to handle this. But it does seem to be sort of a live problem that crops up every now and then. Is this something where the working groups for the Community Advisory Board are really the tip of the spear for that? Are there, you just meant, when you brought up the build system and how difficult they can be to keep all of the different build platforms up to date for, I guess, the single package builder, the SPB, is the successor to what used to be a nightly rebuild everything. Good part of it, no? It's only for the ingestion process, the single package builder is used and on demand, the nightly builds and checks. So it's just it's a different process. So we use the same builders in the single package builder to try to mimic the daily environment as much as possible review process. But those daily builders are still there. And then maybe you could take it then to where those because I think a lot of people don't know where the daily build checks are. So that might be a good thing to show, too. So once a package is accepted, it moves into the daily nightly build where it still gets installed, built and checked. There's just no bio C check run on accepted packages. It's the standard or install or command build and check that's run on every package. So I think, yeah, if I understood Tim's question, it has to do with the fact that while we do quality control for an ingested package to get into the system, there is no control on what the developer does subsequently to that. If they break that they can remove things, they have agreed, let's say that the API should not change without a deprecation cycle. So things should not come out, but we cannot verify that. We see it sometimes and then ask people to obey the rule that they agreed to. But your point is correct that functionalities can change in release or in develop. And all we have is really this. So if they have changed it in such a way that the package is still showing green, we don't have any reason to intervene. I'll push back a little bit and having been a package developer who depended on something that was deprecated and quite a struggle getting to the point where I could replace it one to one. The triage and deprecation process is real. You know, as fire conductor standards rise, sometimes the package will be squeezed out when the developer doesn't have time to or refuses to update it. So Laurie, I've interacted on that process in fact. So I will push back to say that it's not that there's no quality control. There's no process for it. But it's a heavy lift for a project with thousands of packages. I'm wondering if there's a path forward for this or a degree of trust that once you're in, you're not going to start misbehaving. Well, I think to say that there's nothing that there's daily checks every single night in every single package to make sure that they're actually working with at least not failing. And if they fail, they get deprecated. But then you're relying, I think, on the community to make sure as well that the package is like. Well, things like standards for a compiling vignette that's part of the bill that sort of serves as a not a unit test, but a functional test of competence, if you will, or a fit for purpose test. Sometimes people will put the vignette off of the buying doctor site and won't compile it. I've seen this get shot down in a repair. So I know that on interest, the standards are very high. But sometimes as time goes by, this kind of creeps in. I don't know to what extent I find it important, but I was surprised that one of the actual buyer conductor developers, not core, but it developed with multiple active packages, felt that this was an issue that needed to be raised. So I figured I'd bring it up. Well, I think Larry's starting up the, you know, working group to actually examine some of these, like the triage group. So I think that if it's something that you're interested in, like. Like, let Laurie know, because I think she'd love to have extra people helping. I've got a test that the triage process works as intended by squeezing out a package that I didn't escalate the standards to meet buyer conductors. So I. Yeah. And I want the working groups. So I'm not the only bad guy in the industry. I'm the bad thing is bear a bio conductor right now. Since I'm doing that, and it does get overwhelming for release. And I admittedly I haven't done it as much this release cycle, because I've been tied down with other things, which is why I thought I would kind of cast it off to try to be a new working group. I will say to I think it's been discussed both in the tab and the core. We haven't necessarily implemented yet and we're still trying to figure out how to do it. Right. Because as you mentioned, there's thousands of packages, right? I think we have over 2000 packages and we do install build check on all of them, which is already a heavy load and heavy straining on the build systems. And resources that we have. We run by OC check on incoming packages, which does a lot of those specific bio conductor checks, like having runable examples in the vignettes and everything. We just don't have the resource power to add that in across 2000 packages. I think it's kind of been discussed and maybe this is a good point to bring it off again of either having like a separate system that just runs bioc check and not necessarily as an enforcer, but kind of a snapshot of where packages are with regards to the bioc check since we don't run it. I think bioc check was also introduced. I mean, it hasn't been around forever, right? So that was introduced later on. So we have the standard install build and check from our because that has been. So it might be something that we can kind of consider or look into doing. Maybe as a secondary, it probably wouldn't necessarily be as enforceable for like deprecation, but it would definitely flag us to additional things that were more strict on on submission. We just have to figure out a good way to do it resource wise. I have a question. Do we have any upcoming changes that will be happening in the next release or so that we want to talk about your name? Oh, well, I guess the problem is we are still using master as the default branch name for all the bioconductor get repos. And yeah, it is our intention to change that. I think the candidates now are there will be a develop branch and release. X, Y, Y branch. And that renaming process, I think we are capable of automating. And there's been a fair amount of discussion of how to do that. And the actual event is not yet. Dated as far as I know. Does anyone on the core have a speculation about the data which that could be carried out before 3.16 is released, for example? I have airbase on here virtually, but I know everybody would like to start it as close to after a release as possible so that we would have the full release to get developers used to working with the renaming. So I don't know if he's on or not, but I know airbase push would be like as close to or immediately following the next release as possible. OK, at least from my understanding from maybe sooner, maybe a little later. But sometimes in October or that's what we're shooting for. Yeah, there is there is a comment from someone online asking if people would introduce themselves when when they spoke. Because people aren't sure who who anyone is. What can they see? Hi, I'm Larry, I've been talking a lot. Can you see us? Yes, I think there's some of you who are out of the field of the camera, but it seems like we can see most people. You know, I like physically reorient the camera on 18. No, I'm 18. That's our glory. I think someone is. Maybe it's talking, but I'm talking. I'm Jen, I'm a member of the core team. But I was the one who asked the question about what we're planning to do around the next release or after the next release. And so people aren't scared about that, too. And part of the delay besides, you know, probably crossing our teeth and dotting our eyes is to make sure. I think Jen Natasha, everyone is kind of aware that we need to like update and have good documentation for maintainers throughout this process and throughout this switch. So we're really trying to make sure that all the pieces are in place first and transition for that and get more. So what I've done now is put onto the screen a little more of our Trello boards. And just to give a little more. Information on some of the broader topics that we'd like to fold into our work. The BBS activities, the bio conductor build system, this has been speaking. It has always seemed to me that we would like to have a database where we record for historical investigation the state of the different packages on different platforms. As builds occur, we have a number of pieces of hardware that we own or that we rent and a catalog of them and a dashboard that identifies their state, their uptimes and so forth is needed. We have storage in many different environments. And again, a dashboard that shows how it's being consumed when we might run out of space and so forth is something I'd like to see done. This release if possible. We are distributing data in many different ways, data being software packages, binaries, experiment data, annotation data, and it can be expensive when there are egress charges involved. We do not have a requester pays approach for anything. And so there is what I would call forensics that must be conducted when it seems that there's a site that is pulling data robotically that they don't actually need and driving up our costs. We have done some of that. Martin did that a year ago or so. We want to be able to bring new core members on when we have resources to do this. And so there needs to be a cookbook describing all of the activities. We have pretty good documentation in that respect. The Git branch renaming, we've just discussed. There are maintenance activities for the single package builder. Workshop orchestrator, that's something that Sean Davis has contributed that is used in the conference. We also have another implementation of that concept by Alex. And there's a lot of work in Kubernetes. I think there's need for more expertise in the group to grow in understanding container orchestration and what it can do for the deeper activities of the project with respect to compilation and management of the whole ecosystem. So there's a lot for the core to do and the TAB may be interested in some of these and may wish to express desires of prioritization among those many activities. And it's a lot. So when community members get involved and help us to solve problems or to reduce the number of problems, it is much appreciated. She probably mentioned just about grants and things like that. But if people are this is a team. Yeah, so if people are interested in applying for funding, whether it be from NIH or CCI or any other organization, whether that's to support by a conductor at the community level at the technical level or just to help integration of packages where the people in by a conductor are very, very keen to help. Community members get funds to help the whole project grow. So please do contact us. We can help you with that application. We can write your letter support. You're a core member. Alex. This is the one core member that took it in the name wrong. Do you want to introduce yourself to the folks that are joining your tour? Sure, I'm Alex. I joined in December. I'm the newest working member. Yeah, I do most of the so-called cloud things and these things. Good. I love the community. I like the core team. I came from the Galaxy Project. So I've been like open source, open science, biology sphere for three years now. Yeah, one of the projects that we've been working on is with the Yes for Cure program at Dana Farber. It's a program for junior in high school to junior in college students. We did a cancer data science check. So I made kind of a pipeline to go from on the files to Python notebooks and automatically applied it to this Galaxy instance. So using GitHub actions to automate the whole process with somebody can make a change to an on the file and it gets propagated to a live instance. And students come here, they launch notebooks. It takes about 30 seconds for the notebook to come up and then they can do the course and submit it back to us. And yeah, should we give a background on what Cure is? So that's not the Seattle Children's Hospital. Cure, in this instance, is it's actually an NIH program and the CD for underrepresented minorities. And so it's a program for high school students and also for undergraduates who come from underrepresented minorities and to encourage them to get involved in in cancer research. So we were talking with the Cure group at Dana Farber, Vincent, myself. And we recognize that whilst they had a program to recruit underrepresented minority students into the wet lab research, they didn't really have anything in bioinformatics. And they really recognize this with with COVID recently. So this project is to encourage like to provide a route, I suppose, into cancer research and bioinformatics for students. And so they have recruited quite a lot of from local and high schools and from universities where there is more ethnic diversity. It's fantastic. And I mentioned a young woman of the Regeneron STS program she approached me and if this had existed when we were working together, I mean, she did quite well. She's a standard now, but I would have given anything for something like this to be able to pass on directly. This is phenomenal. Yeah. Well, Alex really made the a lot of bridge work to to make this happen. You know, we're talking about our markdown. I think one of the things we really want to accomplish is helping people to offer effective teaching materials and to make them available for computation as quickly as possible. So you write an our markdown, put it in a package and then the steps required to put it in a system of this type are really very, very simple. So this is just, you know, an idea of, you know, could we could we move this framework into other topic areas in genomic data science and for other, you know, student populations and so forth? I think it is very viable thanks to this kind of work. It's not like first year grad or first year grad school student workforce this year was really where something like this, if I had access to an expertise with it, maybe I left a thousand times this year. So this is pretty terrific. Let's keep in touch, because we should write this up and and get more people to use these types of webinar 25 submitted the sort of thing that they're not going to want specifically for DEF. Yeah. Yeah. And just a structure is running on the Jettstein cloud at Indiana University. So it starts on one of the commercial clouds. So the U of S lectures, three service units instead of actually paying the company for money. And I'm also, I guess, managing the open storage network. We also got an allocation there and we got an AWS open data and collaboration with the Galaxy Project. So we have a bucket where Amazon is just paying for the egos fees for us and that bucket is in Sydney. So we have the open storage network in the U.S. and then the AWS open data bucket in Sydney, both egos free places where we can put data and we just got that a few months ago. So slowly transitioning things to use that one. If students been enrolled in this yet, or when is the first batch of students? Yeah, we started three weeks ago. Yeah. We gave a talk with 100 people and 11 decided to register for this. That's pretty good. Four meetings. Yeah. And they each doing different projects. And is this the training? Is this the through the year training program that they're doing? OK, so this is getting a little off topic. Sorry. This is data science. They all have their own work in wet labs and so forth. So it was just bringing them into a data science scope. It's 9.45 and I think we are due to end. Yeah. So. I really thank everyone who turned out and I hope dialogue between us and others who are interested in the TAB and the core will continue. Any other final parting comments? Questions. Don't be afraid to ask us questions and don't be afraid when the call goes out for new members to boards to apply because we really wanted to first find and get more people in and then we really encourage people if you're interested in getting involved, don't be intimidated to. Yes, absolutely. Welcome. Does Levi or Charlotte want to say something? Maybe I'll just add that you also don't have to wait to be a member of the board to to get involved. That we want to have activities going on outside of the the board meetings in the form of working groups and and you can become involved in that at any time. So if there's something that you have in mind or you see something on the working groups page that interests you, please get in touch and get involved. And that's a good way to make yourself known to the people on the board and and to meet people and contribute to the project. Sure. Sorry, sorry for my self as well. The calories of my daily life. Keep in touch. For champion. It's it's me. Oh, OK. Five. So I'm going to head over to J&B to try and make sure that there's no lightning sparks or anything withdrawing. I'm going to be fine. Benithi, I think it's over there. All right, terrific.