 And we're live. Hi everybody, welcome to the Google Summer of Code status meeting. We have meetings every week in order to sync up on the project status, on the application, and this time we decided to record this meeting so that we record some Q&A and guidelines for students. I'll share my screen so that you can find the links if you want to join. Okay, do you see my screen? Yes. Okay, thank you. So, if you're interested to participate and to know more about GSOC, please join our Gitter channel. It's Jenkins.ci slash GSOC-seq. And here you may see a link to the ongoing hangout session. If you have any questions, you can just follow the link and join the discussion. There are also meeting notes for the today's meeting. Today we have a few topics in the agenda. I would like to give a quick update about GSOC 2019. Then let's have Q&A from our mentors and students if they're in your professions and then we will review all the project ideas, application dogs, and sync up on our action items. Something like that. Does anybody want to add more topics to the agenda? This is good for me, Oleg. Okay, so let's start from this topic. One interesting thing that yesterday we have got an announcement of Google Summer of Code. If you go to the website, you may see that, okay, there is a GSOC landing site. You may see that there is a timeline and you may see that the deadline is set to February 6th. But even now, our organizations can apply. And actually, as a GSOC org admin, I have already created an organization profile. I haven't put the information yet, but I invited all org admins. So Martin, Jeff, Lloyd, please join. Actually, we are waiting only for Jeff. But we need at least to org admin to apply, so we are more or less good here. And our next steps would be to fill the organization application and organization profile. But the good news is that we already have all the documents, so at least a draft of all documents posted on our website. So if you go here, there is a link to GSOC 2019 application draft. It includes all the information we need to submit to Google. And I would appreciate any feedback from all participants. If you see something missing or if you want to propose changes, please comment on this Google on this page and let us know or you can just propose pull requests and we will accumulate them. So there are definitely some changes we need to make before we apply. But anyway, we are more or less ready to submit the application and I propose to do it maybe today or tomorrow after we discuss the application docs. So we have a draft in place and we proceed with other stuff. So it's a quick update and you may have seen that we already started getting some queries in our mailing list from students. It happened because GSOC 2019 has been also announced for students. And now they explore organizations in 2018. They see Jenkins organization there and they navigate to our resources and ask questions. So please be prepared to have more queries from students over the next weeks. And this is what was our goal. So the dark mode for GSOC ends and now there will be a lot more public communications. So yeah, this is a quick update. So yeah, GSOC starts. That's all I wanted to say about it and we will return to the application documents later. If there is no questions, we can just actually start the discussion of topics. We have some mentors and students on the call. So we can proceed with the questions and then we will return to the application site. So do we have any other topics to discuss? Especially we need. Christian Vuitton, do you have any questions as mentors? No, I think we're okay from my side. I'm excited that students are starting to contact us. That's good. Yeah, I started preparing a list of active students. I have ten names there. Awesome. And there was a lot of minor queries happening. So that's cool. And actually even now we have more project ideas than in 2016 and 2018 all together. So I hope we are good. We also have a lot of mentors and we will be publishing more project ideas because not all of them have been published so far. And I think we are really good with GSOC this year. And let's try to get much of it in terms of contributions and in terms of fun, of course, because GSOC is an opportunity to have a lot of interesting activities for everybody. Yeah, definitely. I also talked to some of the Evergreen team and I know that they wanted to do some stuff or have some project ideas. So hopefully they're still able to kind of draft something quickly and have another opportunity to have something out there for a proposal. But I know that they haven't done that yet. So let's see. Yeah, regarding the timelines, we are still open for any kinds of project ideas from students or from potential mentors. It would be highly preferable to have project ideas proposed by February so that we put them on our website until the application period finishes. But actually now it's the interest of mentors to propose the ideas as soon as possible. Because longer if these ideas are available on the website, they get more traffic, they have more questions and you get a better chance to get students. So we invite all mentors to submit project ideas as soon as possible so that you have them posted. Definitely. And yeah, having Evergreen idea would be definitely fine. So let's see. Evergreen can generally benefit from many of existing project ideas. For example, cloud features for external workspace manager, it can be used in Evergreen right away. Unfortunately, I have missed the cloud meeting on Monday, but Jeff Pierce was there. So maybe he will summarize his discussion later. But yeah, such ideas can be easily adopted to projects like Evergreen. Okay. So any other questions? Yes. Okay, bring it on. So I would like to, I'm gonna try to attend the meeting today with Andrew. Wow, which one is it? Pipeline authoring. And so with pipeline authoring, I was hoping to get closure on the discussion that has happened regarding the REST API plugins. Jesse made some recommendation on how to proceed with those plugins. But he also alluded into the Jenkins execution engine. So I want to see if the pipeline authoring people have more to say on that. But is there other topics I should bring to that meeting to the pipeline authoring signature meeting? It may make sense to just talk to them about the project ideas. We were discussing some potential project ideas like pipeline doc, an engine for generation of pipeline documentation. It's a follow up to the project idea you and Christian had. So maybe it would be one of the angles to discuss. And yeah, actually, whatever pipeline project is something we could do. And I see that there are also some questions maybe related to pipeline maybe not I haven't processed them yet. But yeah, having pipeline proposals and especially proposals around development tools is something which could help the project a lot. So if we have mentors list, let's have such project ideas. Okay, so I'll pitch the JSOC 2019 as well. Yeah, I mentioned something on their channel, but I never seemed to get any type of response. And they only have meetings every once in a while. So it's not as I figured there was a lot of things that that group could do. But yeah, it's not a hill battle sometimes, but it helps to build awareness about JSOC. And even if we take a list of current project ideas, yes, a lot of these project ideas have been created by JSOC or card means acting as champions, not all of them, but many, but you see, we have a lot of potential mentors who are interested in the ideas. So if you, Christian, or if you're Martin, are interested in a particular area, you can just draft a week right up of your project idea and propose this right up. It may it may already help me because then the people just need to say, Okay, I like that I will be interested in that. Please send me up. It may be even more efficient that just my opinion for random project ideas. Oh, yeah. Okay. So it's just to give you an idea. I did the same today of the configuration as code meeting on the morning. And I believe further was also discussion at cloud meeting. So if we continue talking to people, we may get more people interested in participating in the projects. Yeah, I made a quick pitch at the cloud needed sig meeting. There was one question somebody asked what the timeline was. And I said that we need ideas now probably in February is when students will start contacting us. I interpreted the silence as maybe they're not being a lot of interest right now. So probably, probably good to keep pitching it I guess. Yes, we'll need to watch the recording of this meeting because yeah, I'm interested to understand what the general trend for Jenkins X and cloud native Jenkins. As we were discussing at the last meeting, it can be significantly interesting what we would like to propose in this area. Because now there is no Jenkins X proposals. We would be interested to facilitate the discussion and to have some. But yeah, it would be nice to understand the vector taking them by its maintainers. Yeah, so I has like James about it in here back. I'm not able to attend their meetings. If someone else want to attend. I did add just generally for project ideas into their agenda, their ongoing agenda. And my understanding is their meetings are has been every other week for an hour. They're thinking of switching it to every week for half an hour. And their meeting and genetically are about demoing their progress work in progress and what their deliverables are. So it's more tactical in nature. Mm hmm. Yeah, I'm not. So it would be great to keep poking them. So yeah, let's see, maybe we'll have some outcome regarding cloud native special interest group. Actually, I would say that even if nobody is interested, we have some proposals, we should definitely target the server. So cloud features for external workspace manager. Then we have external fingerprint storage, which is a mapping of pluggable storage, removing kava patch Kafka, I believe it also falls into the area of cloud native C. So yeah, it was about sending an email to the SIG mailing list and listing project ideas we already have in progress. So maybe it could facilitate some discussion. So I'll try to do it tomorrow. Okay. Anything else here? I assume not. If you have any questions, etc. Let's discuss them at the end of the meeting. So we will have some time. Let's take a look at our action items. So slugs. So it's still open. I haven't done it yet. It's totally my bed and my technical depth. Then regarding other six. So we are starting combated and hardware and EDA special interest groups regarding hardware and EDA, we already have two projects regarding the embedded SIG. We don't have projects so far, but I have some ideas. So maybe we'll also raise this topic. But yeah, the six will be published this week. All of them might actually approved by now. And yeah, creating checklist is also something on my table. Jeff, I have a question to you about the expense report. Um, yeah, I still need to submit that. I'm sorry. Yeah, well, there is no time pressure, but it would be nice to get it finally finished. Yeah. Okay, regarding the rest of action items. So we had an action item to support published status with Google Doc as a body. So it's something we have actually done. So if you take a look at our proposals, many proposals have been published as Google Docs. For example, working hours, plug in its project idea from Jeff. Now we just but Google Doc in the application, and we consider it as a published document. The biggest advantage that students can just go here and say, for example, Okay, something like that. What is react? And actually, you can discuss project ideas, just from the application documents and project ideas page, you don't need to navigate anywhere. And I believe it's quite helpful. And we also have made an increase charts and the references on each project idea. So I think that this format is generally fine. And probably we don't even need to bother with the moving this project ideas to ask you to form. What do you think guys? I think they're really cool thing. That's very nice that we can direct the students can ask directly what they have questions about. And then it's you can, it makes it a lot clearer. That's really helpful. It's a good idea. One of the things I would like to do here is to actually have anchor for project proposal, so that when a student opens the page, it doesn't open here, but it opens right here. But yeah, the problem that this links, they actually don't have. Yeah, there are, there are actually links if you open it in Google Doc, but these links are unique for each document. So we can just reference the header by text in Google Doc, which is quite weird. But yeah, I think we can leave even without that. Yeah, I'll explore options maybe I'll modify the logic so that we embed somehow with an anchor. So it starts with visualizing not from the metadata but from the original proposal alternate way. Once the projects are published, we can actually just move metadata to the bottom. And then it should be also fine. Yeah, that sounds like the easiest text, right? Yeah, so if you agree, we can just do that. Yeah, yes. Or maybe we can even modify a project template. Oh, yes. That's the easiest. And if we do that, so let's see. Maybe we still need to have a summary on the top. Oh, yeah, some result already available here. Project rule. That's exactly the summary. Let's just try opening it again. Voila. It's actually what we needed. Yeah, the question about the I guess the stock in the template, it looks like the file name in the title are two different fields. So I ran into that difference in another proposal. Are they just redundant then? Because they appear twice. Yeah, this title is different than the file name. Do we even need the title if we the file name is being rendered? No strong opinion. I can even rename the document from the embedded here. Let's go. Yeah, because they both appear so no. So I can answer. Yeah, I don't have a strong opinion either. I guess it'd be nice to have one less thing that can get out of sync. And I mean, just reading it, I think you can see the title. It's pretty clear. So yeah, I like it. Okay, remove. Yeah. Okay. And then we can just say it will probably not remove it completely. But something like here. Title. So something like that. Does it work for you? Yep. What's the list? Yeah, would be somebody available to update the project proposal template accordingly? I can do that. Do you mean all of them, Jeff? Or just so we can update Google documents. And we actually need to update the template. So there are two separate action items. I can take care of the template. Or if I don't I don't care, I'll just do I'll just do whatever is needed. Okay. Okay, I can I can go through and fix the existing documents, I guess. Suggested that every champion is just his own documents. Okay. No title, title in the metadata. And yeah, we just look at the working hours, a proposal for for an example of the new format. I mean, so example, we just modified working hours. I really like it. We can edit Google Docs from the embedded page. Yes, nice. Yeah, it's even better than just a key document. Maybe we should switch to this format. Some pages. I have no idea. Well, it's highly susceptible to spam, like someone could spam. So it can be spammed so easily. Yeah, right. Well, I think it's fine for project ideas. And they're supposed to be discussed. And we don't allow edit by edits by everyone. But the comments are publicly open. So everybody is welcome to comment in any project proposal. Okay, I think we are good with that. Yeah. Regarding the rest here, should we review the current project ideas status? Or do we have any other topics to discuss before? Last week, I tried to post the Python related things to the, to the mailing list. But then they see it told me that I mean, we should not. You mean the Python one? Yes, yes. Oh, yeah, Python one is complicated. So regarding Python, thanks a lot for doing it with one. Actually, yeah, we'll be reviewing collection items. It should be somewhere in the bottom. Okay. Yeah. So this one is done. Okay. Sorry, it's here. Regarding this. So regarding Python, what Jesse replied to that we shouldn't touch Jenkins Pi. It's pretty much what we discussed last week anyway, because Jenkins Pi is quite updated. But Jesse wasn't against other topics. So like Python Jenkins, he's fine with that. And yeah, what I did here that actually I listed other plugins which are related to Python. And then I secede their current maintainers who might be interested. But yeah, so far there is no response. It would be nice if we can could get something there. But yeah, so far there is no feedback on which we couldn't iterate. I think we still need to wait if somebody is interested. Yeah. So one of the plan Bs I have is asking in Jenkins X channel about the Python specific build bugs. But we need mentors, we need mentors who know Python. So it's not me. And we need a project ID, which would be actually interested, interesting to the community. I think that whatever is listed here is something doable, but we need to get people interested at that. So I think for now, we just wait. And maybe if anybody has any ideas how to get more traction here, it would be helpful. So maybe some tweets, etc. later. Actually, I can help with that, I think. So what I can do is like to try thinking in Twitter or whatever. But yeah, I think that for now, we generally wait. If we are lucky enough, we may get a feedback. Now, but only if you want to propose something on your own, it would be also a possible way. Yeah, maybe. Okay, let me take a look first. Yeah. I don't think I never experienced Jenkins with another language. So yeah, let's see, maybe we will be able to figure out something. I had a special hope regarding warnings next generation plugin, and probably a last call after the call. But yeah, maybe something, something like that. Okay, more action items. So let's take a look what we have here. So I believe that we try to ping in pretty much every project. So this one is just kind of ongoing for right now. Other action items we have a ping in a rick about a git lapis him. I believe I pinged rick somewhere and he's he was on the call. Yeah, I'm here. Oh, yeah, just don't see you. Oh, yeah, you're Mr Jenkins today. Okay. So did you have a chance to take a look at the feedback? Yeah, I think maybe we we got enough feedback for now. What do you think? Yeah, we definitely got enough feedback. So my question here was that this feedback hasn't been incorporated into the project idea yet. So I mean, there was a discussion whether it should be git lab plugin or whether it should be a new plugin. There was a discussion of what would be else in the scope. Yes, it would be nice if we, for example, just summarize results of this discussion, and somehow reflected them in the proposals and then market as resolved. Okay, do you think there are some changes in the proposal to be made? Not exactly. Okay, so I think that what we could do is something like, so what we did is one of Martin's proposals last time, we could say something like that open questions. It would be possible to just write a short summary of the discussion. And let's say that there are multiple ways to implement the task put to the existing plugin, the white students to explore options or reflect them in the proposal so something like that. So we do need to resolve this question per se because yeah, there are maybe other options. But yeah, what we can do is we can say that yes, we acknowledge that there is an open question and we invite participants to explore that and justify their approach in their proposal, which could be a good starting point. What do you think about such approach? Yeah, I think it's fine. But I have another question. For my opinion, GitHub, multi bronze pipeline and big bucket multi branch pipeline, they don't have an interface to construct, how to say, I think a way maybe should consider an instructor can interface for the multi bronze pipeline. So it's something like unifying interface for branch for branch source plugins. Yeah, they are already we have get EA and beat bucket and GitHub. So I think it's bad, it's best to make an interface. So something like get hub bucket data. Sorry? Yes, it's right. Yeah. So it might be useful to generalize the functionality. Yeah, for example, shared interface API, etc. It may be part of the project proposal. Does it look good to you? Yes, maybe we can create a new plugin for the interface. Yeah, it could be a part of SM API or branch source API. Yeah. So SM API plugin. So, okay. Should be multi branch SM API plugin, because they already have SM API plugin. Yeah, but yeah, I think there's functionality could be put in a SM API directly, but yeah, on a new multi branch SM API plugin, something like that. Yes. Okay, so yeah, maybe such approach could help to get this proposal over the line because yeah, we just reflect comments, we also offer students some additional content so they can use this information as a source for their ideas. So yeah, it would be nice. And actually, if we could close these comments in such way, even without making a technical decision right now, because that's why we have community bonding. So these approaches may be defined by students and their proposals and they all can be defined here using community bonding. But yeah, we can go forward with that. And in addition to that, we would still need to have new be friendly issues. So my question to you is, would it be possible to find some of such issues? Maybe another branch source plugins? I do not, I haven't to do the research. So I have no idea for now. Okay, so the question is, or is there such room? Okay, there is. So yeah, we can reference it. So yeah, a question to other work admins, would we be open to publishing this project idea without any different issues? It wouldn't be my preference because I think when people are just sort of exploring, doing development Jenkins, it's nice to have have something that they can actually do. It's tough because if we create a new plugin that obviously there aren't any, but as Oleg suggested, it could be, maybe we can find issues in other branch plugins. Yeah, let's see. Plop, plugin. So let's just try something. If it works, we are fine and the labels will be, okay, all right. Okay, so let's take something like that, GitHub, branch source, a bit of bucket, branch source, doesn't work so far. What else did we have on the branch? API doesn't work. Yeah, what we could do is we could just take a look at the repositories and if we find something, you could start from there. What would assault mic concern be if we could just find, if we find a generic set of new BF new B friendly issues that just anybody that was interested in Jenkins development to do that we can reuse those. Actually, it's a nice idea. So yeah, we could default to that. So here we go. Yeah, maybe it's also an option. You're right, Jeff. It does seem like we get a lot of people that just kind of get started. So having something that enables them to start working on something is better than nothing. Okay, I totally agree. So yeah, we could start from putting the default query. Publishing could be eat and then when Rick has some time to review issues or maybe when there are some requests, we can create a sample query dedicated to the. Does it make sense? Yeah. I would have both in all the documents. Yeah, the default query and the specific queries for the project. Well, what I could do so we could just modify our project ideas layout. And we could put the default query there. So Jenkins IO projects, JSOC project ideas, whatever. So we could actually put it here. Or maybe we could just put common links like participate, new different issues. Would it help? I think so. Maybe in the future too, definitely for next year at this point, because we've already had some brawling getting into the process of getting projects, but maybe it would be worth a while to have a page, like a landing page for students that is like, how do I get started in Jenkins? And even if it's just kind of directing them to the website section of getting started with Jenkins, it's better than, it's like a good place to start. So you have a question rather than being lost or confused or trying to look around or, because we know where to go and what to look for, but maybe just having everything in one place would be nice. So here I take an action item probably Hummel. I'll probably create a Hummel JSOC project idea. Yeah, let's see. It's not really a coding language, I would say. What's the Hummel? Hummel is a template language for, for websites. So if you go to this page, improve this page, and here is Hummel. I see. So yeah, it's not bad. It's just a more couple of language, yeah, which you can use. It's, so Jenkins uses our struct and Ruby ecosystem for static website, and yeah, Hummel is a part of this system. Okay. So, Kristen, you say that I have a generic newbie guide, right? What was your proposal? Oh, sorry, yeah. Just to have a generic newbie guide, so how can I get, I'm a student. I want to do Google Summer Code. How can I get started? Well, but generally we have this guide, Project JSOC, students. Okay, cool. So we have the guide here, eligibility, expectations, first contributions, useful links, selection process, so a bunch of stuff. So it would be good to put that link to the, to the project ideas. Yeah. Oh, here. Yeah. Yeah, totally makes sense. Just so, on the project pages, they can have a reference of where to start. Cool. Now it was good, that page, just so it all is connected. Thanks, thanks Oleg. Okay. Okay. I will do it. Yeah, if somebody doesn't want, if somebody wants to study Hummel, you may guess. Yeah. That's fine. So let's, we have seven minutes left. I propose to take a quick look at the application document again, and then return back to the project proposals. What I actually ask, we have this description, and I ask everybody on the call to spend some time to review the documentation. And yeah, there are definitely some changes we need to make. For example, we have almost 20 mentors now, which is cool. But yeah, it would be great to get your feedback what we can improve in this documentation, what we can simplify. And we have three weeks to finish this proposal. Okay, so do you want to, do you want to, do you want this proposal to be entered online before we review it? No, so my proposal would be to spend, for example, one day. So let's spend 24 hours to review it. And after that, if you are more or less finding with the current state, let's put it on the JSOC website. So right now, there is no time pressure to edit this information. We have several days, but having staged something early wouldn't hurt. Now is this application process like the other, I guess, we can keep editing it until the deadline? Exactly. Okay, but only one person can edit it at the time? Exactly. So we can just agree that, for example, maybe on a rotation basis, or we can, so we spend 24 hours, make changes, review the document on our side. And then, for example, we get another one week iteration. And after one week iteration, somebody just applies the diff to the application side. Does it make sense? Yeah. Okay, then 24 hours, let's assume that tomorrow, at the same time, somebody starts publishing it on the evening. I'm happy to do that. Starts publishing it. You mean send the pull request for changes or enters it in? In the system. Okay. Let's say, I'll just do it after the working days or something like 6 p.m. UTC, gen 17. Okay, something like that. Okay. Does it make sense? Generally, we all review this document with JSO core card beans. So there shouldn't be anything to be there. But yeah, having more eyes would definitely help. Okay. Sorry, what's your meaning of the forced draft? Sorry? I didn't know what's your meaning of the forced draft. Sorry, I didn't get the question. I think Rick is asking what is the meaning of the draft of the application to Google? What's the meaning that we have everything in place? So it means that firstly, Google sees that we are kind of ready. This is one of the benefits and other benefits that we know that we are ready. So if something happens, we already have something staged. Generally, my intention is to have a green flag here as soon as possible so that JNKINS is a project that we just set our intention that we are serious this year and we have everything in place. That's it. Does it answer the question? Okay. So the meeting is almost over. We can go maybe five minutes over time so to quickly check other projects we haven't discussed yet. And then does it work for you or should we close right now? It would be good to discuss one or two projects. Okay. So let's take a look first at what hasn't been published yet. So Artifactory Rest plugin. Martin, what would be the steps here from your point of view? Oh, for this one, now that I have direction from Jesse on how to... So the difficulty with this plugin is the proposal says that, it almost says that we would be returning complex objects to the pipeline but effectively steps should only return serializable data to the pipeline and I think methods don't fall into that category. Methods, no, but fields do fall. And so the rest API is kind of a nested thing. So to access a field, you almost need a hierarchy and on the technical side, I'm not sure how to do the hierarchy but I don't want to make everything flat either because that will just make one gigantic response going back to the pipeline. So that's the biggest technical question I have here. We could push it to the student proposal to explore, I guess. Okay, but in such case we need to summarize the discussion here. Oh, what I just said, you mean? Okay. So maybe something like open questions or so, like we did with GitLab. Okay. Current. So yeah, once it's done, I'm happy to publish it as a draft. Yeah, currently I was a bit his system because well, we just didn't have a description which could be consumed by a student. If you summarize the discussion, if you maybe provide some examples, I think we could publish it. Okay. It's actually the status is currently draft. It's published as draft. No, Artefactory isn't published. No? Oh, okay. Yeah, that's... So other project ideas has been published, Artefactory wasn't. So he's bit bucket, he's Jenkins REST, but no Artefactory. Did I miss something? Okay, so let's go next then. Pipeline step documentation. Do we do something like conversing to pipeline doc or whatever? Or do we give it for Google season of documentation? So this one's weird because I think that there is a lot here that would be better for that Google season of docs because really so many of the... I think what would make this a lot better overall is just having more information about what you're actually putting in. Because you'll go to some of the pipeline steps and it will literally just be the name of the command and just parameters are like string, string, string, with no context for what the step does at all. It just exists out in the space. So to me, that's more of a documentation problem. But Martin brings up a good point here with the... There's no... Right now, currently, it's not obvious how the step works. And part of that is just kind of it's really... That's a technical challenge and it was kind of really hard to build it unless someone included it in the documentation. Like this is physically what the string looked like. So it's kind of like this is a half and half. But if there's... There are some types of technical... To me, technical things are pulling in from where people have documented stuff but sometimes there just isn't documentation to pull in. So it makes it a little challenging. Yeah, would it help if this project idea is discussed at the pipeline ottering SIG meeting? I think so. Because maybe it would be a good way... To proceed. Yeah. What do you think, Ratni? Yes. I want to attend today's pipeline ottering SIG meeting and talk about this project idea and I guess get feedback from them. I doubt they would supply a mentor. Yeah. But we never know. So and plan B is to convert it to something like pipeline doc we were discussing. But yeah, it's up to you, Martin and Christian. So I propose we keep it as is for now, but yeah, let's see if we can still convert it to the project. Sure. I mean, worst case scenario too, it would be interesting to have it as a summer of docs because there are missing some... Yeah, summer of docs hasn't been... Just because it is missing so much documentation. Yeah, right. Okay, let's scroll down. Then we have Jenkins Remoting Monitoring. Maybe I'm not sure. Have I already mentioned the pull request? If not, you can probably just integrate it. Oh, I have already... Here's it. So, Vuitton, did you have a chance to take a look at it? Yeah, I just tell you a little about this. I think it's good to me actually. Okay, so I'll merge it once you approve it here. Oh, I cannot approve. Everybody can approve. So you can still approve. You will just get a gray tick instead of the green tick. That's it. Oh, okay. Because just now I... Okay, let me tell you a little. Okay, so let's assume this is published. We have two other project ideas. One is configuration as code plugin compatibility. So, Martin, it would be great if we could publish it as a draft. And I hope we have all necessary information in place. So there is a documentation. We have some potential mentors who might be able to help. And we have all the information in place. So I think we could just publish it. No, I think it should be published as... Not as draft, but just published. No, okay. We can actually just publish it as well. Because, yeah, we discussed it. Well, we can continue facilitating the discussion. But we definitely have enough information. I'm just editing the proposal. So it complies with the new format we discussed. Oh, yeah, absolutely. Okay. So something like that, project proposal. I'm not sure whether it's not relevant anymore. Oh, yeah. If you are finding this published and it directly is published, I'm also finding that. Yes, it looks complete mentors and everything. Okay. Yeah, let's do it. And yeah, regarding Jenkins Windows Service, this YAML configuration support. So, Jeff, are you finding this being a contact or admin here? Yeah. Okay. So we all just integrated. And the same question, it would be nice to get it published at least as a draft. Mostly because of diversity of our offering. Because this proposal has another technical stack and Java is even optionally clear. Yeah, I'll submit the... I'll fix up the document and submit a proposal to make it a draft. Okay. Okay. So it's something like that. Okay. So I will say it a bit. Okay. And I believe that's it. We still have some unsubmitted project ideas. So we had this... So Python related discussion. We also had a discussion about one of the core functionality stuff, plugin management tooling. So the reason I'm interested to have it as a project idea. And yeah, I think that we might get it over the fence. Last week, I just got over to the... There is no really idiom like get it over the fence. Over here. The correct idiom is get it over the line. Okay. So I just edited and I'll convert it to the GSOC project idea but maybe for the next week. Okay. I think that's it. If you are missing some project ideas, et cetera, please add them to the Google document. But I think we are already good in terms of what we have published. Yeah. So asking through the application draft looks good to me generally. I think there's something somewhere about if we were to add Jenkins X, we may have to change the organization aspects. I'm in the middle of a slack conversation with some folks in Jenkins X and if there's interest but they won't have the proposal immediately available, how should we go about in our submission? I'm fine with putting Jenkins X right away. But yeah, the trick that Jenkins X is no different from configuration is called plugin because Jenkins X is a sub project at least from the Jenkins standpoint. I do not mind if we list all sub projects in the application. Okay. So I don't have a proposal from them yet but we can, we don't need to amend our organization submission that if we get a proposal from Jenkins X much later. Well, I think we can amend it right now. I will just amend it in a way that it's not like Jenkins or Jenkins X. It's like Jenkins and all its sub projects including Jenkins X. Got it. Okay. Yeah. And then that way we may or may not get a proposal from them either way or organizational application will still be okay. Okay. Something like that. Then we also need to change mentor number. I believe we are going to have 20 plus. I still need to calculate it but you have many mentors for this time. Yeah. I mean, until I get a champion and with a proposal from Jenkins X, I don't want to account for them right now. I just want to make sure it doesn't change our organizational application. Yeah. Let's do that. Okay. Thank you. Okay. Thank you too. And so, any other topics to discuss today? I think from me. Nothing from me too. Yeah. Maybe starting from the next week, we should switch meetings to two ones. One is public open office hours for students and mentors and another one maybe for Orcal Means in Cup or Mentors in Cup so that we detach this topic to separate meetings. Yeah. I think we can discuss it later. I just feel the meetings get a bit long. So we do two half hour meetings instead? Maybe or we just keep office hours like one hour in the current time slot and we detach some routine operations like proposal moving around and checking status, outreach status to another slot. I'm not sure. Or maybe we can try keeping it as this until we go over time a lot. Either way, it looks for me. Okay. So thanks to everybody for participating in the call and looking forward to more conversations. Yeah. If you're a mentor, please reach out to potential students and potential commenters and community channels because more visibility we get, more good projects and more good students we get. And it's our joint interest. Thanks again to everybody. So have a nice day. Okay. Thank you. Take care. Bye-bye. Thank you.