 I'm going to be recording. It should be on right now. So we'll get started. Good morning. Good afternoon. Good evening. Good night. Welcome to the Jenkins Google Summer of Code 2023 Mentor Roundup webinar. Today's January 19th. So we are doing this in Zoom, of course. And for any questions, please put them into the chat window. And if there's any questions that comes up after the session, just feel free to pop them into the Gitter channel and or the Discourse channel, where we will be lurking around for questions as well. And then as usual, the Code of Conduct applies here, as always. So be nice, be respectful, please. I think this one is yours, Jean-Marc. Yes. Thank you, Alyssa. Thank you for the introduction. And as said, I love the elephant protecting the little one. Here today, we are going to address questions and clarify a few things about mentoring in Google Summer of Code, especially in this 2023 edition. So we're first going to discuss who we are, what it means to be a mentor, what is the calendar coming up for this year, how do you participate in the various phases or periods in the program. I clarify a couple of things or give some advice on how it's going to work. And we complete with an open question and answer. And you can ask whatever related to Google Summer of Code, whatever you want to know or clarify. I can answer other questions, but that will be offline. So first, Google Summer of Code, just I guess that people listening to this recording or attending to this meeting know what Google Summer of Code is. You can refer to the Google site to have the full details on key elements in there are project ideas, mentors and contributors that I will also name as students, the people participating. So contributors or students are working on projects with the help of mentors. This session, we will clarify what mentoring is. So first, thank you for stepping forward to mentor, because if you're interested in this presentation, that means that you want an intent to mentor. This is a very important step and we appreciate very much the effort that you're doing in there. So what does it mean to be a mentor? And you probably know it if you're interested by mentoring. It's a great human experience. It's a human experience because you're going to help younger people to grow by getting an experience in open source and computing and also a step in their professional career. And this is very gratifying. It's also a great experience because you will be able to share your passion or for open source technical subject sharing all that. Another interesting thing by being a mentor is, and I like to hint that, just remember how you felt when you got out of school that you started, that you contributed to your first open source project. It's a great accelerating experience. Just remember how you felt and maybe fill the gaps of what was missing at that time or maybe just reproduce a great mentor that you met at that time. It's also a great experience because it allows you to reflect on your practice, how you work, what is important to you and by having the mirror of younger people being interested is very interesting. And then you can also use that to improve your mentor coaching skills, which is also very important in professional life. So it's really very attractive to be a mentor. But I need to be honest here, there's no rewards or financial reward besides being proud to have done something useful to participate in a great adventure and having the thanks and gratitude from the community at large. So there's no money involved, there's no retribution, even no t-shirt or swag to have, although maybe no. It's also an important investment, a time investment. So you need to know that from when you start, you need to count about two to six hours a week to invest in the adventure. I want to say it upfront, it's not answering one or a couple of emails reviewing a few pull requests. No, it's you're going to build a constant relationship with candidates or with students that will work on the project. The heavy lifting is during the summer period for the Western Hemisphere. So the summer starts in June and in August. I know that seasons are different in other parts of the world, but this is where the highest involvement will be as a mentor to follow your mentee. Goodwill enthusiasm is important, it's not sufficient. So to be a good mentor, you need to have some experience in development, Jenkins development, plugin development, various other aspects of development. You need to have experience also in the open source way, how it works, the process, the tone, the communication. These are important assets or elements to master. You need to have a presence in the Jenkins community, because the whole process is embedded in the Jenkins community. We're going to encourage the interaction with the Jenkins public and illicit interactions. So the better you're known in the community, the easier it will go. Being a maintainer or an active contributor is in certain cases critical, especially if we want to update or the project idea is about updating an existing component and adding new features. So the people mentoring must be able to approve a pull request and merge it, otherwise the complete process will be sluggish and it will not work. We will not have the expected fluidity. It's still time to build the experience. If you're coming from another community or you're still looking, you have experience and the most important thing, you have a heart and you want to participate. The enthusiasm for me is the most critical element that you need is the drive to share and help people. You can still build up that experience by participating in the community, contributing to plugins or core, adopt a plugin and be involved in a particular plugin or component. I will explain more details in that afterwards. So first thing, who's who? Who's doing what? And so on. Now I don't know how many attendees do we have? So let's start first with the first important actors is the Jenkins org admin team. So the org admin team's role is being the interface with Google in the organization of this adventure. So we're going to provide our registration or our candidature. What is the correct name in English? Alyssa, help me there. What are we going to submit end of this month? Our application mentoring or application correct application. I was searching for the word. Another important role is that we are responsible that the program within Jenkins works smoothly and efficiently and that we reach the objectives. So there's an important work to be done there. And you will discover later what the roles are. Member of the org admin teams are Alyssa. Alyssa is an outreach officer and leading the effort. We have Chris Stern. Maybe Chris, Alyssa, first you can present yourself quickly. Yeah, hi everybody. Where are you? I'm located in California. So I've been with the Jenkins project since 2011 and before that I worked on Hudson. But I've been around Jenkins for a long time. This is my second year being an org admin for Jenkins in GSOC. Excuse me. But so I'm happy to be part of this team. Great. Chris. Yep. So everyone my name is Chris. I'm based in Hong Kong. This is also my second year as an org admin and I have been a mentor once previously in 2022. And I'm looking forward to being possibly both a mentor and org admin again, but it depends. And I work as a software engineer for time. But I volunteer for Jenkins. So happy to meet you. Great. Thank you for participating. Bruno, who are you? Hi. In France, I should make a guess with my accent. Oh, I'm not very far from you Jean-Marc as you know, it's 200 kilometers. So I've been playing with Jenkins yet playing not way really working since last April. And it's my first time as an org admin, of course, and also as a mentor, potential mentor. We'll see which subjects will make it to the end. So yeah, we're happy to be there. And I'm very happy to welcome all of you on this program. Great. Thank you, Bruno. So and my name is Jean-Marc Messen. I'm located in Brussels. I'm from an older generation, meaning that I've already seen a lot of things. I'm still very enthusiastic about technologies and sharing these incredible things that happen and that are available out there. My second here is org admin with the team here together. And this is basically it. So this is the team. A lot of decisions and arbitrations are done together by this team. So there are different levels of arbitration. The mentor team is a first level. Org admins is another stage where we make decisions and also solve potential problems. How can you reach to the org admin team as a whole or individual? Use the Gitter channel. You can also use the discourse community.jankins.io channel for that. We also have an email group. It's described on the GSOC page on jankins.io. It's an email group. This is how you can reach all the org admins should you have an issue, a communication issue or whatever and you want to raise the attention of the org admin team as a group because you feel something is going wrong. It can be interesting in some cases, especially related to communication breakdown issues. So it is about the org admin team. Now let's start going around with the other mentor candidates that are here on the call. So here are just a few hints of what are the subjects I want to do. So the first I see in the list is Frayem. Sorry to butcher your first name. So how is your first name? It is actually very simple as that. Okay, go ahead. Hi everyone. I'm Frayem and I'm located in India as of now. I'm currently a student. I think I'm going to be graduating next year. So yeah, I'm still pretty hung out. I mean, I guess I'm the youngest one here and I'm actually interested in multiple projects this year. Just one more thing. This is actually the first year I'm actually interacting with the Chechenkins community as a whole. I have been working around for the last four or five months. I've been part of the discourse. I've been part of the literature as well. But I think this is the first time I'm actually very proactive about the entire contribution and internship and all of that. Talking about my prior experience in open source, I actually love open source. I have been doing open source for the last eight years now. I still remember my first ever PR. It wasn't much, but I actually learned a lot. I think it had almost 74 conversations. We just kept talking back and forth. It was amazing, but I mean, I feel that open source is the best way to learn something new or to actually get involved in something very big and something influential. So yeah, I guess why? I mean, we are also talking about the projects I'm interested in. I'm actually very specifically interested in the plugin installation one because it's something I have been using myself a lot. I feel that there are some things that we can work upon. If I actually share my screen, I would like to show you something. I think the host has disabled the screen share. It's fine. I'll just share the link. I think the link should work. Share the link, please. Otherwise, we're going to lose the rhythm, but go ahead. It makes sense. I actually have shared the link. So yeah, as I mentioned in the project chat back over here, there are a couple of new features and a couple of more enhancement features, which are really interesting. I would really, really love for these features to come to life. I feel that I have the necessary experience, the necessary expertise to actually get this working up from the ground. So finally, what motivates me to become an inventor this time is that I actually have been an inventor. Last year, I invented a Joomla. So Joomla is a CMS, like, you know, it's just like a WordPress, but like the much older version of it. If that's a way you can see it. But yeah, so I actually had lots of lots of fun last year working at them. I mean, I was just like, I was like the secondary inventor in almost every project out there. I think there were around like four to five projects at the same time. And I was actually part of all of them at the same time. So it was kind of like a very mixed experience. I was interacting with everyone. I was actually conducting events, you know, just like in events, just like we used to have this online gaming sessions. We used to have like outreach sessions. We used to conduct blogs, blogs and like lots of fun. And I would actually like to bring that here as well, if I'm actually selected as an inventor this time. And more than that, I want to be able to learn new stuff. I feel that like, like, I feel that everyone learns a lot while just, you know, while like showing that same path to somebody else as well. So I would actually like to learn as well as a printer or as a student or whatever you whatever my role here is. But yeah, in short, I'm just here for fun. I mean, this is just something I really love doing. And I wouldn't mind, you know, like just being and making a difference out there. Yeah. Hey, free him. That was a brilliant presentation. And I hear the enthusiasm in really great. Okay, let's move on. And we have a mentor candidates. And I once I will not say an old timer, but an experienced mentor. So Mark, you're the next one. Can you present yourself? Sure, I'm Mark Wait. I've mentored two or three years. And it was a really positive experience. I have to agree with John Mark's observation plan on four to eight hours a week. Every week throughout the mentoring period, it's work. This is this is non trivial. It's a real contribution. And you're really helping someone. But it's work. So if if you say, oh, I just can't do that. That's also okay, we understand. So let's see whom I maintain the Jenkins get plug in, I maintain the Jenkins get client plug in. I'm a main member of the Jenkins governance board. And I'm a Jenkins corc core maintainer. And therefore, I've got a lot of permissions. I'm actually not as experienced in Java as I'd like to be. And I'm certainly not as not as experienced in other languages I'd like to be, but I'm happy to use the skills I have to try to help others. Right. And and I've enjoyed learning enjoyed growing and enjoyed deeply some of the surprises that came to us in past Google Summer of Code experiences where we specified a project. The student created a great project description. And during the execution of the project, we realized we had not understood some very important parts and had to had to make changes and corrections and adaptations. It's a learning process, not just for the the person who writes the project plan and is the first time contributor, but also for us as mentors. John Mark, did that cover the topics you wanted? Or was there more that I should say? Yes, no. And and thank you for sharing your practical experience and and putting into the light the time investment that is required and better to know it beforehand. If you want to do a good job and act responsibility responsible with the people. And also, like an old general said, the plan holds until you start the battle. So you need to be prepared. And this is what's what makes the adventure. Yeah, no, I missed I missed one answer. Sorry, I owe an answer. Where are you located? I'm located in Colorado in the United States. Therefore, I'm in the Mountain Time Zone. Therefore, and I talk like I come from Utah because I do. Therefore, if my accent bothers you or my mispronunciation of words bothers you, don't let it get get past you. That's just where I'm from. I'm working to overcome it. Great. Thank you very much for sharing that, Mark. So the next one on my screen here is Kevin. Kevin also is interested in in mentoring a project as some experience in that field, Kevin. Who are you in Swan? Go on. Yeah, so I'm Kevin Martins. I just started working in Jenkins last year around the same time as Bruno. And I'm based out of Massachusetts. So East Coast time, EST. But I want to be a mentor because I'm also the documentation officer and have been part of the copy editor team for Jenkins.io for a few months now. I've seen the results and the impact that Google Summer of Code has had not only on Jenkins, but the people involved with it and just how much everyone gets out of Google Summer of Code has made my heart swell up a little bit. And I just want to be able to give back. I've learned so much in the last almost year that I just can't sit here knowing I know all the stuff and not share it with other people or help other people learn. The excitement, the enthusiasm that people bring to this project is really infectious. And I have seen, looking at the project proposals, there's a couple that really caught my eye, like the site generation and docked screenshot automation. So there are things that I'm really interested in myself on a personal level and professional and work. So really, I want to be able to become a mentor, help people learn what I've been able to learn and gain knowledge from the people that I've been working with, because I think one of my favorite things about Jenkins and the open source community is just how different everyone is and the skill sets each person has. I might know documentation, but I don't necessarily know development. And if I can increase my job of skills like Mark wants to, I mean, that's amazing. And that's a huge benefit for me in every way. And I get to share my, like I said, my experience, my knowledge, anything that I can as a mentor. And I've done a lot of training in education projects before in my past lives. So I want to continue that and just flex those skills a little bit more here as well. Right. That was a brilliant presentation, Kevin. So very nice in your perspective on the usage of things is critical for this project. Okay, good. Then I see somebody I remember. I've recognized a curtain behind. So Dirache, you're on. Where are you? Where are you located? And the rest of the presentation. Yeah, can you hear me? Uh, it was more Dirache. Dirache Singh. Yeah. Yeah. So, yeah. Hi. So my name is Rajiv Singh. I'm from India. So located in times. Would you, would you stop, stop for a minute. We meant the watch. Yeah. Yeah. Here, let's let's do it that way. Rajiv, go ahead. Yeah. Okay. So my name is Rajiv. Like, I'm from India. So I'm located Indian time zone. I graduated last year and I'm working as a software developer. So I'm an open source enthusiast. So in 2020, I did Google season and dots with GRPC. Then I did LFX mentorship with Moja Global. And I did last year, I did Google summer of code with KPDN captain with Oleg and Meg. So I saw like, even, so I got to know about Jenkins from them. So, so, so basically I'm interested in that building Jenkins IO with alternative tools. That idea. The reason is that last year when I did Google summer, summer of code with captain, my project was making a new dock engine. So I already have experience with making a dock engine. And the thing is that even in 2020, when I did my Google season of dots, so the partial some work was on making a a dock site is in check. So for if you talk about, I don't have much experience at writing a dock, but more of like technical knowledge how to make a robust dock engine. And I saw like, even I went through that idea for a dock engine, like Antora and it was suggested like, we'll be using Antora. Last year when I did my Google summer code, we use Docker service. And even that time also, we thought of like, making it a large scale, like using like CD, cloud native organizations, like what Oleg said that time. So maybe that also we can consider it. Let's see. So the, so I am, I want to mentor because like I already have experience as a student, so I want to give it back. I have mentor people not on a large level, but like in India, we have some open source program on college levels. So on that, I used to mentor like to review stuff or I used to be like a partial, not like a serious mentor, but like a full time, but yeah. So yeah, I have experience as an open source and all Jenkins, like we used to, we used to like, you know, I come to me, Jenkins CI, but I don't have much on Java level. Yeah, I'm a Golan guy, so I don't have much Java. But that's okay. That's okay. I mean, docking is like something I don't think we need more of like, but yeah, so that's about me. Okay, great. And so you're working. So you're not studying anymore? No, no, I'm working. Okay, good. Because I know that the semesters in India work differently than in the Western hemisphere. So the holidays are a different period. Hey, great. So thank you very much for that presentation, Rajiv. I hope I pronounced the first name. Please teach me how to pronounce your names correctly. Yeah, thank you. Okay, good. And I believe this is the last mentor that's on this call. We have Drash. Well, I can't pronounce the full name. So I'll say it my way. Drash Singh Yodha. Is that correct? No, close. That was close. But thank you for saying I need to come to India to learn. Yes, always welcome. So hi, everyone. My name is Thira Singh Yodha. And I've been contributing to Jenkins for two years now. And, okay, second is I'm located in New Mumbai, India. And so we have one time zone. So it's Indian Standard Time Zone. So that's a good thing. And I'm interested in mentoring for the project, plugin health scoring, because I was a contributor to the same project last year, as part of the same GSOC program. So we started something, and it's going really great. So I would like to give back to the program and mentor this year for that. And about my experience, I am currently working with Red Hat. And I was interning previously. And then now I'm working as a full time. And just working on the automation side. So that's going great. And my motivation to become a GSOC mentor is as I said, since I was a mentee last year, who worked on the same project, I would like to give back the knowledge that I've gained while contributing to this and help someone else when they are contributing to the same project. And second thing is that for the past few months, I was not able to contribute at all or even join some meetings, literally Jenkins because my work has been very crazy. So this being a mentor at GSOC would be a really great excuse for me to commit something and then start contributing. And having said that, I would not take it lightly. I will stick to the hours that we have decided for the mentors. And I also would love to go above and beyond and try to help the mentee. So this is just also an excuse for me to resume contributing to the project. And other than that, yep, it's always nice. I think it's always nice to contribute to the Jenkins community. So that's all about me. Great. Well, good to see you coming back and giving back. Great. So you had a good experience last year participating through the program. Very nice. Nice to have you on board. Okay, let's move on. So first question, did everybody have a chance to present himself or did I miss somebody? I think we had everybody. I think we got everybody. I needed a reminder, John Mark, for my poor memory. Freyam was interested in a particular project. Rajeev, I remember he's interested in Dockside in the site generator project and Dheeraj is interested in plug-in health score. Freyam, I've forgotten yours. What was yours? It was actually the plug-in installation one. Oh, good. Plug-in installation manager tool. Okay, thank you. I think Mark, I think you are the one who's hitting it right. Yeah. Right. Just that helps me align. Thank you very much. I need to be sure I remember where the interest is. At least for me, it helps knowing, oh, interested here. Good. Good. Here, let's move on. Thank you for the presentation. It's great to see you. Sorry for the people that are listening to the recording, but they can still present themselves online. Okay, so the GSOC timeline, it's more a reminder what are the big steps that we'll have in front of us. So I will, you can read. So there's just placeholders. So the big event that will happen end of the month is that Alyssa will take her nicest pen and submit the application for Google Summer of Code end of this month. And we need as org admin team to have everything prepared that it is accepted. As soon as we know that our organization is accepted, we'll then start the preparation work. So that means that candidates will start to prepare their proposal. So this is beginning of February to March to the end of March. This is an important part where candidates will need help to understand correctly the project idea will have, will require guidance to build a good proposal and to help them think correctly on the proposal. It's important that we over communicate. We'll come back later about that students will be shy because it's a very stressing experience for them to step forward and show eventually their weaknesses or their doubts. We need to tell them that this is normal. Everybody is weak somewhere. And it's part of the process and the richness of what we do to step forward and ask for help. And so try to avoid what they're best, one-to-one channels, especially in this two reasons there. It's for them to learn the review process and to accept the psychological impact of that. But also we share evenly the knowledge and explanation to whoever wants to participate to the program. And this is by fairness. I will remind that several times when we get to that. We're also going to organize weekly office hours during that period. We might fine tune the timing so that everybody around the world can find his best spot in a sweet spot to get organized. The purpose of that office hour is to have a regular time where there will be somebody available to answer their questions, clarify their doubts, and where they can get guidance on the projects or on how to build a good proposal or having a good chance to be selected. So this is an important phase where all mentors are expected to be aware, attentive, help, guide the people. This is the first step of mentoring. It's not heavy duty, but it's important in that the candidates feel supported during that period. Then in April we will have the proposal ranking and selection period. I will explain later how that works in detail. This is the moment where we're going to evaluate the proposal, rank them, review the projects, and see do we have a good proposal? Are we able to succeed with these proposals? Mentors are also expected to review this in an asynchronous process. So to review, give a note, make comments on the proposal, and then we'll have one or two meetings where we'll fine-tune these rankings. Then students are selected after that process. A miracle happens in joking. Google says, okay, you got four slots and because you ranked your project that way, the first four projects are accepted and ready to fly. So the team gets notified and the first phase during May is what we call the bonding period. That means where you learn who you are, how you work, where you set up the tech stack, how you're going to work, how the communication is going to work, and you start working, refining the project plan and say, well, we're first going to do that and we plan to achieve that at that date. This is the first real-life test of the project ID and see are we on a reasonable ground. Beginning of June, this is where the actual coding period starts. There the projects roll and fly on their own. Once a week we keep that format. We have a short office hour meeting where all the mentees and mentors can meet at a certain time if necessary, we'll fine-tune the times. But this is just a moment where we listen what's happening. Are we making progress? Is everything working as planned as so? It is very important because for me personally, I don't want anybody to struggle, to feel frustrated, things are not going where you can also share your victories, not only your your pains, but share the victories and say, I achieved that. I'm so happy and proud to have done. This is particularly natural and last year's experience showed that these moments where we are together are quite valuable and interesting. It helps me also eventually to fine-tune things where communication might be not as efficient as we could be. We have two demos presentation, two milestones. One is midterm, so end of mid-July, let's say there, mid-July, where we organized the first demo. This is what we achieved and this will be a public presentation via Jenkins online meet-up, quarter of an hour, where the students present what they done, bragging aloud, encouraged. For some students, this will be a major hurdle because talking in front of a class is one thing. Talking in front of an unknown crowd around the world is another experience and you need to help people overcome these. The communication part is key in the open-source process. We're there to coach them, teach them and make them grow in there. Then we'll have the same kind of presentation where we expect a completed product, feature complete at the end, so end August, beginning of September, where we do the final demos, final presentation where we wrap up and there will be explanation afterwards what is expected there. GSOC timeline. All the questions about what has been said up to now, I have 10 minutes to go. No questions from me. Okay, great. Thank you, Mark. Okay, good. So project selection, this is something I'd like to clarify and just to be sure that everybody has a common understanding and there is no misunderstanding. It's not because a project has been proposed or that you're not proposing, but you're stepping forward as a mentor that your project will be accepted. Now, we can discuss if you have energy and time, we might propose alternatives in there, but the message I want to get across, there will be a selection on the projects, not only on the mentees. So what is really important, and I thought a lot about that lately, I'm going to write a document about that. It clarifies before, so there are no false expectations or quarrels after that. So for a sturdy GSOC project, we need three legs like this tool. If one leg is not correctly fixed or wrong, it will fall. Our responsibility as org admins is that we have a stool where you can sit on, where people can create something, can live with and build something. If the foundation is not good, I will be very, very unhappy and these rules, criteria is here will help us to have a sturdy stool to build on. Maybe it needs another image than stool to convey the building I work on that. So the first element, the first leg is we need a strong proposal by the student. So the kind of things we're going to look at this during the ranking process, did a student understand, rephrase the project idea, does he own, did he internalize the project, does he come with a novel structured idea, does he have the necessary technical skills and the guts, you need the heart to successfully bring this project to an end. So these are the kind of things we're going to look for. We also need a strong mentor team. This is a responsibility that we take towards the mentees. We need to help them. We need to be in a state where we can make them successful. So we're looking for a team of three mentors, because we know people need to take holidays, people can get sick, might have other obligations. So we need enough mentors that are able to work together as a team. Generally, we want to have, no, not generally, we want to have a mentor that is strong pivot on the project chosen. And so there's some important criteria as he needs to be knowledgeable on the project subject matter. I think I'm discussing that later in a presentation, in the presentation, but he needs to be experienced in the domain. One of the indicators is he maintainer of the component that will be worked on. And so we'll clarify later what makes a strong mentor team. But as said, you can build your expertise and so to be sure that will be selected. The third element, the third lag is we also need a strong project. The project must be feasible, challenging, and useful for the Jenkins community. So we could have a great student, a great mentor team. But the project is, well, maybe completed in two weeks, or so I'm exaggerating. So all legs need to be of the same strength, same length. Otherwise, the stool doesn't work and you can't sit correctly on it. To explain that, when will these criteria be used is when we're going to select the projects. So when at a certain, I don't remember the date exactly, I think it's end April or so, all the students have submitted their formal proposal. So if they upload it on the Google site, this is where then the application is closed for them. At that moment, all mentors are requested to read the proposals and to grade them. So we'll publish what are the criterias that will be used to grade them and comments also will be applied. We have a spreadsheet that's used for that. The spirit of that grading is, does this student have a chance to succeed? Is it worthwhile to help him build something? So there's an important process. The projects will be ranked based on that note. Only one candidate or one mentee per project, so one winner per project idea. And I'll let you read because I'm going to run out of time. I'm sorry for that. So the ranking process is important. And we want to have all mentors participating in that. So you're not reviewing proposals on your pet project idea. We're doing it as a community. Based on that, we'll have and we'll discuss it together to fine tune and nuance this. The mentoring teams for the project are proposed or assembled. We might have no proposal or no good proposal for some projects. And we're going to propose to the mentors that were on that project that didn't pick. And either they can join another project where they can help or be active on. So there will be some fine tuning of the mentoring teams. This will be discussed with the mentoring team and org admin, not with the whole mentoring community, but more with the project I see. Do you see yourself as a team mentoring this particular person? Can we bring that to a successful end in September? We also going to check the availability of the mentoring team. The org admin team will make the final decision. So at the end, based on the input, the process will be public, but at the end it's the org admin team that makes the decision. Now it's not something where we come with a hammer and say, well, it is the way it's going to be. But I probably start to know me. This is not my style at all. I want everybody to feel comfortable and we think together. But at a certain moment somebody needs to say, well, okay, that's what we're going to do. Otherwise we're still discussing when I retire and this would be a waste. And we then going the final phase is then we'll have ranking and the number of slots that we're going to request to Google. And there we're pending the Google decision saying, well, we say that we can manage four projects this year. And these are the candidates that we want. And they say, with all the organization participating, we can only sponsor three. We'll take the three top of them. This is a process. We're going to clarify this also when we're busy with that. I gave a lot of details about that because I had some questions about this process and criteria some days ago. And I've been thinking quite a lot and it's worthwhile to describe them. And I'll write a document to be reviewed by the community and say, this is how it's going to work. And I want to do that upfront so that everybody knows what the game rules are. Are there questions, doubts about what I explained here? Okay, you can always come back via the GitHub channels or discourse channels if you have comments or suggestions for improvement. Last little thing, communication. Communication is key in open source and is key in this adventure that we're doing together. I already gave a few hints during the presentation. Short reminder, it is very hard for the students to step forward in this crowd. So you need empathy for them. It's a big effort. They're shy. And the feeling that they have is, who am I to their step forward, me little insect in front of those giants? This is the feeling that they have. We need to help them. We need to welcome them, the French words coming, sorry. But we need to welcome them, help them grow. So this is very important in the communication. Be careful with one-on-one communications during public phase. I already mentioned it on the Gitter channel. I receive regular requests for one-to-one chats on Gitter. Upfront, I refuse them systematically. It's not because I want to ignore them because they're not worth it. It's because I want a fair distribution of information to whoever. It's a competition. And it's also a key principle of open source. Everything needs to be done in the open, can be reviewed by whoever. If we break this foundation, then suspicion starts to install and you start to have bias and then it goes wrong. My responsibility is, Org Edmund, is to look at all that works correctly. Another important rule of thumb that I wanted to share with you is, and something I try to remember myself, is phrase is always given in public. Critique, especially hard critique, is shared in private. And be careful the way you present the thing. You can hurt people. And this is not the purpose of what we do here. We want to grow. I have an image that comes in my mind. I'm running out of time very shortly. When you have a plant, a small plant that's growing, you need to cut a few leaves here and there. So you need to put water and make it grow in a certain moment. Okay, you need to go there. You need to be very delicate in the way you do it. If you do, and especially in some cultures, giving critique publicly, people lose their face, hope this is correct English, and this hurts, this hurts a lot. So communication is key in open source. Let's do it also on an important, in a good way. I reached the end. Three minutes left for questions and answers. Is there something that I can clarify or something I forgot to say? Go ahead. Yeah, I do have a quick question. Can a mentor mentor more than one project? Very good question. Yeah, very good question. The first statement is experience has shown that mentoring two projects is the best way for failure. Seeing the involvement and the importance, I very strongly discourage mentoring two projects. Okay. So if you have doubts, if you're wondering, should I go there, this project or that project, this is something that will clarify when we will start seeing the proposal. And I will request that students step forward in their preparation process. No, not that we have proposal raining in from who knows where, two hours before closing. We never heard of them. I have no idea. And generally, they're of very poor quality. And so it will clarify. This is something we can discuss. But you will need to have very strong arguments to convince me and the rest of the team for an exception. The only difference is or comment I can do is doing org admin, org admin and mentoring together. My experience is personal experience and in my maybe one day I'll tell the story is you need to be concentrated on the task. And you can have a focus, especially when you're younger, you can do two things at the same time. In order to do the things well, you need to focus on one or the two things and the other will be minor. So in the case and I know you would like to to mentor Chris and this is perfectly okay to mentor and be org admin. Now I know that I will be involved quite a lot in org administration. So normally I will not mentor a project. But this can be discussed if there are not that many projects that make it. So nothing is written in stone. But I just give what the general rules are. In my case, I know org admin is important to me and I want really that this works well. I will not have spare cycles to do a good job as a mentor. But does that answer your question Chris? Yep. And also it's like to what extent are we supposed to help the student or the contributor to draft a proposal? Did I understand the question? How do we need to encourage the people to make their proposal public before? To what extent? It's like they make a draft and how much are we supposed to help them to add the draft? May I offer an answer, John Mark? Yeah, go ahead because I'm a little bit puzzled. So the past pattern had been that if we don't actively engage with them while they're preparing a draft proposal, they are very, very likely to create a draft proposal that's missing key elements. So Chris, the crucial thing for us, at least for me, has been read every one of the draft proposals and make very blunt comments about gaps and absences and flaws because we ultimately tend to use that proposal as the initial project plan. And if it's weak, those weaknesses will come out later and hurt us. I had several where we made the mistake of not being detailed enough about a particular aspect of a project. And we had to then develop that detail later on during the project itself. And it was much more awkward then, much more painful and much higher risk because we actually we came into the project not knowing the answers. So coaching and encouraging in this early contribution stage is crucial and give strong feedback. Hey, you're missing this section, you're missing, you haven't thought about this. Please describe that. Okay. You said it much, much better than I said. I don't know. It was a little bit of balance, but 100% with you, Mark. 100%. John Mark, I did have a question and it's actually targeted at Freya, at Diraj, and at Rajiv. I think it would help me as a candidate mentor, if I could have some time to talk with other mentors about the projects they're interested in, would the three of you be willing to meet together as a potential mentor team, even early on to say, hey, let's do more detailing of this idea together, to gather our concepts, et cetera. Right. Yeah. That sounds good to me. Okay. So if you're willing to share your email addresses with me or with others. I have the email addresses. Oh, you do. Great. Okay. So I can share them with you. That at least for me would help me focus my thinking process and illuminate some dark patches and be sure that, okay, I understand where we're at. Great. Okay. One thing that probably slipped through in my presentation is that, I'm going to stop this here, is that the next important milestone that we're going to have is as soon as we know that we're accepted as an organization will organize a kickoff for all everybody on board, mentors, mentees, candidates, and whatever. And we're going to explain how we're going to work together in this preparation phase where the people will work. And this is the adequate moment where we can organize the meeting where Mark hinted to, where the mentor teams can start to learn each other and know this, going to click this, going to work. This is where we can focus on and learn better who we are. So this is important. Go ahead, Chris. Oh, is that okay? Sounds like a good idea. Yeah. Okay. Any other questions? I'm sorry, I'm six minutes late. I won't do it again. But we had some great presentation of the teams and the people around the table here. I left some time for the last question or comment. So thank you very much all to attend to have shared your ideas and background and to participate to that. And I'm super happy to start this new adventure with you all together. And looking forward to have a lot of fun together. Bye, everybody. Bye, everyone. Thanks.