 Yeah, very good. Hi everyone. Welcome to Google Summer of Code office hours. We reconvene after a short break due to Christmas and New Year. So today we have our common agenda. We will have some time for Q&A in the beginning so that students and potential mentors who came to ask questions have opportunity to do so. And after that we will have standard project meeting where we will discuss application status and other things. So you may see that the agenda is still being edited but I think we could start. So does anybody have any questions about GSOC, about the application process and whatever? So we can start from that and update agendas if needed. Is it Jeff? Sorry? I think that is Jeff. Jeff, can you meet your line please? I'll mute him. Got it. Oi. Sorry. It wasn't Jeff. Sorry, Mark. Okay, that happens. So yeah, if anyone has any questions, just put them in the chat or just unmute yourself and ask because yeah, the main purpose of these meetings is to answer whatever question you may have. Okay, so let's then go through the agenda. So there was item one person needs to be the note taker. Who did put it? I can take notes if nobody else wants to. Yeah, usually we just do it together. So multiple people have access in this document and anybody can post changes. So when somebody speaks others can just make notes. But if somebody wants to do it officially, please do so. And I could take notes if you do. Yes, whoever wants to write them down. So open action items. Yeah, it was quite a break. So we didn't meet for two weeks or three weeks. Two weeks, right? Yeah, two weeks. So we have some pending action items. One is JSOC 2019 results blog post. So that's still on me. It's in my whole of shame. So yeah, I was busy in December and I just underestimated the number of things I need to do. So I didn't finish it. And my apologies to Martin and Marki who spent a lot of time. But yeah, I hope to find this and the patches. So yeah, by the end of this week, it should be done. If you need any help with that or like please let me know out there. Additional reviews will be needed. So one of the problems that since the blog post was deleted, it needed some updates. And when I did some updates, I also then we had Jenkins Vault and blog post needed updates again. So yeah, that's how it happens. Anyway, yeah, by the end of the week, it will be submitted for review. Other thing, we need blog posts by students. So we had three students who went to Lisbon and we expected them to publish blog posts. Currently it's in progress, but we need to do something. Just a well-centered reminder later. And okay, any other action items here? Yeah, travel reimbursement. So all students have submitted the expense reports. Maybe no, Parachay didn't submit this report. But a beauty and long did so and it is maybe reimbursed. And you Mark, you also submitted the expense report, right? Yes, I've already done mine and I've also reached out to Parachay and I just reached out to him again. Okay, thank you. So Parachay and to go. So yeah, I also didn't submit anything so far. Okay, what else do we have in the list? Yeah, there was a bunch of action items, but I believe that almost all of them are addressed. So if nobody calls other action items, we should have done. I think it's fine. Okay. So what did change since the last meeting? So we will go to official announcement of Google Summer of Go to 720. So now if you go to the website, you can find that there is timeline available. So this timeline is detailed enough. And here. So yeah, basically we start applications in less than one week. And that's why I brought up the topic of this application status because we have a draft idea, but we might need to update this draft a bit. And after that, we basically have time. The rest of the schedule is basically the same as the previous results. So yeah, there are some deviations between these. So here you may see that basically community bonding and coding, they start earlier this year. So mid-May, it's already coding. It's almost two weeks earlier than in the previous year. So I wonder whether it's aligned to this everyone's plans, but yeah, I think we can do it. Okay. So regarding other updates, in the end of January, there will be FOSDOM. At FOSDOM, there will be GSOC table and GSOC meetup. I wonder whether anybody goes to FOSDOM this year? I may go. I'm still working with my internal business, my company. Yeah. So where is it? In Brussels. Oh yeah, I won't be able to go. Yeah. For your information, Marky, we will also have a contributor summit on January 31st. Okay. That may be a good selling point for me to my executive staff. Yeah. So if you go, it would be great if you also go to the contributor summit. I can send you an invite. It will be a small event being compared to Lisbon. In Lisbon, we had more than 80 people, but more than half of them were actually users of Jenkins contributors. And here we do a small event, which is specifically focused on Jenkins key projects, including various features we want to deliver also as a part of GSOC and also infrastructure community governance. Maybe one of the outcomes here, there will be more project ideas. At least it's my plan. So I guess that's it. So nothing new. Does anybody else have updates? Oh yeah. Let's just continue. Okay. I think this... Hello. Can you hear me? Yes. Okay. Actually, I did a couple updates. I contacted... If you scroll down in the action items from the previous... That we had in previous meetings, I contacted... I think... Let's see. I have to scroll down myself to see it. The infrastructure team, I sent an email to their mailing list to announce that essentially to infrastructure, pipeline authoring, platform, and Jenkins UX. All those four places, I posted the JSOC 2020 announcement. Yeah. That is great. I have not gotten any response or reply. Well, it was a Christmas period. So for example, that's why I didn't really do anything to the developer mailing list. I did that on January 3rd. So that was Friday last week. It still counts as Christmas for lots of people. Exactly. So anyway, we already have enough project ideas to apply. We have project ideas to get published. But we can spend some time in order to facilitate more ideas. It was a wrong blog post. Sorry. Yeah, this one. What else do we have? Yeah. In my case, I also spoke about JSOC at multiple meetings. Basically, all SIG meetings and sub-project meetings we had there since this time. So maybe we'll get some outcome. But right now, no specific project ideas are submitted through these channels. I also got an update from Akare about JenkinsX. So their plan is to actually apply as a part of Jenkins. This year, so they are going to propose two project ideas. So if they do it, then we'll just send an application and also reference JenkinsX in the description. Is it fine with everyone? It's fine with me. So far, it's not a big deal to get more ideas published. Though, again, we might need to work on our project ideas list. Because last year, when we got to 30 project ideas, it was quite difficult to find anything. So yeah, maybe some more refactoring would be nice on the website. Yeah, let's see. Actually, that's it. Unless there is anything else, let's move on. Okay, project idea submission process. Okay, so we have it here. Yeah, maybe some more changes in the process were passed to these. I'm thankful to Martin for updating to this process. So right now, the recommendation is to do the most of the discussion in the developer mailing list. And we use JSOC, GitterChannel, and the mailing list just to do some sanity check in order to ensure that the idea is fine. And then you're expected to proceed with a seek mailing list or developer mailing list to discuss the technical side of the project idea. After that, you're expected to submit a pull request. So we keep all project ideas in the Jenkins IO website. Yep, so there is a link in the guideline, which basically points to the list of the current 2020 project ideas. And you can just submit more in the same format. Main difference from the previous year. In previous year, we were mostly using Google Doc. Here, our preference is to proceed with this website. So you put a project ideas on the website just as a ski doc. And you can still reference Google Doc for additional details. But you would rather prefer a body to be visible on the website directly. Is it correct, Martin? Yeah, that's correct. Both Google Doc and the content of the A Doc file are good. But the Google Doc is optional. So you can just submit a pull request and get the idea discussed in the pull request. Exactly. So what we have now, we have more than 10 project ideas. We got students reaching out regarding these projects. But all the ideas published here, they're basically transferred from the previous year. We have some discussion in the main piece proposed by Mark White and Rick. But yeah, we still need to get them published. Here, the most of the ideas now come from Google Doc. So like that. But instead of that, the recommendation is to just submit a pull request. We have after that. So basically that's it. So once pull request is submitted, Jenkins, JSO court documents will review it and integrate the changes on the website. All JSO court documents have write access on the website. So we can deliver to the changes quickly. So that's the entire process. Mark, do you have any questions or do you need any clarification about the process? I don't think so. Let me play back to you what I think my steps are. So I chose the optional path of using a Google Doc. It's been reviewed and discussed. We'll review and discuss it a little further here. The next stop for me is after our discussions here, submit a pull request. Preferred pull request one per idea or bundle two. What's the is how high is the bar to have a pull request accepted? Now, I don't think there is a specific bar. So what we have on our website, we have draft project ideas and we have final project ideas. So there is a bar for accepted ideas. We have an expectation that all accepted project ideas will have new different issues that they will have some explicit description how to quick start with this project, how to explore this project. So here there is a bar. But for the draft project ideas, it's fine to basically submit whatever you want. And actually, I even had a proposal in mind to just allow referencing made increased discussions here as a first step. But it's an open question. But submit a project idea you don't need to spend much time. Great. Thank you. Okay. So next stop for me after our discussion today is pull request. Thanks. Right. And also to start the discussion and the developer may increase because there might be a lot of people interested. Well, no, no, so the ideas that I was specifically bringing are already on the developer list as mailing list topic. So agreed developer because I thought it's on the JSOC. Oh, good question. You're right. I'll have to double check. Good point. Okay. And now I guess one of the points where I need some guidance specifically is on the mentors. So it's preferred that the mentors are confirmed willing to act as mentors before they're listed as potential mentors, right? Exactly. Okay. So that's, and so that's an open gap for me on two of mine. I need to talk with two or three candidates before I put their names officially into the pull request as potential mentors. Okay. One of, so one thing I will add to that mark is when you speak to the potential mentors, I would highlight, underline and bold to them the time commitment that they need to spend being an actual mentor. So they, so they understand that going into it and they don't, you know, we don't have problems with them saying, oh, I can't dedicate the time and then we lose, we lose traction on that project and potentially have a, you know, conflict. Yeah. Okay. So we have some expectations listed here. But yeah, here's explicit expectations about time dedication. And yeah, I guess what we need to do before this phase ends is to add expectations from mentors per phase. So it was one of the retrospective feedback from the previous year because some mentors were confused about community bonding and also students were confused about what they expected to do because some mentors were not reachable due to reasons basically out of control in the community. So we will need to explicitly list the expectations here and we will expect mentors to commit to this plan. Okay. And now as I'm looking at this page that's on, there's in the conflict of interest prevention, it looks like I need to be sure that mentors are using either spare time from their personal time or time that their company is authorized as contribution to open source. This isn't, okay, great. Thanks. All right. So I need, I had not read this page and I'm not done it clearly enough. So thanks very much for having it. I will use that as my baseline. Thank you. The other important aspect here, Mark, is that is that the JSOC project that mentors mentor, you cannot, for example, for me, it cannot be a deliverable to my employer. There would be a conflict of interest if I had that. So I have to make sure that the JSOC projects are not part of any internal roadmap at my company, internal roadmap that I have for myself with my employer. Well, just a bit specific. So it's fine to have personal investment in the project and actually we encourage that. But yeah, what Martin tried to say is that basically there should be no commitment because JSOC projects may not succeed and if you put this project on the critical path in your company, then it won't end well. Right. And so I think in the spirit of that, I was interpreting Martin's guidance as this should not be a feature that my company is creating that I'm going to lend to the JSOC effort to do it for us. It's really, this is something independent of my employer's interests. And but interesting to me personally, and in my case, my specific ones are intensely interesting to me personally. So yes. Yeah. So we hear some examples because yeah, when we started JSOC in 2016, it immediately became a big concern in the project. So there are some examples and you can start from them. Great. Yeah, basically our expectation that the project idea has value to the Jenkins community, that it's open source, et cetera, et cetera. But it's fine or probably fine that a company uses it because well Jenkins basically is based on contributions and the most contributions come from companies. Okay. Yeah. So in my specific examples, I think they are okay here because this is not the ideas I've proffered are not roadmap entries on anything my employer has offered. So I think I'm okay, but I'll safety check that with a couple of internal people first. Good. Okay. Exactly. Okay. So I just put links here. Any other comments with regards to this topic? So one comment, especially for students on the call that your project ideas can be proposed not only by potential mentors, but also by students themselves. So it means that if you have an idea about what you would like to change Jenkins, you can definitely do so. Although we will need to find potential mentors. And if you have a specific idea in mind, please let us know about it early so that to be happy for a time or to help you just making it happen. Yeah, absolutely. For the students that are online, I also want to emphasize that JSOC projects are your projects primarily the list that we offer is projects that are of interest to the community. But by all means, if you have ideas on how to improve Jenkins, whether it's plugins or core or UI or anything related to Jenkins, if you have ideas that you don't see in our list, most definitely, you know, create a project idea and submit a pull request. There's there's a difference between project idea and a project submission for the student. So the project idea is just the difference between the submission and the idea is that the submission is the student application to participate and as an intent to implement the idea. And the idea is just a more general sort of project where multiple students can apply. So can you expand a little further on that from my benefit, Martin? So an idea from me as an idea source is not necessarily a fully detailed project plan. It's not fine grained. It's much more coarse grained. Is there something else I've missed? Exactly. It's an idea. Yes. It's it's specified in general terms. It's not a detailed specification. It's not it's not a detailed project plan. This that comes later and it's actually something the student is expected to work on and create part of their community bonding is is creating the detailed plan. So students will first write an application towards a specific idea or towards more than one. A student can submit multiple applications. I think there's a maximum there that that Google will will limit. You cannot have a student applying to 50 ideas, but the student can apply I think to three I think is the maximum. Yeah, I thought they increased it back to 10, but I need to double check the documentation. Still the number is related below. For example, we can just take a look previous year. For example, let's take one of the projects. Okay, let's just take the first one, multi branch pipeline support. So here, for example, we have there is a lot of documentation, but yeah, there is GSOC proposal. Listen, I project by Perichay. So this is what he submitted to us as a part of his application. And well, it's rather an exceptional case because yeah, this is a relatively long proposal. Usually we expect something maybe three to four pages. But yeah, this is an idea which was submitted by student after all processing, kept discussion in the community after some prototyping. There was a lot of discussion for this project. But if you take a look at the project ideas, the idea was relatively simple where it is was people upright. So here was the project idea. So it's just one page maybe a bit more which summarizes the expectations. And yeah, this is our recommendation. Give students freedom to select the implementation to select the approach they want to deliver on. Because yeah, basically, they are driving the project. It's not something like we hire people thanks to Google's consortium to deliver on our projects. That's one thing to keep in mind though is that there is an expectation that the students are going to be coding full time for about three months. And so even if you're not going into detail, it's probably a good idea to try to make sure that's going to be the case. I know in particular the one that I proposed and met her last year, I don't think it ended up being weighty enough that the student had to work all that hard. And there was some concern expressed. However, he proposed the project and we accepted it. So whatever he did as long as he could complete it was fine. And so we want projects that are media enough that the students are going to be working full time. That makes sense. So I'm taking from that that it's okay that I bring out what I consider to be hard problems. And failure is an acceptable condition here. And it's okay that I put something up that's difficult enough that I think it will be a stretch for a student to complete. Great. I like that. That is correct. Yeah, so definitely. And like, sorry. Yeah, Ruben's one potentially could be open-ended. And so it's up to the students to kind of dig into that and, you know, write a good proposal that would benefit the community and also, you know, make sure that they work hard for the entire time. All right. So Mark, if you want to have some examples, you can just refer to previous years. There are project ideas which basically have different formats. Some proposals, for example, this is a pipeline support for a multi-build plugin that explicitly says that it's potential tasks. So you can take a look at this list. And yeah, you can realize that this list probably a one-man year of work. Maybe not, but still it's pretty big. But it gives potential students freedom to choose what the topics they would like to focus on, what skills they want to get, what technologies they want to study, so they can take this proposal and build their own project. And it's okay that a student may select a subset of the idea for the final proposal. And then the Jenkins project accepts the proposal and the mentors work with them on the proposal or work with them to implement what they have proposed. Great. Right. So yeah, and the proposal may be completely different from project ideas. We had some cases where basically alternate solutions were proposed. Yeah, we do reviews during the student selection process. So there is a place when we choose projects. It's basically here. So it's one month since March 31st to April 27th. So this is the time when organizations review these proposals, require slots, map slots to students, and they will be making final decisions about the proposals. But at that point, we won't be able to edit anything. So it's our joint interest to have a lot of discussions here. So after, well, basically starting from now until the deadline for student application, there will be a lot of discussions with potential students about project ideas, about project that they propose, and many students submit their project drafts in advance so that they can be reviewed by potential mentors. And it's possible to steal their projects and provide feedback so that they become realistic. So yeah, I guess that's it about project ideas. So if someone wants to discuss specific ideas, we can do a key study at the next meetings. And again, once the project ideas are submitted, we will be doing reviews as J. So Corker means to help potential mentors to appropriately represent their project ideas. Any other questions regarding this topic? Hello, I would like to ask one question. Yeah, sure. Are these projects are from scratch or any work is done on them or anything is done regarding the project? It depends on the project idea. So some project ideas offer completely new projects, create a new plugin, for example, create a new feature. Some project ideas may be targeted towards improvement of existing functionality. For example, Mark proposed project ideas for Git plugin, which exists, well, since the very beginning of Jenkins, I would say, and there are still opportunities to do something like performance and performance. So it depends on the project. Thank you. Can I add something to it? Yes. So basically what I want to ask is, as a prospective student, you know, in a particular project, should I start doing some amount of work to show that I know what I'm talking about, right? Like how familiar I am with the project. Or is it just that I just have to be clear on the theory aspect of it, that I just need a good proposal and that's it? Well, we do not strictly require students to contribute to the project before Google Summer of God starts. But the realities that all accepted students, for example, last year, contributed to the project in advance because it helps them to create good project ideas. So our approach is that for every project, we have some new different issues referenced from the proposals. So let me take this promotion plugin again. So we do not expect you to do random contributions or whatever. We expect you to explore project ideas. And as a part of that, creating some more pull requests, trying doing some prototypes or maybe some minimal issues would actually help you to create a better proposal. So that's the reason why the most accepted projects actually have history of contribution. There's also the community bonding phase, which happens before project selection. And that's one way to get to know people in the community is by doing some pull requests. Yeah, but it's after the project has been accepted. Oh, sorry. Yeah. So it's also a part, important part. But the project idea you explore them basically kill much 31st. Oh, okay. Thanks for that. Yeah. Thank you. Okay. Should we move on one? Or any other questions? I would like to ask one. So these pros and cons are given on website, right? So can you start making proposal right now? You mean application or what? Do you want to propose you? Yeah. Yeah, you can start working on them earlier. So how it usually happens, you have seen this proposal from Perichay. Usually students submit a Google box in advance so that the people can review them. So for example, once you explore the project idea, or once you have an idea of what you would like to do, you can submit first initial draft to review in the mailing piece or to your mentors in the charts, and start getting some feedback. And it's recommended. So if you already know what you want to work on, you can start right away. There is no need to wait till the application starts. This date is just the first day when you can submit something on the website. That's it. For some of the projects, like I was interested in the Python and machine learning one specifically, there weren't any suggested issues, right? So what would be a good idea to, you know? So yeah, if you go here, you can see that there is somebody who has fun on this project idea. That's one of the reasons why we want to move to Jenkins.io project ideas in ASCII.doc. Yeah. It's not good looking. Okay. So yeah, we'll move them soon. But yeah, the idea that even if there is no project ideas, there are content things. So for example, here there is mailing piece, there is a chart, and you can see that this chart points to a specific chart to this project idea. So if you don't see anything to work on, you just follow these links. And here you can discover that there are people, including Marky, who is on the call. And you can just ask if there are any tickets or tasks to consider and what areas to explore. So if you don't see something, just go here and ask. Okay. Awesome. So maybe if we have some time after these topics, which is not possible, we can probably spend time on the machine learning. And you can also ping me and get her if you have specific questions in that machine learning channel. And I will be happy to help in any way possible. Thank you. Thanks a lot. Thank you too. Okay. So let's move on. So the next item was get plugin project ideas from Markweight. So Mark has submitted two project ideas. Mark, after the discussion today, do you have any open questions? Or would you like to get some feedback? I would love to hear feedback, but I don't actually think I have any specific questions. I think that the one that you had on screen there, this one fine too. The repo caching one or this one. So the plugin performance improvement one, there is it's less likely to be a full three months of work, but there are many, many things in this general area, which could be done and discovered as a result of it. The microbenchmark harness will likely expose all sorts of things that can and should be improved. And the redundant fetch thing is probably a month or more of work because of the complexity of retaining compatibility. Exactly. So what you could do, so you could probably write it in a more open end I think. So even probably merging three ID, at least topic into that project idea as well. I don't know. It could be separate project ideas as well. It depends on how much independent they are. But if you write in a way when basically it's up to the student to make a proposal, and he, for example, remove redundant fetch is just an example when it. Okay. Yeah. So I'm prone personally to keep them as two separate things because I think of them architecturally as quite distinct. The repo caching thing is introducing some concepts that don't exist and has all sorts of blocking and file system access challenges that are hiding behind it. Whereas the performance one is more focused on alternatives and choices which can be made inside the implementation, how to improve the specifics of details of the implementation. Okay. Yep. So I think. Sorry. Go ahead. Yeah, I just wanted to say that I think that this project idea is already to go with project ideas. So yeah, maybe some form of thinking about the communication channels. But yeah, I think that it could be submitted. Okay, great. Now on the communication channels topic, there are many of the many of the others use a separate Gitter channel to have high bandwidth low noise communication. Has that generally been the preferred thing for most of the GSOC accepted projects that they have their own Gitter channel dedicated to that specific GSOC project? Historically, we have a lot of traffic in Gitter channels. And since Gitter, while we is far from ideal, in terms of communication experience, project opted out to separate channels. So there are some exceptions. For example, for all strategy plugin for promoted builds, we don't have so much user traffic in the charts. So we just use the these channels for GSOC. But in your case, if you talk about a good plugin, then you would need to think what to take. So it could be, for example, platform six channel, but platform six channel is pretty active. So discussions and questions from students may be lost here. Okay, so so in my case, it probably is best to create a new channel for the git plugin and hide place both the top or those topics in it. If there's some additional traffic, great. But it's okay if I create a separate channel, great. Thank you. Yeah, right. So basically, there are two stages. One stage is application process. So it's whatever happens until the student projects announced. So this is a time when students come ask questions. And there is not that much development development happening by this time. At this point, it's better to use existing channels to avoid creating new entities. Well, unless you feel that having a Gitter channel for it would be helpful anyway. But when community bonding starts, so this is when the active project starts. And basically, an accepted student works almost full time during coding. And during community bonding, there is also a lot of work serving for mentors. And then this time, during community bonding, teams just can select the best communication channel for them. So in JSOC, we don't set the strict requirement what to take. And you will be able to select what you want. Okay. So yeah, it's better to have something more standard. But if you have a specific need, for example, if you want to work on different integrations of this Kubernetes ecosystem, and you want to go to Kubernetes Slack, it might be different. It might be possible. But it's up to a mentor team and the student to decide. Thank you. Okay. Okay. Any other questions before we move on? None for me. Thank you very much for the help. Thank you. And also, my next steps are to create two poll requests, one for each project idea. And I will probably hoist one more project idea into the list for conversation. Great. That's great. Thank you. Okay. So the last topic is Jenkins JSOC application route. So what do we need? We have an application. Basically, it's almost copy and paste from the previous year. So it was adjusted to reflect new content. It's more or less ready to be submitted. But if somebody wants to make adjustments, let's do so. So when I submit my poll request to submit a project idea, if I think it's worth including in this application, I should also put into the poll request a change to this. No, I should not. Okay. No, because what this application is doing, it's referencing our proposal link, which is where your PR will go. So you don't need to do anything to this, per se. Just your PR will go to proposals, which is already linked as Oleg has highlighted it. Yeah. Well, it might make sense to do some edits. For example, if you have huge community interest around deep plugin project ideas, we can highlight it. For example, hearing long description. So we had a long description here. I just cut it from this year. So we say this year we invite students to join the Jenkins community, whatever, whatever. And here we can provide specific examples if you want. Another option is to edit proposal text. Because proposal text is one of the ways to discover projects on the JSoc website. So again, if you have a lot of ideas related to Git, we can put it here. So we are limited to 10. So if you add something, we also need to remove something. Right. And okay. So with that upper limit of 10, when I look at that list, I think those lists, those things are much broader than Git. They're much likely to be much more interesting, many of them than Git. So I would tend to leave mine off that list unless we see significant interest in the ideas. Okay. Thanks. Oleg, can I ask you a question on the tag for electronic design automation? Yeah. What is that? What does that fall for? What is that? Math too. So we have two project ideas, which were transferred from the previous year about hardware. Okay. Okay. Okay. Now I remember. Thank you. This is the risk five ideas integrate with various EDA tools. Well, there is no risk five here. If somebody wants to offer a risk five project idea, I'm all in. But yeah, so we have a project idea for EDA coverage adapters. So basically, we're using the project from 2018 by a change. And to implement coverage reports for EDA tools, which is a quite hot array now. And another one is just a generic proposal to have integration with whatever. So this project ideas are still around. That's why we have this tag. But yeah, last year, we got some interest, but to be honest, not that much. So again, this text can be a subject for discussion. But for us, if we don't put a tag here, there is basically no chance that this project ideas will be discovered. So it's something we can discuss. And obviously, all this text, if you want to improve something, please do so. Because yeah, this text was polished a bit, but it would be great to get some feedback. And for example, there are some topics which we will need to think about. For example, DevOps world Jenkins world. One of the topics is that it won't be Jenkins world anymore next year. So it's an open question whether we want to reference to this specific conference or whether we want to talk about other events, for example, CICD summit. So yeah, this is also a subject for pollution before we submit the final application. So by the beginning of February, we need to finalize that this process. Any questions about that? Should we, I was going to highlight that, or like software in the public interest, are we under the continuous delivery foundation as well? I believe we should reference both in the current state. So yeah, it's partially a part of the ongoing Jenkins board discussion. So we had election in early December, and now there are knowledge transfers being organized. So the current state of the immigration to continuous delivery foundation that this immigration is not over. So for example, SPI hasn't transferred to that trademark yet to CDF. There are also other things. So formally, we are still a part of SPI. But yeah, according to our website, we also are part of CDF, as you may see. So I believe we should just reference both here. So yeah, if you see bits like that, just comment in the chat so we can edit it. We are coming up to the top of the hour. Exactly. So we should start closing down. So the last topic, we had project ID status, but basically except what we discussed, there are just some ideas floating around, like ideas submitted by Rick, also some ideas proposed by me. What we need to do, we need to start putting these ideas on the list. Because this is the list according to which Google will judge our application. And we definitely want to have new project ideas being compared to 2019. So whomever has project ideas in mind, please spend some time to start drafting them and submit them. And Oleg, again, the application date to the timeline to Google begins next week already? Yeah. So next week, the application is open. The deadline for applications is February. But yeah, so basically by the beginning of February, we want to have as many project ideas as possible in the ideas accepted list. So for these ideas, it's a relatively small thing to do. We just need to convert them to a ski dock, maybe to apply some copy editing. And they are accepted because all of them already comply with templates. But for new project ideas, yes, we need to go through the hoops and of course, just have a draft, have discussions and to move them to a separate stage. So it's important that those of us who are submitting project ideas get them in quickly, because we've only got maybe a few weeks to go through the process to get them from draft into accepted on this page. Great. All right, I'll get my submitted. So there is no strict deadline as February 8th. So February 8th is when our final proposal goes to Google, but final proposal reflects the application draft, this one. And it just includes a hyperlink to the project ideas list. So we can keep editing the project ideas, we can accept new project ideas basically until the student application period starts. But earlier you posted this project idea, more chances you have to get the students reaching out. Because as you may see from this meeting, there is also really a lot of students on the call. There is even more students reaching out to us and get their channels. So if you post your idea earlier as a potential mentor, you have higher chances to get more traction for a project idea. Great. Thank you. Okay. So I guess that's it. So thanks to everybody who participated. Yeah, this meeting was a bit long and we will try to keep the next meetings to 45 minutes. But again, in the next year, we will first in the next meetings, we'll start from point A, and then we will be able to proceed to the project update topics. Thanks. Okay. I've noticed some questions in the chat. Do we need to discuss them? I've tried answering as many as I could in there. Okay. Thank you. So if anything is still needed, let's just sit in the Gitter channel. Yep. Thanks a lot guys. Thanks everyone. Thank you. See you online. See you all next week. Thank you.