 And we'll get started. OK, hi, everybody. Thank you for joining Jenkins Online Meetup. In today's session, we will be covering the last four project ideas of GSOC 2024 Project Ideas List. My name is Alyssa Tong. I'm one of the ORC admins. And on this webinar with me are three other ORC admins. Chris Stern, Jean-Marc Mason, Bruno Varrocton. Chris and Bruno are also lead mentors or mentors and lead mentors for our projects. Also with us are Alex and Valentin. Both are also lead mentors. On to the next slide. All right. So some housekeeping notes before we begin. If you're not speaking, please mute your audio. So in this session is going to be recorded. It is actually being recorded. And we will share the link along with the slides after the session today. So if you have questions, feel free to put them in the Q&A window throughout the session. Our ORC admins and mentors will respond to them accordingly. And we have, as you may already know, we have an active GSOC and discourse channels for further communications. So feel free to join the conversations or post your questions there after this webinar. And lastly, the Code of Conduct is in full effect here as well as throughout our community. If you don't know what it means, it simply means that being kind and being respectful to one another. So in this webinar, our lead mentors will do a walkthrough of the following project ideas. Cloud events plug-in for Jenkins, enhancing an existing LLM model for domain-specific Jenkins knowledge, manage Jenkins CI GitHub permissions as code, and open rewrite for plug-in modernization. After each project idea walkthrough, we will pause for a few minutes to take questions. You can either unmute yourself or put your questions in the Q&A window. You don't want to unmute? No, unmute will not work because this is a panel. Oh, right, right. So attendees don't have a mic. So the only way to ask questions is through Q&A. OK, all right. Thanks, John Mark. So let me see what else. So without delay, we will get started with Chris. OK, hi everyone. So the first project we're going to talk about is the Cloud Events Plug-in for Jenkins. So next slide. For this project, the project size of medium, which is about 175 hours or more. So the project difficulty is somewhere between intermediate to advanced. The project nature is to revamp an existing plug-in or plug-ins because it just came to our attention that actually something called a CD events plug-in is in existence. And we may want to take a look at that as well. Or to start a brand new plug-in from scratch. And they were listening to a meeting of Cloud events from Jenkins to add support for continuous 3D presentations, CD events, which is, I think, it's a subset of Cloud events. The goal of this project is to build a plug-in event driven architecture based on Cloud events SDK capabilities. So in our case, we prefer to use, I think, the Java SDK. But that can be discussed. This goes to be learned through this project or Java, Go, Cloud events, SDK, and networking. And so next slide. So what are Cloud events? It's simply its specification for the scrubbing event data in the common way, which is like the JSON element. You can specify sync wave events as sent to the source. And this concept is important because it's one of the requirements to be added to the plug-in when the user interacts with this plug-in. And sync can be system logs, HTTPS protocol binding. It can be AWS, SQS, or Kafka, or protocol event format, or JSON event format, et cetera. So the ability to show the events by status would be nice to have, such as success, failed, triggered. So but the project must support CDE events, which is a common specification for continuous delivery events. And a continuous delivery foundation, it's one of the groups we worked with here at Jenkins. And I'll show you the next project. Chris, just we will make a short pause here if somebody would like to ask a question. So you can go ahead in Q&A if you have questions. We'll wait for a little bit less than a minute. Just checking on GitHub. There is one from Shivaji. Could you please explain it more in details? Shivaji, can you say, is there a particular point that you didn't understand, or we just explain a little bit more in detail globally, the project? Well, here, Chris, maybe you can start answering, giving a little bit more details. OK. So I think the follow up was at the Cloud events point. Guys, what is Cloud events, or is that why we use it? So let's see the Cloud events point. Let's go back to one slide before this. You want me to go back to the other slide? Just one before. Yeah, this one. So Cloud events are basically just not this one next one. The one before, not after before. This one? Before. Oh, sorry. Yeah, no. No? Here. You're going back. Hold on. In the opposite direction. Yeah. Hold on. There. This one, not this one, right? There, this one, the one you're, the one Chris is looking at, one below, number six. OK, yeah. Cloud events, it's, well, if we want to specify it, like, you have to look at the docs to see, like, what the format is. It's basically just a format to, like, communicate event data. And so it's like, this is a very brief summary. So I think if you want more info, you could go to the two links provided in the, I think it's in the, can we, can we, can you go to the link in the previous slide? No, dear. No worries. Yeah, let's go to that one. So if you click on, like, I think it's a CD events link, CD events.deft link. No, not that one, the next one. Yeah, that one. So if you click on this one, you'll be able to find more information about the CD events I mentioned. And CD events, it's like, I think it's a subset of our Cloud events. So Cloud events would be what's based on. This is, like, a specific to CD foundation. And we want to support this. That's why the project is like, in fact. Chris, I'm a little bit new to this. The purpose of the project would be to be able to send CD events to configurable sources. Would it be to receive CD events in both directions? OK, we had a question from Mohammed. Do we support any of the message blocker servers you mentioned? That depends on the scope of your proposal. You can support, like, multiple formats, including, but not limited to AWS SQS as one of them. Another one is Kafka. And another one would be, I think, WETS too. But another option would be, I think, you could support, I think, one format called AMQP. So that's another format we can support. There's a follow-up question from Shivaji. Is there already a cloud event plugin? I think you mentioned it shortly. And why do we need to do a new one? We need to do a new one because the old one doesn't support CD events, as I mentioned. That's always a why. That's why it's a must to support CD events. OK, so the subset of cloud events, but more for continuous delivery. I learned a couple of things. Thank you. We can, Alyssa, I believe we covered the questions, otherwise we're still there tomorrow. Yes, I probably have a question there. Is there kind of existing plugin to be updated instead of creating a new one? So that one's like, it's kind of like awkward because of the existing plugins. One of them maybe we may be able to work on it, but we need to get permission, or we need to collaborate with the team responsible for maintaining it. The other one, the original one, that was from, I think it's the 2071 GSOC program. That one, I don't think it's kind of like a no longer actively maintained. So a better idea would be to start from scratch. Also because a lot of what happened before the CD events came to be. So it was like, that's why we want to start a new one. OK, we'll take the last one. How many talks do we do, do projects do we have, Alyssa? Because I want to know how much time. We have four today. OK, we'll have to spend two more minutes. I'll answer this quickly. So first we want to create a plugin support CDN. OK, I think it depends. And then we'll provide some examples for each quality event services. So kind of, if I understand your question properly. OK, events. Yeah, yeah, yeah. So has anyone? Yeah, I'm going to talk with someone from CDN site on Friday. That's when we'll learn more about it. But right now we don't know yet. Yeah, that's it. OK, Alyssa, I suggest that we move on. I think the lead mentor is Chris Tern, too. So go ahead. Yeah, so next project we're going to talk about is enhancing existing LRM model with domain-specific Jenkins knowledge. And for that, the project size is, again, medium. And it should take about a little bit more than 175 hours. So project difficulty is from intermediate to advanced because you would need to know some basics about deep learning, especially NLP, to be able to excel in this project. Portrait nature is defined to an existing open source LLM model with Jenkins-specific domain knowledge and the UI for users to interact with it. Our goal is to have an AI-driven app from end to end that will enhance users' commands with Jenkins, such as to on-prem, which suggests ways to maneuver some Jenkins-related tasks. The skills gained through the project, predicted, would be Python, LLM, likely Lama2 or its variants. But we're open to other suggestions, too. AI, ML, Jenkins, UI, or Lama, which is a 2-to-1 LLM locally. So next slide. The trick is not so easy part about this project. The first part, which is a pretty big part, is data collection. So some considerations we need to have are what to afford, what should be the coverage of what kind of data. So that's like, you need to know Jenkins pretty well to do a good job collecting data alone and how to achieve a good balance of the data. So the fun-tuning part, how to do a great job. So we have to be careful about how to achieve these outcomes with limited resources. So second points need to work with limited resources because everything has to be done locally and most properly on laptop. UX, you need to know how to make it user-friendly and how to make the presentation pleasing. And I think that's the end of this presentation. So any questions? Question from Nur Yad Al-Muham. So thank you, Chris, for explaining this. Wanted to ask what basically the criteria for contributor selection for this project or there is no code base actually for this? Yeah, that's a good question. But the thing is you need to demonstrate some knowledge of Jenkins to begin with because like this project, the sole purpose is to facilitate the usage of Jenkins. So you have to like, you should submit some PRs, ideally, maybe to Jenkins style or Jenkins co-aven or to some Jenkins plug-in to them so you at least know what Jenkins is about basically and how to use Git. To demonstrate that the knowledge, enough knowledge of Jenkins and how it all works together. Is that correct? Yeah, that's correct. And also you need to write or draft a proposal to be reviewed or if you don't want to be reviewed, submit it directly. But for that proposal, you have to explain very clearly and to demonstrate, you have to know how the knowledge to carry the project to completion successfully. And that's like not so easy to do actually and you need to read a lot about Jenkins, maybe the documentation on Jenkins.io. And also maybe there are some YouTube playlists too, especially the ones where they are in Pope. I would recommend those two if you want to like get some hands on knowledge about how Jenkins is like and how it works. It's basic architecture, it's like on top of that. Actually this project is very difficult to do properly. So if you want to try for it, you would need to put in a lot of effort. Nur, did that answer your question or you want to? It looks like, yeah, but he has another question that works. Do you think we can investigate other open source LLMs as well in my mind open orca, for example, and I was thinking of Mistra also. Sorry, mind you. This was open orca, I'm not sure. We could discuss. Yeah, once we get to the voice review study. Yeah, Mistra also. Thank you. So the choice is open in the proposal. Did I understand it correctly, Chris? Yep, that's correct. So were you suggesting one of the models or the engines? I'm not familiar with that. I think we are suggesting to use just one open source LLM and that's going through it. Yeah, that I agree must be open source LLM. Yeah, and we need also to check data ownership. Yeah, sure. OK, so I think it's a normal question. Noor would like to send a draft proposal for this and maybe we can discuss. I will investigate. This is a very wise step to do. So the principle is, as we explained in previous session, is that by writing a draft proposal, you start a discussion publicly with the community and with the mentors in particular. So sending in a draft proposal and to start a discussion about that is really the way to go. OK, I want to add that this year, I think Lisa started a forum for submitting a proposal for review. So that may be more agreeable for most people because that provides some love of privacy and maybe a bit like to so as to prevent plagiarism as well. I think it's one brain. Yeah, and also the intention was we had last year we had so many people sending us drafts in different places. And there was a high likelihood that we could have missed, you know, one or two here and there. So I thought the forum could help us keep everything together in one place so that we can make it manageable for our mentors. Yeah, that's a good idea. So community, the Jenkins-Odio, correct? Yes, but there is a form that I put out. So I will. OK, got you. And all we send, it's going to be all over the place. So you can't miss it, really. Yeah, OK. We're good. So we can move on with Alex at this time. Yep. OK. All right. Hey, everyone. Go ahead. No, I wanted to make fun of that's me. I didn't know you had so many gray hairs with a wizard. All right, John Mark, then I will go ahead. All right. Yeah, my name is Alexander Brandes. I am a Jenkins Core Maintainer and the Governance Board member, and actually it's the first time for me being a G-segmentor. So yay. OK, I'm entering the project called Managed Jenkins CI-Guitar Permissions as code. Thanks for the next slide, Alyssa. The project is called RPU in short form, and I will use the abbreviation in the further slide. So don't get confused. RPU just means Repository Permission Updater, just the short form of the project. As you can see, the Repository Permission Updater in a nutshell manages Artifactory Permission and Automatic Release Permission for Jenkins plugins. It doesn't have anything to do with repositories at all. It's just a bit misleading the name. And the goal of the project is to turn it into a tool that actually manages Repository Permission because the outcome of the project focuses on a tool you can submit a pull request to. And once the pull request is merged, it updates the GitHub permissions of the repository inside the Jenkins CI GitHub organization. Some of you may have already taken a look at it, and you know that we have around 2,200 plugin repositories inside the Jenkins CI organization. And if someone wants to update a membership, this is currently done by hand by a few people, including myself. And the goal is to automate this progress. Next slide. Yes, this is a draft I made up how it can look like. This is not how it is supposed to be looked like, and it doesn't show how it is at the moment. On the left hand, you can see user files API are at the bottom, you can see a new entry to the YAML file editor called GitHub team. And under this list, people can add GitHub user names of people who should be added to the GitHub team. Once this PR is filed and merged, the tool should update the team membership in the GitHub repository. On the middle hand, I added a screenshot of the team how it can look like if team members are added. If you don't mind handing over a screenshot, then I would quickly show what the RPU repository looks like. We lost the slide. Oh, OK, sorry. Yeah, you share. Unfortunately, I can't screenshot from my current machine. This is pretty unfortunate. OK. Is there a link or? Yeah, if you could go through the Jenkins Infraorganization on GitHub. OK, hold on. Let me go back. Are you logged into GitHub? You don't really need to be a log and just quickly demonstrate where this. I know you're good. This one, Alex? Yes, Jenkins Infra, just the organization over for you, please. Organizations. The link top left, where the octopus is, Jenkins Infra, you click on that. Right. Thanks so much. If you scroll a bit down, the repository should be pinned a bit more. Yeah, there's the repository permission updater. Right column, middle. Right column, yeah. To the right. What is it called again right here? Repository permission updater. One up there. Wrong one. This one here. Yes, this is the is the GitHub repository of the existing repository permission updater code. All the tooling currently lives there. And if you scroll down in the repository, you can see a long, long read me explaining how it works in detail. I don't want to go over that right here because we have everything written down how it works, how the MO file must be structured, how the GitHub repository is defined, how the Artifactory path works in detail. We have everything there. So if you want to know more about the repository permission updater in its current state, feel free to read me or shoot me a ping in the GitHub channel. On the third slide of the presentation, I added a link to the GitHub channel where the discussion happens. If you haven't, it's slide 11, I think, 10. Yeah. Don't hesitate to join the link and ask any questions in case something is unclear and you don't really know where to get started or how to get started or how the RPU works in the current state and how you could contribute without breaking it. So don't hesitate to ask me a question or ask the others. I'm always there just to be a ping. If you don't mind going to the last slide. Yeah. The project is a medium-sized project. I ranked it as beginner to intermediate because it doesn't really involve working with Jenkins itself, but it is a tooling for the entire Jenkins CI organization. Every plugin, every component, every API, every wrapper depends upon your need in order to cut releases. And it's a critical component in the Jenkins infrastructure. And as I said before, the goal of the project is to automate the management of GitHub permissions for the Jenkins CI organization, given currently this is all done by hand and takes super long if you want to update five or 10 teams with 20 people. The skills to learn invoke Java, Groovy, Git, Maven, Snake YAML, and a custom GitHub API we are using, which runs the repository permission updater under the hood. But to be said, there are like two or three, maybe four Groovy files in the repository permission updater, which can be removed if you want to transform the RPU into a Java-only project, which would be totally fine. And I would appreciate it if you can get rid of the Groovy files there. So you don't really need to learn Groovy. This is just in order to get rid of the files. And Snake YAML is the library we use in order to read and manage the data for every repository file. At the bottom of the slide, I added a link to the Jenkins I.O. page, outlining a bit more information about the project, the scope, how to get started, or adding a link to the GitHub API I mentioned before in order to get yourself familiar with it. I have a question. Yes, I just read an LV. I receive what can do some GitHub operations already. I imagine it will be superseded by this project. Yeah, I'm aware that we have an IRC bot, but I don't have an IRC setup. I don't have a Bouncer setup. And I prefer using my GitHub administration rights because it is much, much quicker instead of writing five or six bot comments. But yeah, you're totally right. The IRC bot will likely be superseded if the project takes off and finalizes because you will no longer need to run any comments. Yeah, thanks, Evie. I tried it once, and I didn't really get it to work. So yeah. But ultimately, you're right. The goal is to get rid of the IRC bot and get it to run in the GitHub PR merge state totally. So we can get rid of that all and make sure once the PR is merged, everything is machine handled. I have a question and user request. So is the project or do you recommend that the project handles GitHub access rights and so on? But will it also handle removing? So if somebody decides to leave PluginMetain or these, will it also handle currently does not very well? Yeah, that's actually a good question. In the current state, the GitHub API, we are using already supports this functionality, but we never got around implementing it. So if you file a PR removing members from the defined list, in the best case, it should update their permissions as well and remove the people from the team because the underlying API does already exist. But it doesn't work well because I still receive messages. But there's something to look in. It's not just adding users. It's also removing. Yes. Currently, it doesn't do anything big, but be remind, you can still leave GitHub teams on your own if you want to do that. So you don't really need to do that through the RPU, but that would be the most easiest way to do that. Are there other questions, the attendants? In case you have more questions after the meeting, don't hesitate to ask us in the GitHub channel. I'll be there and I will try to my best and answer them. Thank you very much. Lisa, you're on mute. Hello. So last but not least. So my name is Valentin. He's also the first time I'm a GSOC mentor this year. So I will present the open reward for planning modernization. Can I move this slide? Thank you. So the project size is medium, but I would also expect that is a project that will also continue to evolve a lot after the GSOC phase, especially to implement more receipt. I rank this as intermediate to advance because you also need to know a lot the plugin ecosystem and what it means to modernize and update the plugins. So the project nature is that we want to automate the plugin modernization transform and also perform large scale refactoring. So the goal is to provide a new tool, generic based on the open rewrite framework. So open rewrite is a tool based in Java with some core implementation and modules. And it allows you to implement your own receipt. So the idea is to implement, to use this framework to create a new tool and demonstrate it on running it on the plugin ecosystem and see how robust it can be with some implemented receipt. So if you go, if you already went to the plugin page, there are a lot of example of receipt. I don't expect to have all implemented here, but that's something that can be extended on the future. So if you can go back to the slide, thank you. Here, one of the main challenge is the dependencies between a receipt. If we take, for example, one example where we want to replace one dependency with one API plugin, the naive way would be to just transform the POM file and add this dependency, but most of the time this will fail because probably this plugin is depending on a very old version of core and adding the dependency, the new API plugin will fail and the plugin will not even compile. So here the challenge is really to build those kind of dependency graphs based on the plugin metadata in order that when we at the end open the pull request that we don't have any false positive and that the plugin actually is a building by the CI. So on the required scale, Java, of course, data structure, especially on graphs and trees. So open rewrite is using the trees and the visit on pattern that you can implement to perform operation on the nodes and perform transformation. And of course also on the Jenkins tool chain like Maven. So if we want also in the future to integrate this generic tool to the tool chain is good also to know how is it working. And on the link you will find more information about the project. So if you have any question. Fun project. Very interesting. Yeah. Any questions? Are there general questions? Oh yes. When the last date for draft proposal. So I would like to have it done. Well, let me see. So we are February. So March 18th is when submissions are being collected by Google. So definitely much before that because you need to give mentors and lead mentors some time to review your proposal. I am hoping. So today is the 27th. Let me take a look. The 18th of March is when proposals are open for Google. So I'm hoping either this week, next week would be good because we need to give time to mentors like I said to provide feedback. Okay, we have two questions about the last project open rewrite here. One from Jakruti asking the project goal is to use open AI to automate the plug-in modernization. Is that a good rephrasing of open rewrite? I'm not sure exactly by open AI. But we want to use open heroites that is producing let's say predictable way on all the receipts implemented. So I don't think that on this project we want to use AI to do those kind of things. Yeah, it starts with the same word open, but that's it. Not the same end. Yeah, totally different tool. Thank you, Jakruti. Okay. Then we have a question from Dibay and Gauche. How does ReFaster and JDom come into the picture for open rewrite? So ReFaster and JDom. So if you implement a receipt using open rewrite so it's Java based. So here you are, let's say free to use other framework to perform the transformation. Open rewrite is already providing many APIs to perform a transformation on XML or Java code. But we could also explore when we implement those receipts using other framework or libraries to perform those changes. So I hope it answered the question. Thank you. Now we have a few general questions. One of them being, can we discuss with mentors our ideas about the project and how? Well, we have Gitter. We have community.genkin.io. I'm not so sure there is a channel in Gitter for each and every project. Alexander showed us earlier one he has created for his project, but I don't know if Chris has one for his project for example, but yes. Yeah, okay. Usually what we do is we start a new channel after the project is selected. Yes. We discuss which medium to use. So GsocSig Gitter channel should be the right way to discuss. Of course, there is no one on one. Everything should be public. So it's no use to start sending private messages on community.genkin.io for example. Everything should be public. I hope that answers your question and other admins or mentors, please add comments or something if you think I was wrong doing that. No, no, you're perfectly to the point. Thank you. It's a waste of bandwidth to start answering and discussing with each individual one. So it's the whole community that needs to benefit from the discussion. And the other thing is that otherwise it starts to instill a defiance or suspicion in the other that somebody could get a better relationship or better answer from this or that mentor. So it's best to make everything in the open everything public. This has been covered. Yeah, we have another question from Akash Mishra. Can we give an in progress proposal for review? I mean more than 90% completed. Please, please. Do you answer that one? Or somebody else wants to answer. Go ahead. Yeah, so I already said, please, please do. Once you have something that takes forms and if you have questions or doubts on that make them clearly in the document and make them obvious. So you show what you're doing. What is your thought progress and you try to elicit comments, advice or reactions by the community and others. So yeah, well, I don't send in a document that just has a title. I do have a follow up question though is like for John Mark. So like this year, do you have a limit for how many times a review can be requested for the same purpose? So do we do have such a thing? This is a good question. I'm here only as an advisor in that. So this is a discussion that the org admins need to have. The point that Chris is doing is that last year we had a huge amount of proposals and half-baked one and this takes a lot of time into account. So, well, I leave you Chris or Bruno or others. It would be interesting to set a limit to the number of reviews. What is your take at that, Chris? I think maybe not more than three times. Sounds very reasonable, yeah. So I think what we also wanna keep in mind is all mentors and co-mentors have a full-time job and they have limited time. So keep in mind that if you're gonna submit draft proposals several times, they may not get around to reviewing all those times that you want them to. Just because the amount of proposals that we get and plus our full-time job, it can be a lot. I can answer the question of Noor here, moving on. So my final question, Noor, I don't believe you. You come with a lot of very interesting questions so keep them coming. Alyssa is going to turn off the meeting when we go to the grade, so what is the criteria? So what is the criteria Google depends on in deciding which project to fund and which to refuse? I want to clarify this. The process is following is that the Jenkins community, organ men's and mentors will review the proposals and the project and rank them. And say, if we have only one step further, Google is going to tell us you will receive this year so many slots. And so let's say Google is going to say, we can share only money for you to make four projects. Automatically, the four first projects in our ranking list will be picked. So the ranked list is key. And this is what the mentors are going to work. If we're in a super good year and we have the capacity, if we propose 12 slots and say, we're able to do 12 projects and Google says, yes, you get these 12s, we'll do 12. So it's a balance between our mentoring capacity, the quality of the proposals that will then go through how many slots Google gives us. I hope that was clear. So the decision and ranking is Jenkins community. Google just says, they open their wallet and say, we can offer you or pay for four projects. Alyssa, was that clear or did I completely mess up my answer? I think you're right on. Okay, good. So that was answered. Which one do we have? We have from Muhammad. So as a new contributor, what do you expect from us to do as first step? Okay, that is a very big question. Well, I see Chris is answering there. I think that we're... I propose that we park this question or if somebody can answer that. And I think it has been answered. Otherwise, we're going to be... Actually, it's just a link from Google for contributors to say about what to expect, how to start the application process. So I will also teach you how to choose an organization for a new project. And what to do if we get turned down. Great. Okay. Thank you. You rescue me there because I was fearing that I would get into a rabbit hole and giving two explanations. Noor, yeah, I was right. There is another question from Noor. So this brings another question to my mind. Can we share old channels created for specific projects? For example, if one was created to the fine tune, can we share this also? Well, I've... I can make a... I can make a list. Yeah. We can make a centralized list and normally the communication channels per project are also or should be on the project page. That was answered and we have the last one from Debayan. How many projects can we submit a project, a proposal for? As many as you wish. No, that's not right. But one, but you need to have a quality proposal and don't forget you're going to make the mentors or you're going to make them waste their time. Oh, but as you're on a roll, like Google allows three proposals to be submitted. Oh, okay. That's okay. I didn't know that rule, but generally spreading over more than three is you're not going to be enough in depth on the project. So three sounds a good limit. I would focus on quality over quantity. Yeah. Now, what you need to know is that there is an interest to work on several projects because some projects might not be chosen from the community side because mentors cannot be spread or multiplied and spread on several projects. So when we reach the end, the number of possible projects will start to be limited, not limited, but I missed that answer. Chris, help me on that one. What I wanted to say that competing on two projects could be an interesting thing because sometimes mentors withdraw. Yeah. Yeah. Sometimes what you guys get canceled to. Yeah. And we have our priorities. So if you want to compete, so it can be fluid at certain times, but it's life is not easy. So you need to choose. So three maximum is a very good rule of thumb. That was a conclusion that you need to remember. But as a general rule, if a project is likely going to get canceled, we'll make an announcement in advance. Yeah. Happened last year. Other questions? Oh, there. Lisa, if you want to conclude, we're now five minutes from the end. Yeah. So we, so here are some links that we thought might be helpful for candidates. There's a lot of reading. There's a lot of due diligence. That's going to be needed on your end. But I wanted to call out the third bullet here, which is your draft proposal for review. Again, if it did not make it onto this form, it will not be reviewed. And like I said earlier, all of us, we have a full-time job. So this will help us keep everything in one place and we're not going off and searching for your draft somewhere else. So if it doesn't make it onto this form, it will not get reviewed. And you will need to give mentors and co-mentors time to review your drafts. So submissions are open for, from Google on March 18th. So that means that you need to provide us, give us like at least one to one week perhaps to review your drafts and provide feedback. Okay. So work the dates backward and figure that out. Give us a week or two to review. But yeah. So we have another five more minutes for questions. There was one question answered in written form, but I can give some color to that. The question was about, is the ranking visible in real time? And is it public? The ranking is not public. So these are discussions and waiting. So that's done internally in the mentor in an organ main team. Yes. I'll share the slides and the recording after the session. It'll be on the Gitter channel. Okay. Done. If we send a draft for review after March 18, will there be any problem? I don't think so. I think it should be okay. It's okay. Do we have a hotline for reviews? We should have one right? I think we had one last year. Don't remember the date normally. So the time spent on the reviews is limited. And because we also need to rank. So the near you get to the final date for submitting your proposal to Google, this is where they turn off the shut down the entrance. The closer you get to the date, the less valuable review you will have. How about we make it one week before the application closes? I think there's a good proposal. Yeah, that's fine. I can update the form with the dates. Okay. That was the last one. Thank you. Good that it was useful for you. We try to improve each time on this. Alyssa, I think we're reached the end now. We're at the top of the hour. Yeah. Great session. Thank you everybody for your questions. Thank you to our panelists for today. We'll see you guys on the getter channel. Have a good evening. Have a good night. Have a good day. Bye everybody. Thank you. Bye.