 Hi everyone, today is May 19th, and after a short break, we continue the Google Summer of Code office hours just to explain what happened during the last month, there were these mentors. That means we were working on selecting projects, making final decisions, etc. And on May 17th, Google has finally announced the accepted projects. So for students and for the community, it was like one month of radio silence for mentors and talk and means, not so much because there was a lot of discussions and thanks to everyone. So finally, we were able to announce the projects in the continuous delivery foundation. And the other list of accepted projects is here. So we will have a project for cloud events or credentials for Jenkins remote monitoring and for security to be able for the next period and for monitoring. So thanks to everyone who participated in this in the application phase, we received several dozens of proposals. There will be many great proposals and unfortunately we don't able to accept all of them, like it happens with everywhere is everywhere. So before we start, I just want to thank everyone who applied, who engaged with the Jenkins community during the application phase. Because it's really important that we don't take for granted the time where you invest and we appreciate all your contributions and the participation in the Jenkins community. Which today we will talk about what's next and what you can do because this land of JSOC, it doesn't mean that it has to be end of your participation in the community there are other programs, et cetera. And if anyone is interested in the call, you'll talk about that. And yeah, what else, yeah, and of course, congrats to the accepted students. So please welcome Shruti, Harshik, Akih, Koltik and Aditya to the Jenkins community. And if I pronounce the names incorrectly, please let me know because we'll adjust, yeah, it may be difficult to understand. So yeah, thanks a lot for your time and it's great to see you in the Jenkins community. So we will have 30 weeks of community bonding and after that we will have two coding phases. So as we discussed in previous meetings, the JSOC program this year is a bit different from the previous years. It's more relaxed in terms of time because students don't work full time. They work only 20 hours approximately. And there will be two evaluation periods instead of three like it used to be since 2017. So, but still it's a Google Summer of Code and we are looking forward to it. And as you may see this year, we have a number of projects which are really important from the community standpoint, from the Jenkins future standpoint. Three of these projects are tightly related to Jenkins in the cloud, including cloud events, Jenkins Remote Monitoring, this Prometheus, and also security for the Jenkins Kubernetes operator. So these are topics which are on our roadmap. They might not be on the Jenkins IO of public roadmap because we need to update that. But yeah, all projects will be here and the whole project is very important. So this document will be updated maybe within a few days if this time allows. And yeah, also regarding other projects. So the project for semantic questioning plugin is important in terms of software delivery, like cycle and delivery pipelines. Because there is just two to nine focused on continuous delivery of Jenkins plugins and proper version is essential for that. So it's convenient for users and this project is tightly aligned with our goals in this area. And these discussions we had at the previous contribute of Summit, of course, using the Jenkins delivery pipelines. And the last one, please, the Git credentials binding project. Well, Git credential, Git plugin is used by pretty much every Jenkins instance in the world. These are some exceptions. It's a core functionality of Jenkins even it's located in the plugin. And yeah, it's also very important to have Git plugin involved. And yeah, all Citrix management credentials management again, it's tightly related to security these days. And it's very important to Jenkins users. So all these projects are very important. And we think we are happy to see this list because we would prefer to see more projects. This year we've got only six slots. So we've been able to accept all the projects and we can talk about it later. And the continuous delivery foundation, there is another project in Spinnaker, which is about try Spinnaker IO. So then you'll call, you'll be working on that. Yeah, of course, the main doesn't exist because it's not URL yet. So basically they are trying to create a way to try out Spinnaker quickly and see how it works. And lastly, we had a project by Slate and Minus about custom and Jenkins distribution service, which allowed to quickly build custom configurations of Jenkins and maybe try Jenkins IO could be also a good topic for the next projects for the GSOC or not. So it's great to see that Spinnaker coming into work on that. So these are current projects. And before we continue, are there any questions, comments from students and mentors? Yeah, so if you want to comment just unmute yourself and how basically, how whatever you want to be recording. But it's a pre-meeting, so everyone is welcome to participate. Okay, so if no questions, let's continue. And yeah, the next steps. So there are a few action items for Canadians. So we will be contacting all reject students. I know that we will be doing it within 24 hours. So this deadline has already passed, but several students still haven't received the feedback. Accordingly, apologies for that. There will be some events, which you don't have so many people in the group, but all of you will get feedback. We have collected feedback from all mentors. You've been processed by all Canadians and you will be definitely contracted if you haven't received the feedback yet. So we also work with other Canadians and these other community members to see whether you could accommodate projects in other ways. So again, we received less projects. So then we wanted, but for particular projects and for particular students, we will look for alternatives. And again, we will contact you. So we are currently looking whether you could find the projects, so whether you could find mentors either during the summertime frame or during the autumn time frame. And if you're interested, please reach out to us. So we'll see what options we have. Okay. So what's next? I hope that all students have been already contacted by the mentors. If not, please let us know, because we hope that things start working soon because a community bonding is three weeks, but it's just three weeks. During a community bonding, there are multiple topics to address and work on. So it's not just getting introduced to the mentors, but it's actually being introduced to the community. And our objective for the community bonding is to ensure that when the first day of the coding phase starts, you actually know what to do, you know how to do that, and you can basically start coding from day one. For that, maybe you have seen student guidelines, so there are actually student and mentor guidelines on our website. And these guidelines also describe what is expected during the community bonding. So if you haven't read these documents, please do. For example, for students, there are a few topics defined. And just to highlight the process, in the Jenkins community and in GSOC in general, we expect students to write the projects. Mentors provide advice, provides assistance, the expertise. But at the end of the day, these are students leading the project, and students are expected to collaborate, communicate and write activities. And if you need any assistance, we are here to help. So coming to work is not only about writing code, and we expect you to have written high-level, because it's a good experience for you. It will definitely be helpful going forward, and we are here to help. So during community bonding, what do we expect teams to do? So teams consist of a student who is a project lead, basically, and well, the leading mentor, of course, and also several mentors. We have at least three mentors in every project at the moment. There might be additional contributors joining later, or maybe union. It also happens. But the key objective for this team is to actually get ready to the project base. There are multiple items. So you will see these items on the screen. I will go through them quickly. So we define the communication channels. So we recommend that you have a chat. You can see that we set up a GitHub chat. Actually, this year, so GitHub is also something I would recommend for a chat, but you also have an option to use Slack. So we have a continuous delivery foundation Slack, and my ECM. So if you want to join, so there was a question of whether I have to be a member of OpsamX to join? No. So the problem related to the governance on the continuous delivery foundation site are dated. But for us, there is another guide here. So the continuous delivery foundation, if you go to Jenkins.io-slash-chat page, here you can see that there is a chance to see a Slack game, and this link works for an email. And if your team decides to use a chat, one thing to keep in mind that the CDF Slack has pre-account, what it means that it's limited to something like 10,000 to 20,000 messages across the entire Slack workspace, and this amount of messages currently will unlikely last year through the GSOC program. So it means that if you want to have conversation, it's during the entire GSOC, having the Slack channel is not enough, but you can choose it as an option, and we highly recommend that you could meet with OpsamX.io-slash-chat. And for Gitter, have everyone seen Gitter? Yes. Okay, so basically if you go to GSOC, the most of Project Ideas, GSOC 2021 Project Ideas, If you go there, you can see that, well, let's take Cloud events. So for Cloud events, you can see that there are few links here, that there is a link to a chat in Twitter, that there is a link to mailing please, and there is a list of linked meetings, because this project is based on the role of Cloud native sheet, which is a surprising headless, taking the name. And yeah, here, so you have a chat, you have mailing please, and we have regular meetings, which points to GSOC apparently, but yeah, actually the team has meetings every Friday, so it's just a mess in the metadata here, because yeah, we've got it fixed. But what I wanted to say to the teams, that the links you had in project ideas, you have the links for initial discussion and application please. Going forward, the teams have opportunity to decide how they treat it. So basically new mentors and whatever community you have around the project, like stakeholders, interest people, you are fully free to choose what communication channel we use, whether it's Niter, whether it's Slack, or you may decide to use something else. It's up to you. So our expectation that projects are community projects, what it means is that basically you participate as a part of wider community, not just as a small team, and if you want to get full experience of open source, this is how you should participate. So not just working in a small team, but actually reaching out to the community to potential users, getting feedback, collaborating with it's possible, because yeah, your main goal in this project, not to deliver your task, your main goal is to actually study something, learn how open source community works, improve your skills, improve technical skills, soft skills, and to have some experience. And it's not only related to students, same for mentors, all of us learn together when working on JSOC. I learned a lot when mentoring students over the past years. And yeah, please make sure to make it your priority. And of course, if we deliver some code, it's nice. And yeah, it's probably a criteria for final completion of the project and for successful evaluation, but it's not the main goal for you as a participant. The main goal is to actually study. And yeah, please focus on that together with the mentorship teams. Okay, do you still follow me? Yes. Yeah, do you have any questions before we proceed? So again, communication channels. So chat we discussed, mailing list is optional because we already have public JSOC mailing list. You can use this mailing list for let's say top level conversations for internal team announcements, et cetera. For technical conversations, we have other mailing lists. So for example, if you want to ask about Jenkins development, the best way is to go to Jenkins CI Dev because there is no point to just ask your team in the mailing list if you can ask why Jenkins is coming in. And you can see that there is a lot of topics. Actually, our developer mailing list is a mix of open governance and development. It's due to historical reasons. For now, we intend to keep it like that, but if you have any question about development, just drop it into the mailing list and we can discuss. Same for example, if you want to discuss something specific to CIT to interactive ability, you can go to cloud native CIP and ask there, it's a mailing list or there is also CDF mailing list for interactability between projects. So you can use these channels. So historically, our projects don't meet mailing list, but if you decide to so, you can totally do that. Another communication channel we asked teams to establish is weekly meetings. So we asked all mentors and students to have a first meeting as soon as possible. And the main objective was to define communication channels. So during the coding phase, we recommend having two meetings per week. At least it was a recommendation for full-time JSOC and students who have worked in 40 hours per week. Now with 20 hours, yeah, please discuss it with the teams how we want to organize and how we will organize the work because some students may want to work just full-time for one phase. Some students may want to work for two phases. So discuss it with the teams, but we expect at least weekly meetings between team members because they have been proven to be very efficient in terms of communication and experience sharing. So we don't use these meetings for status updates. Status updates can be done as synchronously in the chat. Use these meetings for knowledge transfers, discussions, again, studying together, discussing things, discussing obstacles and both in each other. But as much as if you can make a couple of communications in synchronous, that's great. But having this meeting is still nice, even if it's 15 minutes or 10 minutes if everything is okay. Okay, more on the con. So yeah, the next topic we expect during community bonding is getting to produce to key stakeholders and contributors. Again, it's not just about your team. Many other projects have communities already. So for example, if you talk about, just a second. So if you talk about cloud events, probably to this example too often, but yeah, there is cloud-intake sweep with many people participating here and there with active charts. If you talk about the Jinx Kubernetes operator, then there is even a separate select workspace on the virtual lab where there are ongoing discussions. I'm not sure whether the team will decide to use this workspace or maybe not. Actually, when I was thinking about that, I was wondering whether this workspace whether this channel should be moved elsewhere, but yeah, it's put up to the team. So same for example, for semantic version, it's like the Jinx infrastructure sub-project because again, there is an active community and we're interested to have it done. For remote, yeah, we have remote and sub-project, we have Jinx score, we have again, cognitive sweep, forget credentials, I believe that Mark will use platform sweep as a base for this project. And for what's that? Yeah, we discussed everything, I believe. So, but again, you define the channels and I highly recommend to start reaching out to the wider community earlier because all these projects have significant community value, there are many potential users in the Jinx community and there are many ways to how you can reach out. Firstly, join the sweep meetings, join project meetings or you can just send an email to the developer or do your sweep and for example, just do quick self introduction or project introduction. Another way to communicate is actually writing an info blog post, if you already have a good proposal, we see a lot of details and all of you have such kind of proposal. So you can already use community morning time to write a small blog and to speak about your experience, about your plans, which is a main focus, not to build community around the project because most stakeholders you have, more feedback you get and more opportunities for learning you have during the communication. So my recommendation during the communication is really go outside your team and have communications with more people. Any questions, any comments? So Jeff, we have as experienced mentors, would you like to say something about that? Good, sorry, go ahead. Yeah, I'm not the one who has experience here in G-SOP. Jeff is the one who has. Yeah, but Jeff, it'll be better if you start on this one. What, sorry, what was the question in all that? Oh yeah, so would you like to say something about the community morning before the question? Yeah, so I think that the important thing is to just kind of get to know the mentors a little bit, get some code out there, maybe get some stuff reviewed and kind of just sort of get the conversation going. Make sure that you're comfortable with the repo and submitting pull requests and kind of get the whole process going. Then when we're ready to start coding, we're, you know, everything's ready to go. Everybody knows what to do, how to make sure that the code gets reviewed, just kind of how the whole process works. Yeah, so the established force of engagement, I think. Yeah, that's what I was trying to say, I think, so like. Yeah, that's what I was trying to say, I think, so like. Yeah, also knowledge transfers that Jeff mentioned. You know, and maybe figure out which modes of communication work best, as Oleg said earlier, the mentors have full-time jobs, you know, we're all in different time zones. And so I know I haven't in the past been really great about keeping up on Gitter. If we choose to use Gitter for our project, I'll try that. I think during the process of just trying to get some code going, we might find out which things work best for our particular project. Yeah. So, yeah, it's actually a program for wider communities. So there are commonly two types of communication, synchronous communications like mailing please, and real-time life communications like charts, et cetera. And although in the Jenkins community, like in many other communities, we recommend to use a synchronous communications as much as possible, because everyone is in different time zones. It's normal to have something like 24 hours response delay. Also, in fact, the most of the teams use real-time communications like chats, it kind of improved these tools like Slack where you can have threads where you can actually recover these threads and synchronously. But we think about it carefully. And if there is an opportunity to move communications towards synchronous, it might be better for everyone because even students, yeah, this is one of the reasons why GSOC is more flexible this year. It's 20 hours per week expectation. Everyone can be more flexible with the current crazy times. It's important. Okay. Yufal, would you like to add something? Yeah. So considering this project is also about cloud events. So hence we were thinking maybe CDS Slack would be a better place because a lot of the stuff that is going on in the events in CDS will slowly start catching up with the cloud events plugin. So based on all these factors, it's important to understand what kind of projects would also be stakeholders in the long run. So in terms of cloud events plugin, it would be cloud events and eventing. Yeah, for cloud events, actually, the situation is even more interesting because cloud events is a clear interoperability project like you work just inside Jenkins in the Jenkins community, but cloud events is also open source project. Cloud events is actually why take the open source project and it has its own community. For example, yeah. Let's see. Where there's a community of garlands, they have their own governance, a code of ponder. They have a speed hub, a meter, et cetera, et cetera. And they likely have their own chats within the Kubernetes workspace or maybe not. But one thing you could think about as a team is, for example, reaching out to this cloud events community. I think whether somebody would be interested in participating in cloud events, they also use Jenkins a lot, multiple community members. So it might be a good opportunity for you to reach out and to think whether there could be some collaboration where you have mentors from this community or maybe you can even decide that, okay, we go and we create our channel within the cloud events community because it's better for collaboration. You can make a decision like that. Yeah. It's up to you and to the team. And yeah, I know that for students it might be quite difficult to operate on these levels because it requires significant open source expertise, but talk to mentors, almost all mentors have a lot of expertise in the open source communities, not only just in Jenkins. And yeah, please use this expertise so that mentors can help you, how organize and help guide you and all mentors have a lot of context in there so they might be able to assist when needed. So Mauricio, who is another mentor on this plugin is not present today, but he is one of the experts on cloud events. So to him, we'll be getting a lot of knowledge on a lot of other stuff that we can do once we reach like a level where the plugin can be, like we can start using the plugin. Yeah, right. And yeah, it also applies to other communities. For example, forget credentials, get an open source project. We used to participate in Google Summer of Code. They didn't participate this year, but the other mentors whom you could reach out. Well, and I met a few mentors I can help for Jenkins Remoting. It's Prometheus community. For example, they might be interested or there is open telemetry activity, open telemetry community activity growing and there was an open telemetry plugin created by Elastic recently for Jenkins. And again, it's a window of opportunity because we can use one of these contexts again to grow out reach, get more feedback and see how it works. Maybe not even during the first coding phase, but again, you have three months so that you can review the team to evolve your communication based on how the project evolves. For then, Kubernetes operators have a huge community. So why not? And this is also a topic where you can talk, for example, with the Jenkins X community because Jenkins X community also operates in the cloud native domain, Kubernetes domain. They also use the operators a lot and there might be a lot of about in this work speed and sharing. Symantec version. Yes, it's also Jenkins community. Again, it's Jenkins X community because Jenkins X had Symantec version plugin for Jenkins X. Garret Evans actually was one of contributors because Garret Evans is a mentor in this project. So you automatically get connected to the Jenkins X community and use this plugin. Sorry for this detour, but again, this is a kind of free conversation. So, yeah. Okay, so yeah, what else? So continue to discuss and plan the project. So this is an important point because what you made during the application is a project proposal and we reviewed this proposal. We made a decision, but not all proposals actually can happen as is. For example, there might be two ambitious in terms of timing. There might be two ambitious in terms of deliverables. Or after the discussion, these mentors, you may choose different architecture, different approach. It's totally possible and we had cases like that before but you as the team, you're fully free to decide how you press it. So the deliverables you defined in your original proposal, they're not slated in the stone. And as a team, you can discuss what you do, how you adjust based on how the project progresses, et cetera. And our main criteria for evaluating students is actually how they progress, whether the bound works, whether the experience of mentors is great. And as long as the experience of mentors is great, we do not really care about what was delivered to them. It might be of course a different situation if, for example, you two would have unfortunate reasons we have escalated to work at means or maybe even to the Google in the case of negative evaluation, for example, things like that happens. We can discuss it later because it hasn't happened in the Jenkins community yet, but I was involved in other communities where we had these escalations and discussions. But yeah, if you want, you can continue and right now let's focus on positive side and the positive side is you have an opportunity to adjust during the community bonding. Use this opportunity and if there are major changes, major discoveries during the implementation, again, you can adjust. For example, there was a project where mentors and students did the first phase and they realized that the project is just unfeasible, not implementable due to things related to the student and they basically chose another direction. It wasn't in Jenkins, but in Jenkins we adjust projects a lot. So don't hesitate to do that. And again, students as leaders, they're basically eligible to make it a final call. So mentors provide advice, provides input, but it's up to the students to make it a final call if there is disagreement, etc. Does it work for everyone? So yeah, there is a lot of text there, but yeah, again, take a look at this page later. An important topic to set up your development environment, computers, etc. And for projects which require cloud access, also think about your environment. But it means that if you need something specific, for example, with Kubernetes cluster for cloud events, for Jenkins separator, or if you need other environment, talk about it with mentors earlier, because me as a project don't expect you to pay for this environment on your own if you need it. Me as a project will do our best to provide assistance, but to do that, we need to know about it earlier. Because yeah, we have budgets, sometimes we also have to create accounts, sometimes there is a lot of bureaucracy involved, so together with teams, with community bonding please talk about what you need. If you need something from the Jenkins project, from the Jenkins organization, please let me or Kara or other partners know, and we will do our best to provide it. So again, the goal is to be ready to start from day first. So for example, if you need a repository within the Jenkins organization with permissions, let's create it during community bonding. If you need specific licenses, hopefully not because everything we do can be done with open source but just piece all these topics let's resolve them later. Questions? No questions. So yeah, learning discusses the process with mentors. We discussed it basically also for engagement we have mentioned. We use Jira to track GSOC tasks. So this part is dated as well. I will remove or replace that over the previous year we adopted Github issues in many projects. We officially opened the cloud gates. So for example, if you go to Jenkins Kubernetes, if you go to many other plugins like configuration as code they use Github issues. And at this point there is no sense to enforce any particular task tracker. What we ask for is the Jenkins community that for your own benefits please create tasks, please track them because it helps you to stay on track and well many teams do it in production many teams do it together. It's up to you you can descend that you follow Scrum, you can follow Kanban, you can do whatever works for you as a team. But yeah my recommendation is to keep track of the tasks because it's helpful for you because you can agree using the tasks you can agree on the definition of done because how we usually approach the Jenkins project and this as well that the definition of done is not just you roll some code but it means that this code is delivered this code has test coverings this code has appropriate documentation etc. And our approach again not working in a parallel branch for months and merging to the last day of GSOC we recommend well continuous integration because we talk about Jenkins. So try to break down your tasks to small items talk about criteria for them and common pattern with your mentors and try to deliver as often as possible so for example you have a feature to it if it fits in this thing no pull request even if it's one line documentation fix or if it's something like 100 clients etc. It's fine. Please try to avoid big pull request because they have to review, they have to deliver and they are also hard to integrate. We want you to integrate often and again talk to your mentors about how to establish this process and for example in my case yeah I also have a dashboard for Jenkins community physical one because yeah my memory is quite better at the moment but yeah just why not so I see that Kubernetes operator has a project there so yeah maybe it's not the best example but yeah if you want you can create boards like that within GitHub issues or within Jenkins Jira and as a team you just decide what approach you want so you have freedom of how you define that and our main aspect is that it's public so that you can onboard contributors and orphanages have access to it if something is needed from us but how you implement it, how you price it it is totally up to you and yeah just try some more industry practices because again you study here so if you want to try agile development etc. and the mentors are up to that, why not okay questions okay and the last part for community bonding is actually knowledge transfers so again being able to start earlier so if there are specific domains you want to discuss with the teams so for example for cloud events plugins it will be reasonable if Mauricio does introduction to cloud events and we can also do it for the entire Jenkins community because why not again if you can go to wider community do it if it doesn't slow you down and for other projects if you need specific knowledge transfers talk to the mentors as often as well as happy to organize sessions on demand so in previous years we used to do sessions like how to develop Jenkins plugin etc. all these sessions are recorded by now I can share links if you need and if you need something specific or if you need to discuss one of these sessions live because you have some questions let us know again it can be just your team if something specific you can use one of your meetings for let's say knowledge transfer for pair coding which is also a really great technique to get started and consider it why not so something like that if you need knowledge transfers let us know so what else we have regarding the next weeks and that we need to run in place so we have this office hours we will have this office hours to have organizational level questions and discussions we don't really use them for project discussions these meetings are optional so if you have any questions please please join I would like to start a doodle poll but we can choose new time for meetings if this time is not comfortable for students, for mentors or we can have sessions in different time zones depending on the interest but yeah this meeting is optional and do not use this meeting for asking questions, do not wait for this meeting because for example you can ask your team or you can ask again the Gitter channel for JSOC so no need to wait for this meeting if you have a quick question just ask right away our main objective as mentors is to ensure that you don't have blockers and that you don't have anything to deal with so we will try to help so we can use this meeting for all discussions then if you want to show something or share your experiences you are welcome to do that okay what else, yeah I send a request to the students for project pages so you can see that here there are projects from 2020 they will be the same list for 2021 soon and here you can see that there are links to students so why it's helpful because it helps to quickly navigate through content through history etc there are also profile pages and we ask all students all mentors to fill in these profile pages so that we can easily ask you to the list so here you can see three roles, students, mentors, advisors so advisors are basically non-mentors but people who contribute to the projects as stakeholders sometimes help and if you want to introduce more roles in the projects please do so but this how we organized the projects before students create a profile so some of you have already submitted full request and thanks a lot for that if you haven't done it yet please do another thing which I would recommend for community bonding is to submit your first full request if you haven't done it yet it might sound a bit odd because calling starts on June 7 but actually by submitting the first full request you can evaluate the process, you can check the environment, it's okay you can also start just ramping up in the project and it doesn't have to be big requests, just whatever and the main projects have newcomer-friendly issues published if not discuss it with your mentors and start from there because it's again a good opportunity to have up to speed does it work for everyone I summarized all I wanted to tell yes already it was a long discussion we don't have rejected students on the call so for rejected students I will be following up in the mailing list to save everyone's time and yeah so question for anyone would you like to discuss something would you like any feedback do you need any additional information to proceed I just wanted to say thank you Oleg for giving us an overview what's next so from my end for those of you who don't know me I will be mentoring together with Jakub and Sylvia Crenetti's Jenkins Operator Project so we'll make sure everything is aligned with the overall schedule we'll make everything transparent as much as possible and in case of any questions we'll retell to you guys so yeah thank you thank you too any other comments, questions so students have been super silent during this presentation again you can see the US full community members so as mentors etc just feel free to interrupt ask any questions anytime so there is no formalities to follow and if you have any questions if you need any clarification then if not let's just continue hi Oleg I have a question yeah sure thank you so much for the presentation and my question was actually if you remember one month back we discussed about changing the name of the project from semantic versioning conventional comments plugin I wanted to ask about that so I think we have time till 25th of May to update it on the G-Stock website I got an email regarding that so what would be a good way to discuss this with the community and go ahead and make the changes the name and concept is rather a method for the mentoring team yeah you do planning you do adjustments based on whatever discussions you had based on whatever discoveries you had so just discuss it with your mentors and it's enough if it requires wider discussion then feel free to reach out to the Jenkins community etc so for example if you decide to rename Jenkins Kubernetes operator to something else I think that it requires wider Jenkins community but if it's a plugin that you create, I think you can just discuss with the team and start from there okay got it, thank you okay any other questions, comments so yeah if you have any questions again ask in JSOC Peter ask in mailing please ask your team members and yeah all of these approaches will be working fine next meeting till the next week but no need to wait until then yep again thanks to everyone for joining JSOC thanks for joining this meeting I hope you will be a great experience for you yep let's make sure that you also have fun study something so thanks all and looking forward to working with you this year thank you thanks thanks all thank you thanks all bye