 All right. Hi, everybody. Thank you for joining Jenkins online meetup. Today's topic is on Google Summer of Code, a guide to better preparations for candidates. So my name is Alyssa Tong. I'm on the, I'm one of the GSOC org admins. On this webinar with me are two other GSOC org admins, Jean-Marc Mason and Chris Stern. And also our mentor is here. One of our mentors is here, Marc Waite. Some housekeeping items before we begin. So this session is being recorded. We will share the link to the recording after today's session. If you have questions, feel free to put them in the Q&A window throughout the session. Our org admins and mentor will respond to them. And then we also have an active GSOC discourse and get our channels for further discussions. So feel free to join the conversations there or post your questions there after this webinar. And lastly, the code of conduct is in full effect here as well as throughout our Jenkins community. What that means it's, it just means be kind to one another. On today's agenda, we will cover why you might want to join GSOC, how GSOC works, some important dates and tips to remember, and then we'll answer any questions at the end. So Jean-Marc. Hello. Good evening. Good afternoon. Good morning, everybody around. Here we have now 15 attendees to there. So very happy to be part of that. I am org admin for Google Summer of Code for Jenkins. And well, one of the questions that the participants have here. So what does it mean to participate to GSOC? What is it? It sounds great. Can you move the slide? Okay. There we are. So starting the adventure of Google Summer of Code is a great decision. Participating and competing to be part of it will help you to enable you to learn a lot. If you make it get some nice pocket money, you will have the chance to make an impact on software that's widely used in the world. You will have many, many users and you will have a prestigious experience that you can add to your resume. So this combines a lot of very powerful, interesting things that you find in open source. And this is really the crystallization of these different aspects. I'd like to go a little bit deeper there because these are very practical parts. I'm going to use another image for that. If you embark to this adventure, this is like mountaineering. We're going to walk together with you and we're going to start an adventure to discover incredible things and help you make things that you wouldn't even believe that you were able to do in the beginning. It's a wonderful adventure, teamwork. You need to work and rely on the others. You will have to learn skills and use them. It is not a holiday. So at certain points you're going to ask yourself, why did I register for that? This is too much effort for me and then you bite on your teeth and you continue the adventure. For me, this is the best representation of what GSOC is and very important, like for mountaineering. I hope some of you have some experience there. The most interesting thing there is not the summit itself. It's the way to achieve it, to arrive to this summit. It's the preparation. It's the learning of new skills, learning to go beyond what you thought you would do. It's the camaraderie of other people you're going to meet and learn new things. So this is all together. But remember, this is not for the fainted heart. It's an effort. You need to give quite a lot. So this is a front warning I want to give for that. Can you move to the next slide, please? So remember for this adventure is not something where you just go to a counter and said, well, here I want to register for the nice mountain climb going up to Malaya and Mount Everest. And here is my money and make me a big adventure. No, you need to remember a few important things before you start this road. There are limited number of GSOC slots available because in order for you to that it's a useful experience for you, but also for the community and a good balance. We need to have good coaching and mentoring capacity, meaning that the slots are finite. We're not going to offer 12 places or 12 tracks and they will all be lousy. We're going to concentrate on what we can do and select in each of these tracks the best candidate, the best proposal. So choosing a candidate is based on the proposal. Our proposal is a general word. We need to assess in a quite short period who you are, what you can do. Do you have the right stuff in order to embark in this adventure without taking the analogy of mountaineering, killing yourself by doing a mistake or bringing the whole the whole crew of people walking with you down and that it turns into a failure. So we're going to look at the proposals. What is your experience in programming contributing to Jenkins project with the various criterias that will be used to judge and will help you to build that and go there. The other warning I want to give there, it's a long and important effort. It's not something where, well, okay, a couple of weekends, there we are excited, want to contribute and so on. Here we're talking about weeks of work to be able to build a proposal, build the experience, work on the project, finalize it. So it's a long effort. So don't start the adventure if you just have, you don't have the right shoes or you don't have the right spirit. You have only time for a day outing. Here you embark for big mountains. I don't want to scare you. I just want to warn you what you will have to do right now or like the mountaineering aspect. And this is what you need to do while we are preparing everything so that Jenkins can be accepted as a mentoring organization for Google is you need to prepare yourself. Like here before going on the mountains, you what I call you build your Jenkins muscle. That means you get into shape. You start learning, learning the product, how to use it, how to program it, how to improve it, who the people are, how do you interact with people on the other side of the world. Just that is already an incredible experience. But this is what you should start doing now, learning. An important thing there is most of you are quite young and used to school where you're told what to do. You need to do that for next week. You have that assignment and so on. Here we entering in another world. We're entering the world of open source where we want to teach you how it works. Autonomy is very important in order to be successful there. So it's very tempting to sit there and say, well, I want to contribute. I'm excited to participate in this. Where should I start? We don't have the time to explain you time and time where to start. Read the threads, read the various discussions that have already been online. Listen or read what has been done the years before. Do your homework. And once you're stuck or something is confusing but something that shows that you already in the middle of the matter, then ask. Don't forget that mentors have a job beside that sometimes very, very demanding. And so we need to focus on the help that we're able. We need to share it equally and honestly to everyone. This is what I wanted to share. I'm just going to conclude before giving the word to the other. It's an incredible adventure. You're going to learn the most and everybody is going to learn the most by the way by preparing some their way will stop earlier. Some will go up to the summit. But participating and playing the rules and learning. Everybody is going to to get rewarded for that. Thank you. Thank you. We're all good. Thank you. So what is GSOC and how does it work. So this year is going to be Google's 20th year in this program. It will be Jenkins eighth years. So participating. The project successfully has completed 35 completed 35 project ideas. What that means 35 Google summer of code candidates were mentored or participate in the program with Jenkins. And let me show you for the project ideas for this year. See if I can get out of here. Yeah. This the everything is on Jenkins.io. By the way, there's a lot of really great information on here. So I suggest that for those that's really serious and participating or wanted to get into this program read up. There's a lot of reading involved. Okay. So GSOC 2024 project ideas are here. We are still finalizing the project in the next week or so. We should have it more finalized in a better state. So check back here often. You will see things move from draft to accepted ideas. And if you're interested to find out what happened in the previous year. There's also project ideas that were in 2023. Okay. And then a good a really good place to learn what happened in those projects and with those GSOC contributors. There are final project reportings that it's done and it this is all on end of the blog section of Jenkins.io. Okay, so we've got one project idea that was completed here. And then there's the Docker base Jenkins quick start. Very detailed. And this is what you will be doing as well. Okay, so there's a fundamental build detection probe. And then building Jenkins.io with alternative tools. So there's a lot of good information on here. So I suggest for those interested to read up and learn. All right, so let me go back to slide share. Okay, so there's three important prongs to this program. It involves GSOC contributor. It involves mentors and it involves project ideas. Now, all three needs to happen and have to be in place. It cannot function one without the other. What we're focusing on here is for GSOC contributors. And then for the part of the GSOC contributor, just, you know, I just want to reiterate what Jean-Marc has mentioned earlier. What this really requires from the contributor is commitment, self-discipline, self-direct, and a lot of due diligence. So if you have that in place for yourself, we'll need that, okay, for this program to be successful. So I will let Chris take it from here with some more tips and important dates. So hi everyone. First of all, I'm going to talk a bit about a timeline for 2024. And so the first time we see on the slides from December to January, which is the period preceding this time. That's when you were supposed to build your Jenkins muscles to understand the Jenkins product, technical and ecosystem without the community. From January to February is the time to study and choose the project idea or ideas. First, we need to understand and explore it, which means to, to comprehend what a project requires, such as a tech stack, which I'll get to in a bit. And also includes journey online meetup like this one. And between February and March, you're supposed to actually build your project proposals, which would be submitted to Google for your application. And remember, open source software development relies on communication and working openly with the community. And we encourage open discussions. So we don't, we won't like any private direct messaging. And we encourage you to publish your draft, the Google doc and discuss with us or anyone within the community for review, comments, suggestions and feedback. We're also encourage you to attend regularly GSOC office hours, which is to be scheduled at around this time I think the day to the day of week to be to be determined. And on April 2, which will be the application deadline for or GSOC potential candidates. So next, tech stack. So most of the projects are in Java, some in Kotlin, some in JavaScript, HTML, CSS, Golang, even bash, or even Docker, depending on the project requirements. And for web development. I mean, I'm saying we use ASCII dog and gas beta JS, which means that for one of our projects this year, I think it's for the stat statistics. Website we've, we will use also gas beta JS, which because like our team is our infotainment familiar with the tool. And this year, many project ideas involve proof of concept work, software development and CI CD. So many of the projects involve tooling observability. Next slide. How to prepare. So number one, do do diligence, which means doing research on a project idea you're interested in. So this normally takes quite a bit of time to, to get a basic idea it takes at least one week we expect. And after you have a general idea of what the project entails, you should ask some thoughtful questions in together channels. We expect you to interact with the community. They are asking questions, answering questions, maybe, and even like providing feedback tells you those proposals. We want you to develop your proposal with the community. So we always like watching our channels. So if you have any like questions about your proposals, you want to discuss, please do it openly on the channels. We also expect you to make impactful contributions. They put requests, flexes, suggestions. Next slide, please. So the important dates for 2004 are March 18th. GSR Contributed Application Period begins every second. GSR Contributed Application deadline. And finally, May 1st, except the GSR Contributed Projects are announced. We are genuinely here to Google it from timeline, which can be found in the link referenced. Next slide, please. So reasons a good candidate may not get accepted. So in that case, in event your proposal is not getting selected, it's because of the following reasons. We cannot accept all candidates that apply. Due to limited resources with a number, limited number of mentors available to mentor projects. So it depends on whether that's a good match for you. Good is sometimes not enough, as some proposals may be bad and good. So those who are outstanding would definitely be chosen. We can submit a finite number of projects to GSR. Your proposal will be excellent, not the highest priority for a Jenkins project. But a good thing is we can always try again next year. So next, I'll hand it back to Elisa to finish the talk. So as I mentioned, this session is being recorded. I'll share the link to the recording later on. But we also have other recordings that you can find on the Jenkins YouTube channel. GSoc website, John Jenkins.io, there's a wealth of information there. Go to the blog sections. And then, as mentioned earlier, there's Gitter and discourse channels, as well as office hours recordings that we've had from previous years. So all that is available online. So right now we will take questions. If you have questions, you will have to type them in the Q&A. Yeah. So we have a question here from you who is asking, can graduated one participated participate in GSoc 2024. So what are the conditions to participate to GSoc? Pick up this question. I think that question. So Chris, you want to answer it? Do you want John Mark to answer it? Me? I can answer it because I did check. I think the eligibility criteria, one of them is like you have to be new to open source, but you don't have to be a student. Young professional is okay. Yep. The answer is yes, you can participate. We have another question here from Runak. Reading it, do we have specific communication channels for different channels? Can we start contributing now? Who is going to answer that one? I can. Do you want me to answer that? Go for John Mark. Okay. So, Runak, there are two phases that you need to be aware of. The first phase is getting acquainted to the project that you're investing your time in. There you are competing with all other possible candidates. And we want to answer these questions only once. And they're as in open source, everything is done in the open. And Chris insisted on that is we avoid as much as possible one-to-one communication channels or communication, because only one person is going to benefit in it, which is a waste of time and is not good for the other participants because they will feel cheated. When the topic gets very technical, project mentors or the lead mentor very often has a dedicated channel. Most of the time, these channel or majority, it is a dedicated gitter or element. It's a gitter or what's the other name of the protocol matrix. A channel where specific questions are answered. So at this stage, you're still on the competition contributing. Be careful there because if you start contributing on the proposed solution, that means that you're starting before it even the first race didn't start yet. So, think well where you're contributing, so don't contribute the full solution with it. But what is important is that you can and should work on fixing problems that are in the periphery of it that you learn and show that you start to master the complete environment where the particular element is. So if it's around a particular plugin starting to fix issues that are not directly in the scope of the project that you're proposing and a way to implement it, but a lot of other problems and a lot lying around. You start learning how the code works. You start learning how to use the environment you start to learn how to interact with the maintainers, which are also an important stakeholder in it. So can we start contributing? This is a good idea. Just be careful not to code the complete answer or what you think is the complete answer of GSOC before it has even started. I hope that that answer was complete but still intelligible for you. I lost track, so I see, I use things. Thank you. Alissa, go ahead. I think there's the next question is what are the chances of someone's projects idea get selected for different projects. Can I answer to that one? If somebody else wants to. The chances are high. There are between zero and infinite. So that means nobody knows. I should have prepared that but to give you an idea, normally the these information are still available in the 2023 documentation. So we had several proposals, so we had around 60 proposals that went down to four or five of projects, and we had about 10, a 10 person competing average on project. Remember, we choose the one that in our opinion has the best chance has the best proposal and a most efficient way of solving it and contributing to the open source project. Mark, do you have something you want to add there or have I been too kind in giving too many. I think I think the crucial thing for me will your project idea be accepted. One crucial piece is, is there a lead mentor who will take the who will lead the mentoring for that project. Right, because without a lead mentor, we're not going to, we're not going to run that project so part of the persuasion process and the project proposal is persuading the lead mentors like me that that idea is a good idea and it's it's good enough to clarify. So, so the competition is part of it is persuading lead mentors. Ah, I want to be involved in this or that right there. One of the finite challenges is the number of lead mentors that are available. Yeah, I forgot that nuance. Chris, do you want to add something. I really want to like raise the, but to bring up that like, like what the, what the candidates do can impact the project so it's like if you can have like, if show you have the buddies to do a good proposal if you can like suggest ideas to help bring a project to life. It may improve your chances to. Now, Shridhar has asked a question that I think may hint is a good question for others to understand the answer because it implies, I think it hints at a misunderstanding of how the project how Google summer of code works. So Shridhar's question is there around 14 projects listed in the draft ideas. When will the projects filtered after selection by Google is disclosed. The misperception there is that Google somehow chooses project ideas they do not. What what the process is, is the Jenkins project goes to Google and proposes to Google. We propose to be an organization under the Google summer of code project. Google may say yes, but then then if I recall correctly, we submit a set of project ideas that we're that we're proposing to them and they will look at and this is based on if I remember right it's based on contributor proposals that we submit right and Google then says we'll fund this many where many maybe one to zero one two three or four so our organization proposal if we're accepted as an organization that does not narrow the field of project ideas. So the project ideas is very open and the Jenkins project will select which projects ideas it finally submits and then Google says how many of them will they fund. Did I get that correct John Mark in terms of the sequence. Yeah. Yes, you're very true and somehow I misled and did not answer to do the, to the correct question so you exactly said, so there are two parameters there. We, we, we offer a lot of projects ideas and say what this could be something this could be something that can be done. Several mentors volunteered to a couple of them. It will not be the case that mentors will spread themselves in on various projects. Generally this this works out very badly, unless there is a strong mentoring team that means that on the, let's say 13 project ideas that are on the table. We're going to look, do we have a balance between strong proposals on that and mentoring team. So we will shake and come up with our shortlist and say Google. This is what we will be able to do this year. We have enough mentors, and we have a good candidate per project. This is what we propose. Are you funding that. This is the way it works. Chris, do you want to add something or mark. The crucial thing there is, and I think that ties also to Akasha's question about, hey, for plugin installation manager tool. How do we choose which, which are the right features and which aren't which aren't and the answer is we discuss back and forth in a project idea proposal in a, the potential contributor says, I think we should do this this and this. The potential mentors say no, I think the priority should be that that and that, and that bouncing back and forth between contributor potential contributor and potential mentor is how we arrive at a better plan. And we all come to a better idea of which things are most interesting and which are not. Just to jump on what Mark said this process of thinking of coming with ideas discussing together is precisely the thing that we want to teach you that you learn. And this is not something that you learn at school. This is not something that you asked to do in a professional environment. They're generally you obey orders and do yes sir your right sir and I'll call that that way. It's not the case here. We're all equal with different experiences. And we work together and think together and nobody has the definitive answer. We think together and this requires also from the candidates to step forward and show that you're you master this. This step which is very difficult and we will help you for that but it's come forward with ideas participate in it in the conversation. Prepare arguments. I think this feature is a good idea for that and that reason. And this is a weak point of that. What do you think exactly this process is key word Jesus and open source. Sorry, I went overboard again. Sorry. Great. So, so another question from Kari Noida. What are some of the hallmarks of successful proposals does the background of the contributor matter and the background absolutely matters, especially in terms of our observation of their involvement in the Jenkins project. We one of the things we're doing when we accept a Google Summer of Code project proposal is we are accepting the risk that we're going to give our time as mentors to someone who is going to be doing software creation coding. And the challenge with that is we are now relying on the fact that you have enough coding skills to do the job. And if we haven't seen evidence of your coding skills through pull requests through submissions through other other examples, we're going to be very skeptical of coding skills. Right. We we it is an unfair thing for us to say, oh, we accept your project without having first seen that you have enough coding skills to actually do the job. And the way you show that is by submitting pull requests to show evidence that, hey, look, here's how I wrote this. Here's how I did that. So your involvement in the Jenkins project is crucial to your potential being to be accepted as a contributor to Google Summer of Code. John Mark or Alyssa. I'm good. I think we need to move forward on the question and somewhere I lost a little bit. There's a question about the cloud events plugin. I have doubt from this project draft of cloud events plugin development. Will this project be rebuilt, or we have to make it from scratch. And the answer there is, we don't know. And the reason we don't know is because we haven't done the design work to decide and that's what we're looking to a contributor to make that decision. Understand the cloud events API decide if the existing CD events plug in is a good thing to transform to use the cloud events API. And the challenge there is that's of interest to potential to potential organizations like Fidelity Investments or US Bank or other financial institutions who want to do integration between systems. Cloud events is a CDF project to do that. Right now I think the crucial gap there is I think we're looking for a lead mentor as well. Yeah. Okay, we have another question here. Is it okay to start building a proposal now? Or should we wait for the finalized project list? The answer is yes to both. Oh, there's a quick one. No. What do you mean with building a proposal? If building a proposal is describing it. If building into details of functionality, the pros and cons, eventually build a prototype or a mock of the solution. Yes, you can start for it. You should publish it and make it so ask for review and so because you might attract mentors. The condition for it to be in the finalized project list is that you have a strong worked out solution. So complete. Not coded with code. So here it compiles. That's not what we're asking. We want to see the whole processing and there is a complete process to define what needs it. But it's only later that we will see is your proposal strong enough and do we have the mentors for that and then it'll make it. There is a likelihood and happened last year and I had to disappoint some people and say why here we have a lot of people that are working on these proposals but because one of the mentors had to withdraw. We already know that this project is not going to make it in the final list and we advise you to start investigating another project. You can start working on a proposal. And it is also wise to wait and observe how the things go is a mentoring power behind your project and this you can see are people reacting to the proposal, your draft proposal that you made public and other competitors. I'm going to say a little word if Alyssa you checking the time right. Yes, I am there. There is the topic probably there will be other discussions about that. Cheating one of the primary values of open source is that everything that you do is done in the open. As soon as you start trying working bilaterally or keep things for you and hide it, you build suspicion. And you start making mistakes because you're designing your own solution, which is not what the community as a whole wants. So sharing working openly is part of the system. Taking other people's idea and work on them is also okay, but there are limits to that and you need to demonstrate. It's like in scientific research. You can use and you should use other people's work. Quote it, mention it, but attribution to other people's idea is critical. And keep that in mind. So being open, sharing, teaching and learning together as a primary value of open source. But as every good idea, it can very easily be perverted. And it's a very uncomfortable situation afterwards. When we see and hear well pieces of my proposal have been copied by this or I suspect that one or and we see this kind of cripple. If this is an English word. You know what kids do when they fight over. This is a very bad sign and something will be very disappointed off. It's not easy to find a balance and I'm ready to discuss in other forms about that, but this is learning how open source works. It has nothing to do with the competition that you have at school where it's copying on your neighbor or it's school is a complete other sets of rules. And here you entering the real world of creativity. So I move to the next question. So we have about 15 minutes left. Okay. So the next question. Once Google admins approve Jenkins as a participating organization. Will there be specific number of projects ready assigned if not, do we get a chance to propose a draft I think we already answered that question. Should I contribute. Should I contribute keeping in mind a particular draft project or contributing overall in Jenkins is better. Mark, do you have an idea there it's it's at least at least for me the challenge of trying to focus your work on a specific project idea. It really narrows the field into which you can contribute. We will then not see enough code contributions from you and have a very difficult time assessing. So, if, if you don't contribute more widely than just around your project idea, you risk us not seeing enough contributions to assess whether or not you're able to actually do the project. Yeah, go ahead, Chris. So it was like, I think it's a better approach would be to focus on both like focus on developing your own job project proposals. And also like contributing overall to the Jenkins ecosystem, the PRs. So you can use the PRs in your application. Yeah. And I will add there contributing with codes is not the only thing. You need also to learn what the tool is about how to use the tool, what is continuous integration, what is unit testing, all these things that I hope that are taught in your in your schools and that you know already but these concepts should be mastered before and and because changing a comma in in a comment is a contribution that doesn't show that you know what a Jenkins pipeline is. Hey, so next question can people whose proposals aren't accepted follow along, audit the process of coding of the accepted project. Mark. Sure. Absolutely. And the open source. Right. Well, more importantly, the project, yeah, to John Mark's exact statement, the project work will happen in public. Right. The way that the selected contributor will submit their work is by submitting public poll requests to the destination thing. So last year when Vandit Singh was working on on doing documentation, it was to a publicly visible repository. It was crucial. When we did the pipeline steps doc generator it was to a public repository when we when we did work on the get plug in it was to the public repository so absolutely you can follow along. The mentors are following along. You bet. Okay, next question. Can we work on questions are moving all over the place for me. Can we work on dropped projects. If it if it's worth enough to him to impact users much better. Yes. Yes, absolutely. Open source. Therefore, what that means is contributions are come from all over in many different ways, and you're welcome to contribute. It's a good experience to learn. It's a great way for you to understand better how software development works and how open source software development works. Additional thing I would add to that is, you will not benefit from the structured mentoring organization that's put in place for Google Summer of Code. So, you need to find somebody who on a spare time will help you and so the autonomy for this way of doing needs to be or requires more engagement there, but this is a very positive way to continue learn and a very, very, very good way to prepare for the short selection session. Yep. Thanks, Sean mark. By when should we try to keep draft proposals ready. Yeah, there was a slide on that with the dates with the months so I suggest you go back into that slide and and take a look. Yeah. Hi, Aniket. Now I'm interested in the bear token authentication for get and get get client plugin. And I've also started researching but my question is, should I start building a proposal right away before the final project list display on Jenkins.io. So, that's a that's there's a secret there's not a secret there's a public piece of information that may help you on a cat. I'm I'm mark wait I maintain the Jenkins get plugin and therefore things that are targeting the Jenkins get plugin are interesting to me I'm probably also a lead mentor. So, so starting work on that is a good thing. Now, will you right now I'm a little hesitant on it because I'm not sure that what's been proposed by the user is actually needed. And so part of the research is to understand is what the user is requesting really necessary or is there another way to achieve it. Yes, you could start immediately on that kind of investigation and yes that would be a good thing to include include in a project plan. Even if the project is not selected. If you do it the right way, you will learn a bunch of important things and you will learn the methodology and think and you would be very Right. Satisfied by the adventure and get knowledge is a very useful thing in the world of software development it has get has won the battle for software configuration management and therefore everything you learn about get is helpful. Yeah. Hey, I'm interested in the automatic specification generator for Jenkins rest API because I have seen plugins like Jenkins rest, which provide convenient operation on Jenkins from the Java API. Is this job aimed at making it easier for other developers to use this plugin. Good question and it's not really about a plug in, but it is that Jenkins in general has a rest API. And what it does not and if you look at the rest API from a running Jenkins, go to almost any URL and Jenkins append the letters slash API and you'll see a nice web page that highlights the contents of the API at that point. However, that nice user friendly presentation of the API is not a formal specification of the API. And the idea here for this this project idea is it will help a number of things if we have a formal specification of that API. But that formal specification should be ex derivable from the existing code base because that's how it's done now, right each of those API entry points is implemented in some Java source code. So is it a specific plug in no is the automatic specification generator targeted to make things easier for Jenkins users. Yes. Do you want to add something. No, I'm, I think the answer was complete. Okay. I just wanted to jump on Philip glance question very is, is it allowed to stream the work on platforms like Twitch, I would say where your adults you know what you do. Now, jokingly, they have been pair programming very successful experiences working on it. It's useful in certain cases. Now the biggest challenge that you're going to experience there is the time zone difference and generally people by here in this meeting you get it smush on the on the nose with people where it's middle of the night and our people where it's the wee hours of the morning. So, live streaming and things like that. Why not, but it's, it's, there's no thing like you need an authorization and it needs to go through for ministries before it gets the stamp of approval. No, that's not, that's not the case. Yeah. So, Darren Pope and I have done the improve a plugin tutorial on the Jenkins on the Jenkins that is now hosted on the Jenkins developer pages. Improve a plug in was initially a series of live streams that we happened to record it record now we didn't do it on Twitch, but it was a series of live streams that we recorded, and we ultimately decided hey this is useful enough let's put it in the Jenkins documentation. So, yes, is it is it useful and helpful to live stream on a platform. If you find that helpful. Great. Yeah, in my case. I had to do a little more planning and thinking before I was ready to do those improve a plug in tutorials. There was quite a bit of research to understand how to, how to do the steps before we made it look fairly easy in the improve a plugin tutorial. Um, can I add to it. I just want to say, I do remember to get permissions, like, because like you, you need to know like your mentors are comfortable with idea before going ahead with it. Yeah. Always, always look at the others and think how is what I'm going to do perceive so this is there is a human dimension in all this adventure. That's very big. We have five minutes left I have here an interesting question from any kids I'm going to give a shot at. So our big contributions mandatory or small code PR. Okay. Whatever you want or do. Don't forget what we need to see. And sometimes a small PR may require hours and hours or sweat. So I remember discussion in a previous life in measuring developers performance by single line of codes. No, it's not the size of the PR. It's what we need to see is how do you master or how much knowledge do we have of the functional environment you're working in. Do you master the development language you must testing to master the basic concepts of the language that you are at these PRs are there to allow us to have a very good idea of what you can do. So, to give an extreme example, changing a comma or a capitalization in a comment is wasting our time. On the other side, a substantial PR that adds a new functionality has tests, test suites and all that that's complete is very good one. And also the PR that's maybe four lines, but it's fully fully a hand tuned and optimize and has 80 lines of tests to demonstrate that these three lines of codes do what they're supposed to do. This okay too. So if somebody wants to add. Oh, that's great. I think we have about three minutes left. So, yeah, go to the last question. I think, yes. So, can I may I offer on the last question. Yes, please. Go ahead. Okay, so the question is, I'm interested in screenshot automation for Jenkins documentation. I'll end the description of the question there screenshot automation for Jenkins documentation is a good choice for a project if you're interested in how would we capture pictures that we can that embed in the Jenkins documentation. And yes, it is vague because what you'll have to do is run Jenkins, have some way of describing to Jenkins where it should navigate, and then you take the screenshots and capture those to compare with what's already in the existing documentation. No, it's not supposed to be a plug in. It would be a separate tool. We already have separate tools that run other documentation generation exercises. And we would this would be another tool like that. And you can read the description there. You're welcome to ask more questions. Right now, I'm less interested personally in that one that I am in some others, but there may be other mentors who are interested in in mentoring it. That's it for me. Thanks Mark john marker Chris anything else to add before we end. I just want to say, this is an incredible and exciting adventures that you all are going to embark it. You're going to learn some will stop earlier. Some will go all the way to the summit. But this is an incredible adventure you're going to start. And I'm always happy and proud to be just a little piece to to share my enthusiasm about that and this great adventure I never have been disappointed is what I wanted to say. Thanks so much somebody else wants to conclude. Thanks. All right. Thanks everybody. I'll get the recording out shortly. Questions and discussion can continue on get her after this one. Thanks all. Bye. Bye bye.