 Hi, everybody. Thank you for joining the Jenkins Online Meetup. Today's topic is Google Summer of Code, the Mentor Roundup Edition. My name is Alyssa Tong, and I'm the Jenkins Events Officer. Along with me on this webinar are three other Google Summer of Code, Org Admins, Chris Stern, Bruno Barakton, and Jean-Marc Mason. So some housekeeping items before we begin this session is being recorded. We'll share the link to the recording after today's session. If you have any questions, feel free to put them in the chat window throughout the session. Our Org Admins and or mentors will respond to them accordingly. We also have an active GSocGitter and discourse channels for further communication. So feel free to join the conversation and post questions there after this webinar. And lastly, the Code of Conduct is in effect here as well as throughout the community. Simply, it means just to be nice and kind to people. So today's agenda will cover the impact of a GSoc Mentor, the busy time period of a mentor and a high level task list for mentors. We'll go over project selection criterias, some communication guidelines, and lastly, take more questions, if any. So in 2024, which will be in a couple of weeks, we'll be Jenkins' eighth year in Google Summer of Code. That's if we get accepted. We will be one of the 150 open source organizations under this program to help bring new developers into the open source software development community. So there are three major components to a successful GSoc program. Those are mentors, project ideas, and GSoc contributors. This program can't function without one or the other. So in this webinar, we will focus on the important, but often hard to find mentor component for this program. So from here, I will let Bruno take over a couple of next couple of slides for more details. Thank you, Ulissa. So we'll see rapidly what it means to be a mentor, at least to me, but I will try to follow the bullet points. First of all, first and foremost, it is a great human experience. You may be there to grow up in your technical skills, but you will grow up also with your soft skills because during the Google Summer of Code 2024, you will help new contributors of mentees grow. You will help them become better technically, but you will also help them grow with their soft skills, communication skills, writing documentation, and so on. So you will change through this process as well as the contributor of the mentee will change too. And it's a unique opportunity to share your passion for open source technical subjects, everything about Jenkins that you already know. You can do that through the Jenkins forum, for example, on GitHub, on the various Jenkins channels, but frankly, being a mentor for Jenkins and Google Summer of Code 2024, it's something different. It's a tighter way of communicating. And frankly, if there is a project that doesn't trust you in the list of the subject proposal for next year, go ahead and try it. Frankly, if you want one of these subjects to progress next year, Google Summer of Code is the way to go. And if you've been in the industry for quite a few years now, it will maybe give you some remembrance of things past. We will be able to believe when you started yourself. Maybe you had good mentors when you started in IT, maybe not, but you could be a help, a real help for newcomers in the open source world or the Jenkins ecosystem or the IT in general. By being a good mentor, you can help young people to become better and interested in contributing to open source, for example. It's also a good time, think about your practice. Where are you in your career? Why do you want to share? Why you want to take some time to teach, to mentor? You have something that you want to share. You want to reflect on your past experience. That's also a great opportunity to step back, to gain perspective and to transmit, to transfer your knowledge to somebody ready to go into the IT industry. And I said as an introduction that you will also be transformed because it will improve your skills as a mentor or a coach. Maybe you already had some interns where you are living in the industry you work for. But frankly, having somebody from a different culture, from another part of the world in a different time zone, practicing a different language, that will teach you a lot of soft skills that you maybe don't use on a daily basis for your day work, for example. So frankly, you will become better at communicating. And as you don't want to look like a fool when working on one of these subjects, of course you will do your homework and you will try to put some light on the shaded areas of the subject that you are interested in so that if ever the mentor or contributor has some questions, you may be able to answer or to give some hints. You're not supposed to be the know-it-all, the master, the greatest of all time regarding the subject, but you have to know a minimum set of things about the subject you want to address. So you will also become maybe better on the subject you will address. Next slide, please. And you may ask yourself, okay, I will help someone grow, but what is a reward? The first reward I see, I already talked about, that you will grow also. You will become better at communicating. You will become maybe better on a few of your technical skills. And frankly, seeing somebody grow, becoming better technically, I may be rating his or her documentation skills, for example, writing skills, that's a good thing to see, that very rewarding. And see also project you believe in, progress, and even succeed, why not? At the end of GSOX, that's also something that is very rewarding. It's not the time to testify about what I have done this year, but frankly, seeing the end of the project and seeing it put into production, that's something that very rewarding. But beware, you just can't sign up to be a mentor and then forget about it. You will have to invest some time. So it's between two to six hours a week minimum, I would say. It could be much more than that, but I don't want to scare you. It really depends on the project. It depends on the mentee. It depends on the time you want to spend on the project, but frankly, don't think spending less than two to six hours a week or the project might fail. And of course, the heavy lifting will happen during the summer. So we'll see the different phases in a few slides, but the main part of the project is the coding phase and it's during the summer northern emitter time, of course. So you will maybe spend more time during the summer than before during the spring, of course. And you will maybe have to adapt to the mentor, to the mentee, sorry, time zone or the mentee school agenda or something like that. We used to have only students in the previous years, but now Google allows people who already have a job to apply to be a Google Summer of Code contributor. So maybe the contributor will work during the day or maybe we'll go back to school during the summer because he's in another hemisphere where the summer break is not that big. So yes, you will spend two to six hours minimum a week and maybe not during the best time of the day for you. You have to know that before applying and you will have to discuss with the contributor in order to know that beforehand. There is also maybe a problem with time zones because maybe you will be in a different time zone as the contributor. And so you will have to set up a weekly meeting or something like that, synchronously. You have to be face to face or camera to camera at least once a week in order to exchange because sometimes when the communication skills aren't that good it's not perfect to just exchange messages. You have to see face to face from time to time. Now for the requirements, of course, we want you to know a little bit about Jenkins plugins and so on. We don't want you to be a Jenkins master. You don't need to be already a plugin maintainer and so on but it's good if you already know how Jenkins works and how the technologies we use are used within Jenkins. So there is a bare minimum to know but you don't need to be an expert at all. I think the most important part is the motivation and not your development skills but of course you have to know how to develop and it will change from project to project. Some projects are more linked to the Jenkins core. Some projects are more linked to Jenkins plugins. Some projects are more linked to documentation and of course you won't need the same set of skills depending on the project. And of course you need to know how the open source ecosystem works or even better how Jenkins works with open source. Jenkins is open source and it has its own way of working and we have dedicated channels to discuss. For example, we have some way of introducing pull requests. So you will have to gain knowledge if you don't know it yet on how Jenkins works when it comes to open source. And when I say open source, it's not only code it could be related to documentation for example or website design, whatever but you have to know how Jenkins works with GitHub how we should submit contributions and so on but don't worry there are quite a few guides that could help you if ever it was needed. And of course one thing that is really important is the subject of the project idea. We have I don't know 10 or something project proposal for the timing I think we'll get three to four accepted by Google. And you have to be passionate about the project idea even if you're not an expert on this very subject you have to know some things about this project and you have to be some kind of passionate about it. You want it to succeed even if you're not a mentor that's something you would like to see succeed for the Jenkins ecosystem and that's a major point you have to be thrilled by this subject. And of course we want you to be part of the Jenkins community before applying as a mentor. Being a contributor in the Jenkins ecosystem or community is not that difficult. If you already know Jenkins maybe you could help newcomers in the various GitHub channels or on community.jenkins.io or even in the developers mailing list for example, all the user mailing list there are tons of ways to contribute. And you could also become a contributor by writing blog posts, modifying existing documentation, creating pull requests, trying to help with issues. There are tons of ways and there are also some pages on Jenkins.io that explain it all. So it's kind of easy to become a Jenkins contributor in a way on another. But that's something we want to see you in we want you to be part of the Jenkins community before applying as a mentor. That's something really important for us. But once again, don't run away, we still have time. If you haven't worked with the Jenkins community yet you still have some time to build your muscles I would say Jean-Marc, and you can build that experience. We still have time to do that. Next slide please. So we are the org admin teams. So we have Lisa, we have Chris, Jean-Marc and myself Bruno. So you can join us on the specific GitHub channel. You can also get in touch on community.jenkins.io it's a discourse. And you can also, but I hope you won't have to use the email, the group to escalate if ever you had some communication issues. Next slide please. So we'll now do a round table at least with the admins and Marc with there and we'll say who we are, where we are located and the time zone important is the time zone. The projects you are interested to mentor the experience you have with Jenkins and development and what motivated you to want to become a G-Soc mentor. Also, we also have Hervé. Okay, fine. Alisa, are we supposed to do a round table with only the people in the panel or with the attendees? With the mentors on the panels right now. Okay, so I will start, sorry. Then I will leave the floor to Chris and the others. So I am Bruno Verashten. I'm the one who talked too much. I'm based in France, the northern part of France just next to the Belgium border and my time zone is UTC plus one. At least until next summer when the government will mess up with the clocks. I'm interested in a few projects to mentor but I can't mentor them all. Of course, there is the building Android apps with Jenkins, if ever it was selected. Chris created the building iOS apps with Jenkins. I could help with that. I also saw something by Mark which is the Plugin Intelligent Manager Tools Improvement. And there is also the screenshot automation for Jenkins docs. So quite too many projects. I'd like to be a commenter with. And my experience with Jenkins, well, I started using Jenkins in 2013 or 14. So that was a long time ago. But then the company I used to work for switched to GitLab. So I forgot about Jenkins until two years ago when I restarted working with Jenkins. So this year I was a mentor for GSOC project about quick start tutorials with Docker. And I had a great time with Jean-Marc and Ashutosh to build something that could help newcomers to Jenkins with just one command. You could then start to Jenkins instance on your machine and start interacting with Jenkins to learn about Jenkins. And last year, not last year, this year, I was motivated to become a GSOC mentor because I had quite a few projects I proposed and all of them I thought they were important for the Jenkins community. The quick start tutorials, for example, will dramatically change the way newcomers start with Jenkins. And that's something I wanted to happen between me or without me. I thought this was really important and that was a great opportunity for me to help this project to succeed. So that's why I was a GSOC mentor. And this year I'm also interested because now I know what it is to be a GSOC mentor and I grew up, frankly. So I want it to happen again. I can become better through the next summer thanks to GSOC. I'm done with that. Chris, are you the next one? Okay, so my name is Chris. I'm based out of Hong Kong. So a time zone-wise is GMT plus eight, which means that we are like a day and night difference from my American colleagues. Most of them at least, the ones in the Eastern time zones. And the projects I'm interested to mentor this year would be, there are a few of them, but the project I most want to mentor would be the stats UI project. And my experience with Jenkins in general is like I have been a volunteer for Jenkins for a few years doing all kinds of things for GSOC, mentor for GSOC. And also I have been a plug-in maintainer. I think I have four plug-ins on them about. It's like, and I have been really split for all the few occasions. I've participated in dogs over the hours. And what motivated me to want to become a GSOC mentor is because I used to be a GSOC contributor a long time ago in 2019, 2020. So I did it twice with Sun Pie, which is, they do solar physics. So it's a bit, so astrophysics, so it's a bit different. And the next person on the list is, that's where Jean-Marc, do you want to go next? Yes. Yes, okay, do you hear me correctly? Yeah. Okay, here we go. So my name is Jean-Marc Mason. I'm located in Brussels, Belgium, which is just a couple of, just 100 kilometers away from where Bruno is. So if I shout loudly enough, he hears me. I've been dealing with Jenkins a long, long time at different roles. And the last two years, that last two editions, I was lead, or admin for Google Summer of Code. This year I will only be an advisor to the team and to mentor the team because in 2024, I'm going to retire and move over to France to enjoy my retirement. And so I will have a lot of personal GSOC projects to do from painting and preparing a new house and moving 600 kilometers. This said, I wanted to share a couple of ideas in points for mentors and indirectly to mentees. Being a mentor is, as Bruno said, a great human adventure. And there is a lot to be learned, a lot of rewards from that. But on the other side, it also a demanding task. It's an important task because the mentees will be counting on you, they need you. So where I'm pointing to is that it's an involvement. Mentorship teams, and the team is important, is composed on a lead mentor, who is generally the most senior, has the most gray hairs or no hairs at all and knows the technical subject. But there's also people that will help that wants to learn technically and will also learn the mentorship and these human soft skills. And this is very important too, because this is the way you can progress professionally and this is the way open source can help. But this requires an engagement, this requires presence. It requires several skills and it's not easy. In the sense, the biggest problem that young mentors have or young in the sense, unexperienced mentors is the imposter syndrome. Meaning who am I as an amateur who doesn't know and who doesn't there speak to these people that lead mentors beside not having hairs or being having gray hairs. In several fields, they don't know a lot. I don't know anything about CSS and happens. It's a team and everybody comes with the skills, being language skills, human skills, communication skills. It's then important that you participate that you engage yourself, that you discuss and don't stay behind, yeah, okay, I'm mentored. I'm going to sit at the back of the classroom and not make any noise. So it's a great opportunity to learn and grow, but it also requires, as I said several, an engagement, an investment of a few persons. Don't forget that summer in many parts of the world are, well, I won't say chaotic, but I sometimes disrupt it because of holidays, things like university exams and so time management or mentors, but also for mentees is an important task and is something that you need to keep in mind. So don't forget that G-SOP, it's not a stroll in the woods and we're going to say, no, it's sports. It's a heavy investment and everybody has to work heavily. So they're the involvement is strong. The last thing I wanted to give and then Alyssa is going through, Bruno is going to turn off my mic wisely because I'm talking to them. I'm trying to beat Bruno at them. What is important for mentors and mentees? And I observed that this is sometimes difficult to get and it's related to the imposter syndrome. In open shores, what is important is that you come with ideas that you bring the things forward. You're not executing what people tell you to do and this is a great dimension to open source and this is why it's an incredible school is but the creativity, the drive, all these sets is important. I fear that very often and I observe very often, especially with the young participants as well, I wait to be told what I need to do now. Tell me what to do and this comes very often in question. This is not what we expect. This is not what Google Summer Code expects. We expect people that create and create are autonomous that can communicate, that can share and work, that can work together. And otherwise I'm going to go to the board there. If you want to have advice or channel advice or want to discuss these matter, don't hesitate to ping me or other org admins on the getter channel or on community.junkinst.org to see and we can discuss it. I will not discuss because this comes so often. Where do I start? What do I need to do? Well, do your homework, read, be autonomous and share, discuss, get ideas. So this is a very different dynamic than school. It is why it's so great. And the last bit of advice is, read about imposter syndrome and about beating it. Everybody can do that if he has the stamina to do it and just go for it, try it. And not everybody will be selected and you will be selected another time. It's a great adventure. I hope to have enough time to participate through this year's edition. I hope to be able to continue if my wife allows me and my budget for garden will allow me to continue spend time with you. It's a great, great human. Okay, Alyssa, Bruno, I think I said a little bit. So whoever wants to take the mic, go ahead. So perhaps we can hear from Mark as his mentorship experience. Sure, I'm Mark Wait. So I maintain the Jenkins Get Plugin and a number of other plugins that are interesting to me. I'm based in the US Rocky Mountains. So in the Rocky Mountain region of the United States. So just as Bruno noted and as Chris noted, we're on separate parts of the world, all of us. I'm about 12 hours away from India, for instance, and 11 and a half hours or 12 and a half hours depending on how my government is messing with clocks. Great to be involved, happy to be involved and thrilled to be part of it. So interesting projects to me. There's a Get Plugin project proposal to use bearer tokens. It's a different authentication method and there are folks who've been interested in that. I'm also interested in open telemetry, a way of monitoring jobs and surfacing or bringing the results of that monitoring to users in different forms. For instance, through a network monitoring page or through performance monitoring systems like Dynatrace or like Grafana. Those kinds of things are interesting to me. I'm also listed as a possible mentor for plugin installation manager tool improvements and happy to assist there as well. Past experiences have been really positive. Well, I should share one. I just recently submitted the third recommendation from me for one of my former Google Summer of Code mentees to the advanced degree programs this candidate is applying to at universities. And as it turns out, universities care very much about this kind of thing. Your involvement in a Jenkins or in an open source project can help people as they move their careers forward educationally and it helps the Jenkins project move forward. So it's a delightful experience. Yes, please don't kid yourself. It is at least two to six hours a week. All summer long, that is the reality of it. If you say, oh, but I just can't do that. Okay, then it's probably best not to be a mentor. We really do need the time given to these new contributors to support their efforts as they contribute. And there's nothing dishonorable about saying, I'm sorry, I just can't do it. The org admin team will typically assign two or three mentors to any given project as a safety measure. But you should not go into it relying on the safety measure. You should instead be committed yourself to give that two to six hours a week to support the contributor in their work. They are by nature inexperienced. They are by nature first time contributors or relatively new contributors. Expecting them to have years of professional development experience is unreasonable. That's not what they're going to come with. They're going to come inexperienced and ready to learn. That's all that I really had unless Alyssa, you or John Mark, you had other questions you wanted me to address. No, I think we're good. I think we can move on to the next slide. Thank you, Mark. And Chris, this is for you. Okay, so next we're talking about the GSOC 2024 timeline for mentors. So as you can see in the diagram shown on the screen, we have eight milestones from org acceptance in February to the final evaluations supposedly in September. I'm saying supposedly because like this time around, like we have Google have three different lines for the GSOC project. So they call it small, medium, and large. And it depends on the size of project. So the length can change too. So next, so GSOC 2024 timeline for mentors. So just reiterating organizations are to be accepted by Google sometime in February, 2024. And candidates can start preparing for the proposals from February 22nd to March 18th. During this time, candidates may need help to understand the project idea. So we will have to start and buy, especially watch the GSOC SIG channel to answer any questions they may have. We have to review and guide proposal drafting. So these would normally be done using Google Docs. But sometimes depending on the project, it could be done via means to like FACMA or maybe a Google Slice. We over-communicate in the open. So this means that no private or one-to-one communication channels are allowed. So even if like people approach you for private advice, you should direct them to the public channels instead. And we have weekly office hours. Usually it should be, if I'm wrong, please correct me. I think it's like we did have that on our first day hours here. But this time I'm not sure. It's like it should be the same time slot but we'll have to confirm. So we'll answer questions of contributors and to give guidance. The proposal ranking is like a period for the candidates to submit applications. It's between R18 and April 2nd. No mentors will be involved in reviewing and ranking of the candidates. Next slide, please. Oh, can I go back one slide? Because I think we have a mismatch, yes. So if a GSOC 21 timeline for mentors we also have the bonding period which usually marks the beginning of the GSOC project which has been accepted. This is the period during which the mentor or mentors and mentees learned about each other for a project. And we would set up the tech stack for specific workflow into project communication during this stage as well. So it's a very crucial period to establish report with the mentees. And during this stage we prepare and publish a project plan initial schedule and we also discuss with the community. Usually we email sometimes vague discourse about project plans and details. Finally, the coding period is normally between May 27th and September 2nd but we have to confirm that too. So for this coding period we have midterm downloads and presentations. That should come around July, August I think and end of term found downloads and presentations. So two demos and presentations for each project for a cohort. Next slide. Next. Oh, hang on, yeah. So project ideas, we have, should we introduce the projects here or not really? So we have a project ideas page here for 2004. I think for this year we have at least 14 project ideas so far and we may add more later as they come. And next slide please. And project selection criteria. A good project masks on three legs. A strong proposal by the student. So if you demonstrate they have understood and we face the project idea well. They should use novel and structured ideas for the project and propose concrete outcomes that's measurable. And they should be able to show the technical skills and guts required for at least the basic ones required to start the project. And we also have to show to Google, we have a strong mentor team. We as an unspoken rule would like to have for each project three mentors with one journey is okay. They should be experienced or rather experienced. So for more inclusive slides and they should be knowledgeable on the project subject matter or at least one of the mentors should have expert knowledge in the project subject matter. And the third leg is we have to have a very strong project. So first, which means I should be technically feasible. Second, it should be technically challenging enough to motivate why we have a project. Third, it should be useful to Jenkins community to justify why it's been selected and sponsored by Google. So next slide. So project selection process, once meted, formal proposals are reviewed by all mentors even though they may not be the mentor for that particular project. All of the mentors on our team will grade each project. Grading comments used to sort proposal. So it involves some time commitment, the mentors part. And we only choose one waiting project, her project idea. And the project proposals are ranked by each of us ideally. But all of the projects for all the project proposals for each project, for like the mentors assigned to the project must grade those projects. And like we always discussed during meetings with all mentors, we then find and we find the criteria. Mentoring team for projects proposed and assembled. So as I once the projects are selected by Google we will confirm the mentors for the mentoring team by the Occamene. And we will also confirm the availability of the mentoring team to make sure like each project is covered as best as we could. And also Occamene team makes finalization. So request Google for a number of GSOP project slots. So this is one information we provide to Google when we submit the application. And when we choose the project ideas to submit we do not know like how many project slots we will be given but when you take the project, project student mentors I believe we are able to bring to a successful end. So it really depends on all the factors of whether a project will be selected. But normally like if a mentor usually it's interested in a set of projects but they're not selected they may get assigned to another project. Next slide, communication. Communication guidelines. So all communication explanations are to be public. This is hard for like this is not for lack of a bad word, normal for most people because like for open source it can be kind of awkward to have all the communications out in the public. And this is understandably hard for shy and imposter syndrome participants. But we should avoid one-to-one private communication during public phases. And the genre of farmers praise is to be given in public and critique is to be shared in private. And that's the end of my part. Thanks Chris. If there's any questions feel free to put it into the chat window and we can help answer the questions. And also be posted in the Q and A. Yeah, we'll give it a couple of minutes. So if there's no questions definitely you can reach out to us after this webinar via the Gitter channel as well as communications.jankins.io. We're always there. Mark has a question I think for the chat. Oh, sorry Mark. Well, so I open it to Chris, to John, Mark and to Bruno. Are there other things that potential mentors should consider? We've talked about, we've talked about time commitment. We've talked about skill level. We've talked about some of the dangers associated with imposter syndrome saying, I'm not good enough. Are there other things that are on your mind about, hey, a mentor should consider this as they embark on the journey of being a mentor? Yeah, I actually want to add maybe to repeat ourselves just about time commitment. It really depends on whether you're the lead mentor or like, and it really depends on the mentee and the project nature and how you intend to mentor it. Like for some projects it can be a few hours for mentor, per week. But for others it can be more demanding. You may need to sometimes to work through yourself too. So that may take a bit more time. I'd say like, it could take me 10 hours per week of a project like it happened before. So do consider like time-wise if you have the time to do so. Or if it's like, if you really cannot do it, can you work as a team with the other mentors to make it happen? And I see John Marquez has his hand raised, Alyssa. Yeah, one of the other points I wanted to draw the attention has already been raised is it is interesting, but sometimes difficult. Be aware that time zone or time differences is something we need to learn and be able to deal with. It's a difficulty, but it's an extraordinary opportunity to learn, to work with that. So to leverage asynchronous communication have a very good written and quality written communication. So these are different skills. So I don't want to scare people of that. I just want to make them aware that this is an interesting thing to learn and requires exercise. I like the words, you need to build muscle and so you need to master this skill. So just be prepared to do the effort. So time zone difference can be challenging. It's early in the morning for people, late in the evening for others. And when you're busy working, you're stuck. How do you manage that? Interesting questions, interesting techniques learn and put in place, but you need to be aware of that. One thing I would insist on maybe if something you told us about John Mark earlier is contributors are not following a well-written path. They are writing their own path. They are making their own journey. So it can be difficult for them to make proposals to progress on their own to experiment with novel ideas because they are used to have an assignment and do it the way it is asked for. And that's not the way GSOC works. So that's difficult for the mentees but it's also difficult for the mentors because you have to let the mentees a degree of freedom but you have to guide them nonetheless. So it's sometimes difficult to find the right amount of push, pull, step back and so on. So that's something that could take a few weeks. It took me a few weeks or even a month this year to find the right amount of push and step back because yes, it's not an assignment. Contributors make proposal and they follow their own path. It's different from school, different from work. It's something else. It's open source. So we have a question from Vandit. If I'm a potential mentor in a project, can I answer questions if I have the knowledge about the subject matter of the contributors who are interested in that project? I see that Chris is typing the... Oh, the answer. Vandit, you mean before the coding phase in the bonding session or even before during the proposal? I don't think you're... Yeah, so let's assume that just throughout the entire period if he's interested in being a mentor. Yeah. Maybe more so now because I got a lot of questions in the channels on Gita. So maybe like for... Okay, so interesting communication. Answers, yes, you should answer as much as you can and it's because I guess it's going to by nature, the effort. So you should help as much as you can and find ways to contribute if you can. Yeah, but keeping in mind that the contributors have to... The potential contributors have to do the homework too. So you're not machine answering as soon as somebody puts a coin in it. You should help the contributors, the potential contributors when they have questions maybe about the process or general questions about the subject, the idea but not give them answer for each and every question because everybody has to do his homework. I have a good image for that. It's now it talks to parents. When you teach a child to use a bicycle you need to find the exact balance in holding the bike that the kid doesn't fall but also let it lose so that the kid learns to do it himself and you're just there to avoid that he falls on the ground. And this is a balance that you need to find in a way this is mentorship. Now coming back to Vendit's question I think it's good to give advice and guide but the word guide there is very important. A lot of people, young people are used because of the educational system to be fed. So and the professor is telling do this, do that, do that. We want to get out of that model. And so how you advise, how you guide the people needs to be very, very fun. And I agree with Chris. Yes, get involved, answer, coach, whoever, mentor or not. You need to remember the way you felt the first time you joined the community. So this is very, but find the correct balance. Don't give all the answer. Mark raised his hand. So I think I may have a different angle than John Mark and Bruno. So it's okay that mentors disagree with each other. Don't be shocked that in this case I don't remember the last time I felt like there were too many answers to any request from any potential contributor on any of the forums I've watched. I would love to have the problem of too many answers to a potential contributor's questions. So if you have some knowledge about the subject and are willing to answer, please answer. That's great because if we make the flawed mistake of deciding that, oh no, only lead mentor should answer or only very qualified mentor should answer, we will get far fewer answers than we need to have for these potential contributors. We've got an enormous pool of potential contributors. This is a very interesting program to these contributors. And therefore we're going to get a flood of questions. And if we lean on too heavily on only the lead mentor or only the lead mentor and a few others we miss the chance to engage, to connect to help these people along. I don't mind if we get more answers I'd love to have that problem. That's mine. So you've heard my disagreement. John Mark. I fully agree with your disagreement Mark. So, and the point is very, very valid. The thing Bruno and I had in mind and I think it's shared with Chris, we get regularly questions which are, I'm excited to start with GSOC and with Jenkins Community. Where do I start? These questions have been answered so many times just to scroll up in the thread. It has already been there. So yeah, okay. You can help the people where to find, but we're expecting that people at least starts to reel in the knowledge and know where to search. Where definitely help is required and there I strongly support Mark's opinion is once we get in the real stuff, not the where do I start? Read the documentation. Try it. But oh, I tried and I don't understand this. I thought it did that, but I don't understand. These are the goals questions. These are the good question. I get this mistake when compiling and this is the error message. This is what I tried, right? Now I'm stuck. Can you give me an idea? Another goals question is these are, these are motivating questions. So I think we're synced with the... Bruno raises hand. Yeah, just wanted to say about that. When you give an answer, please make it always public so that we don't get somebody who's got an advantage because he got the answer and the other don't know about that. So always public and that's a good habit to have for the rest of the GSOC project. Very true. That rule about responding in public is not just for the service of the individual. It's for the whole community, right? When if I choose to answer you in private, I have shared an advantage to you that may not help others. The other is I've also most likely assured that I'm gonna have to answer the same question again from someone else. Whereas if I answer it once in public, I can at least refer people back to that answer in the public location and say, hey, here I answered this already. Because guess what? Many of these questions have already been answered by others or have already been asked by others because they're pretty common questions. John Mark. And the other side of the argument is also creating one-to-one communication is counterproductive in building a community. People that share knowledge that work together because there you start dividing and you can, you start, it's a strong word, but suspicion. What are they doing? What is their idea in their corner there? What are they trying, trying to overturn or trying? No, when you try an idea, this is a spirit of open source. Show it, make it public and say, I'm working on that. I don't know if it will work out. I don't know if it's a good idea. This is what I'm doing. These are the results. It's the open source Darwinism and it works because it's public. So just the other side, the argument about public sharing. I will have to drop shortly. We have just a couple of minutes left. Any last minute question before we drop? Okay, it doesn't look like it. So our next GSOC related webinar is going to be in January, end of January and that's going to be dedicated to new GSOC contributors. So until then, happy holidays and thanks everybody. Bye. Happy holidays everybody. Bye.