 on the cloud. Okay, we should be recording right now. So I'll get started. So hi everybody, welcome to the Jenkins in Google Summer of Code webinar. This is for Google Summer of Code 2023. So this webinar is to help address the question, how do I get started with Jenkins in GSOC? So hopefully by the end of this session, it will have helped you, you know, get started, figure out how to get started, what to expect, and so on. So my name is Alyssa Tong, and I'm an org admin for GSOC. Along on this webinar with me are Jean-Marc Mason, also an org admin. Bruno is also Bruno Verrachten, sorry Bruno, is also org admin. Chris Stern is our org admin as well as a mentor. And then Marc Waite is a mentor for GSOC. So next slide please. Yes, thank you. So some housekeeping notes. So we are recording this session and I'll make the recording available within discourse and Gitter sometime later today. So for Q&A, feel free to put it into the chat window. We will answer them as we go along. And if we have time at the end of the webinar, we will open it up to Q&A as well. So for questions that, you know, that may come up after the event, feel free to put it into the Gitter or discourse channel and then we will get to them, you know, as we see them. And of course the Code of Conduct applies here as well. So basically what it means is be kind to one another. So next slide Jean-Marc. So this is what we're going to talk about. You can quickly go through it Alyssa. Yeah. So in this session, we will cover what it means to participate in GSOC. And as I mentioned earlier, what you could expect and what is expected of you. We'll quickly go over what is GSOC, Jenkins and GSOC, and some important timeline that you need to remember and stick with because Google Summer of Code, they're very adamant about sticking with the date that's been given. And we do the same as well. So we have to follow those dates and those deadlines. And then as I mentioned, like before, Q&A will open it up at the end. But if you have questions during our presentation, just feel free to put it into the chat window. And one of the org admin or mentors will answer them. Great. So well, welcome everybody joining the call or listening after this live session. And basically, so you want to participate in Google Summer of Code short GSOC. Well, that's a good idea. And it's a great decision that you're making. So with this adventure, you will learn a lot on technical fields about open source. And you will do that while being coached by people. So it's a great way to learn and get experience. It's also an incredible opportunity to have an impact by your work, which you can have with open source very easily. But here you have really a great opportunity that your work will be useful and will change something. Participating to Google Summer of Code is also a nice way to get some pocket money. So Google has big pockets. And they want to teach people and to promote the ways of open source and open source. And we're very thankful for them to sponsor these kind of events. And participating to it is a nice way to get some money. And who knows, by yourself, a new laptop or whatever you need for your studies or for your starting career. And talking about career, participating to Google Summer of Code is also a great way to add a prestigious line in your resume. So there are many, many reasons why people are interested to participate in GSOC. So what is GSOC in a nutshell? GSOC is this. It's a great adventure. You will see great things. You will do great things together. And this picture for me really summarizes everything. You will get to places where you didn't think that you would get to. And like Alpine Adventures or Himalaya for people in India, which is there, this can only be achieved as a team together. Generally, you have a guide that brings you to explore these incredible sceneries and participate to these adventures. There are pitfalls. It's not always sunny as on these pictures. It's tough. You'll have to walk. Sometimes the feet will hurt. It will be cold, damp. And this is part of the adventure. This is why people like mountain climbing. I want to warn everybody that wants to participate to Google Summer of Code. The Jenkins team has only a limited or finite coaching capacity for Google Summer of Code. That means there are only a limited number of slots available. And not everybody will be selected. So the selection process is already part of the schooling of the adventure. It's the first big hurdle to win. So only the strongest proposal will be selected. And on the criteria, what are the projects that are the more likely to be successful that will have the best and useful contribution to the Jenkins project and the best return of mentoring and investment. So we need to find a balance in all that. The other important thing is that you need to know this is a long and important effort. It starts with a proposal. It will take several weeks. You need to be involved. You need to do your work there. It's exactly like climbing a summit. It takes a lot of effort to get there. And you need to get prepared for that. And this is the presentation we have now and the kind of advice that I would like to share with you. In order to reach the summits that we've seen in previous pictures, where you prepare. You get in shape. You lose an extra kilos, which I maybe should do myself. To do that, you build muscles. You build your technical expertise in order to do that. And then there will be the selection process for that. So a couple of words. What is GSOC? How does it work? Where is the front? Where is the tail? And where does it start? So the first important thing to do is read the available documentation. There are a lot of explanations around. Don't hesitate to read it once or twice and then ask the questions. How to do. We built over the years. It's the seventh year that we're participating to that initiative. Very proudly. We built up a lot of references, useful references for contributors. Word contributor means in the new definition of the program before it was limited only to students. People that were graduates or doing a master somewhere. Now it's also open for young professionals. So these were the word contributors. Have a look to the projects that were presented last year. Look how they were documented. Listen to the presentations. They succeeded. It worked with them. Get inspiration. Learn from the people that were before you. Google has also some very good pages and good readings on how it goes. What is a project idea? What is the role of mentors? What is expected? A lot of document. Take the time to read it. And we'll have other opportunities during the process where we can discuss together in where we're available to answer questions. The only thing we would like is that you have read and you know the theory of the program. So how does it work? So we're currently in the very initial phase. Google announced a couple of weeks ago. Yes, we're going to do Google Summer of Code 2023. So very initial and we're starting. This is the moment where you can build if you're interested to participate with the Jenkins community in Google Summer of Code, you can build the Jenkins muscle. How do you do that? You do that by understanding the Jenkins product, experimenting, reading, start your own Jenkins instance. And Chris will give you some tips and advice afterwards. But you also learn how the ecosystem works, how the community, how do we communicate? And there's one strong point I want to make available or are you aware of, I'm sorry, is that the purpose of the initiative of Google is to learn how open source works. It's different of how companies work. A lot of things that are shared, but open source has one principle that you need to remember is that everything is done in the open. You share. That means that when you're going to work on an idea, when you're going to work on your code, you're not going to do it in your corner, in your den somewhere and only show it at the end of the process. Here the process is that everything that you're going to do, everything that you're going to build, that you're going to learn is written down somewhere, shared, that everybody in the community, there are many time zones involved, there are different skills involved, but everything is open. So you're going to write and prepare a project proposal, all that is done in the open and you ask the community, what do you think of that idea? Nobody has a comment about that? Okay, then we go on, but at least you have described your idea and you requested for comment. And so I'll come back later in the explanation. So this is how the community works. Read, listen, observe how it works, the principle of pull requests, get your hands dirty with that. So this is something that, and this is now the right moment in December and January to learn these kind of things. Nothing to really worry about, nothing really with deadlines or so, you can enjoy the end of the end of year period, depending on the region of the world where you are festivals are different. January, February, you're going to start studying more deeply and choosing a project idea. So project ideas are currently being built, discussed, and are available for review. Start reading them, start understanding them. So I'm just going to switch quickly. No, this is not what I wanted to do. There it is. So this is the Jenkins IO website, is the main Jenkins, and you go in sub projects, Google Summer of Code in Jenkins. This is the main page of our project of our initiative where you have a lot of explanation. This is the GSOC home page and we'll update it regularly. This is where you have a direction to all the various documentations. This is the section that you should look for in start reading. We have some dedicated guidelines, good readings, a couple of books also that are mentioned on the Google portal. Have a look there and you can look, for instance, everything that's available here, what the communication channels are, office hours are going to talk later. These are here the current lists of projects we're working on. I just walk here. So the first status of project ideas are the ones being discussed. That means somebody woke up in the morning suddenly and I have an idea. And he writes it down, people discuss us, but what do you mean? What would be the outcome and so on? And so it starts to crystallize. Currently we don't have any projects anymore that are in this very early stage. These are the projects that are in draft mode. These are ideas. We have a rough idea what it could be. Not all have mentors assigned to. When you click here on it, which one can I take? I'm going to take this one here. So you have details on what is the background, what are the skills required, what is the difficulty, what are the outcomes and a lot of details. This is the first stage. Study them and try to understand it. We're going to organize the second half of January, one or several sessions where the mentors will present each project idea in more detail and you will be able to ask questions and know what you mean. I understand it that way. Is it in line? I have this novel idea. Everything is done in the open. Everybody here is the same. So we discourage any one-to-one discussion during the whole process. So you can already start to look so you know what to explore. So you can focus your learning process. So this is what's going to happen the first part of the year, January and February. In March, February and March, this is where you have chosen a project and you're going to build your proposal. Now we're going to do something at that moment very unnatural, especially unnatural compared to what you've been taught at school or so. The first principle at school, you don't cheat. You don't look what your neighbor is doing and you protect your work that somebody is not going to cheat on you, but this is not the way we work. It's the common effort that will make the product and the world better by working together and sharing all the ideas. You may start an idea and somebody at a certain point will add ideas to yours and yours will get better or somebody else will come and will compete with yours and add other things and at the end we're going to decide which one is the strongest idea which has the best chances to reach the goals that we want to achieve with the program. So that means that we very strongly encourage you to publish your drafts and make them available to everybody, meaning that the mentors are going to read your drafts and going to ask questions here. I don't understand this. What do you really intend to do there? Can you make that more precise? The community, that means that all the people that are either users or contributing to Jenkins will also ask questions or tell you here, this has been proven to be a bad solution. You're going to burn your fingers with that. Try this method or try this goal or these kind of things. So it will be a very weird process for you, but believe me, it's a very rich process and it will make your draft, your proposal, stronger. Yes, somebody can come and pick your idea. It may be faster than you, but it's part of the game. So you need to be the best you need to learn and we're there to help you and we're there to help everybody the same way. So there is a little bit of what's English word for that, but natural selection of idea. It's tough, but this is the way it works and this is why we don't want to privilege this person or that person by giving him insight. So this is something you really need to understand. We're going to explain that further. So we'll organize regularly during that period what we call office hours. That means that we're going to organize a meeting every week. We're trying to look to have the correct time zone to have it friendly for the biggest, for the majority of the participants. I see from the names here that will be more on the Asian side, but we'll organize a meeting. That meeting is just where here I'm there and what are your questions, what are your concerns, what are your doubts? How can we advise you to move ahead? And this will be the backbone for you to progress and move along on this adventure and learning how to move ahead. So mentors will be there, org admins will be there to help you. April 4th is the moment where the dice are rolling. This is where you must have submitted your proposal. So this is the goal of the first stretch of your GSOC adventure. Why do I say the dice are rolling? It's because you have no influence anymore. You've done all your work, you put your heart in it and now you need to wait. What will happen in that period is that the org admin and mentors will read in details all your proposals, will reflect on them and will rank them and will build a proposal with a number of slots that we're requesting from Google and providing them evidence of what is the coaching capacity we have. And so Google and our organization will come with a proposal and say these are the number of slots that we request. These are the projects that we want to run this year and these are the people we select in these projects. And this will be announced May 4th and this is where it really starts. So all that is a preparation and you will realize there's a lot of work involved to get up to there. From May 4th, this is far but in a nutshell what will happen is that during a period we call it the bonding period. I find it a funny word but you will first learn to know your mentors and the mentors will learn who you are, how you work, you will set up a work framework, how are you going to work together, you're going to work out the architecture, what you're going to do. So set up the framework. And then about mid-May, well it depends because we have an elapsed period for the complete period. Then the actual work will start and how it's done will really depend from project and mentor teams and how you get organized will also depend on your holidays or if you have mid-term exams or this is then left to the freedom of every project. The organ men's will be there like a fatherly figure saying that everything goes well and that no fighting in that we get the goals achieved. There are two milestones, two important milestones that you need to know but we'll give details later is that somewhere during the summer we're going to do a mid-term presentation and evaluation where did you reach, what did you achieve, what are the things that you can show and brag about. And then somewhere in September we'll have the end presentations and also presentation of the deliverables and we'll do a wrap up. So this is the timeline. I realize I have been in a lot of details and I've eaten a lot of time so I apologize for that. I wanted to give enough details about that. Now to the more technical part and I give the word to Chris if you can give more details on the technical part and how to build the Jenkins muscle. Okay, sure. So I'm going to talk a bit about tech stack we're using at Jenkins. So most of the projects are in Java, some in Kotlin and for website it's mostly in Java services as in Ruby. Some projects have been in bash so it all depends on the requirements. And for the web development of Jenkins.io which is a project idea we have for this year for our main website we use ASCII.org. There seem many project ideas involve proof of concept and documentation such as the website we've done I just talked about and also some Android and OS projects. Many of the projects involve tooling or development tools. So it's a good idea to read up on these and do some research and make a good post on the next page. Okay, so how to prepare? First thing first we're just to do research on the project idea you're interested in. That's important because you need to have a context and we don't normally give out too much about the context. So you have to be original and be able to come up with some solid ideas about what it's necessary to make a successful project. And two, do ask and tell any questions on IRC such as Gitter. This is because it will help us to differentiate to tell who is more likely to be able to successfully complete the projects and will choose the contributors accordingly. And three, interact with the community. So don't just think that it's all about what we saw. A large part of the application has to do with the interaction as well. So do do engage yourself with any conversations you might find interesting or you might find rather than to your project idea. And four, develop your proposal with the community. So like Jean-Marc just said, develop the proposal with us. So ask questions, share your proposal, policy with us. If you have any doubts or questions, do ask. Five, show us what you can do by submitting pull requests, patches, fixes, impactful contributions. So I think I've heard from some other organizations that they do consider pull requests as a must before they can accept an application. But I don't think that's the case for Jenkins, but we do appreciate any pull requests submitted as part of the application process. It's a good sign for success, a good indication for success. Yeah, yeah, true. Okay. So next, so it's to remember. Remember to check Google's program timeline, which is allowing to given and to adhere to it, because like we have very, very strict timelines and we don't normally like give grace periods, even if you have very legitimate reasons to be late for something. So GSoc contributes to application period begins on March 20th at 6pm UTC. So that's, I think that's about March 21st Indian time or Asian time. And GSoc Contributor application deadline, it's on April 4th, same 6pm UTC. So that's April 5th, Asian time, except GSoc Contributor projects were announced on May 4th, same time, 6pm UTC. So don't be late, be on time and be prepared. Yeah, that's important. I'm going to pick up here, Chris, or you can jump in afterwards. Here are some resources. At this point, I just would like to pull into the conversation last year's participants. So we have Hushikash, if I can see correctly, I'm not monitoring chat. So Hushikash quickly, well, not quickly, but take your time. But what would you like to share with this year's candidate for GSoc? So the first question is, what did GSoc bring to you as an experience? And what worked well? And you would have done better if you had known or what is your experience. So can you share a little bit your experience of last year? So yeah, so I feel communication is a key for a successful project. Initially, I was a very shy person, you know, I didn't know what kind of questions to ask. I was worried what people would think about me. If I asked some silly questions, I was very anxious to share my ideas. I didn't know where to get started. The Jenkins code base is really big. There are so many files, you don't know where to get started. But Jenkins community did make it easy for us. It was a very comfortable journey. I didn't know how those three months just passed. But then it was a very smooth journey. I did face a lot of challenges. But in the end, yeah, you have to just get started, explore the code base, be very active in the community, and take the help of all the people in the community to create a very strong proposal. That's sound advice. Thank you for your comments and advice that I really cashed. And it comes also to my experience. And having seen you travel on this path and your climb on the mountain and reach the summit, one of the key elements is how do you communicate how do you efficiently ask questions? How do you explain what you intend to do to ask for advice, direction? It's like mountain climbing. I don't know if you're familiar with it. For me, it tells us something. In order to reach that, you need to communicate with your teammates. You need to explain what you want to do and ask for feedback. So this is key. It's a hurdle. Pushy Cash had some issues in the beginning. It was, I remember, very shy in the beginning. And who am I to dare ask to people like Mark Waits or these knowledgeable people? I'm just no. You're an important person. You come with your experience. You come with your heart in that adventure. You're worth that we as a community take the time to help you. But we need to get that discussion going. We need to get that. So this is the most important advice. Efficient communication. Don't assume that the person you're talking to is sitting near your desk and sees what is your on screen. It doesn't work. What doesn't work or what did you intend to do? What are you trying to do? See these kind of things. Don't assume. This is what I feel a very most important lesson in this complete adventure in one of the keystones of open source. So thank you, Rakesh, to have stressed that point. And now I've eaten most of the time here because we're now listening to your question. And so you can practice the first lesson being don't be shy. Ask questions. We're there to help you. The first question was from Aditya, if I pronounce it correctly. It was, can I contribute on these draft project ideas from now? Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Yes. Go ahead. Mark, how can we do that at this stage? So there are two different ways to contribute and then I will give the word to Mark who isn't as his own experience than maybe Chris Kim chime in. The first way to contribute and clarify is to submit a pull request on the project proposal. And this will be then reviewed by the team. This is not the most efficient way to do it. If you have lightweight ideas, questions, queries, you can use community.jenkins.io which is the discourse where you can start here. I don't understand this work, this work. Where should I look for it? But nothing refrains you to really start giving structure. And if you have ideas, you can really start contributing on the idea for that. Create Google Doc document. So we're sponsored by Google. So everything uses Google tools which work well for that purpose. Create a Google Doc document. Good idea to use the template. That's available. Generally, these kind of contribution, these kind of working is done in a later phase because now the project ideas are still very fuzzy. But here, if you already understood it and you come with novel ideas in it, go for it. You've seen what Mark reaction on that. So to summarize, can we, yes, yes, yes, three or four times yes, how discuss on community or Gitter, but community is better for that. You can update the proposal that's on jenkins.io, submit the pull request, and even start creating your document, make it public, and announce it on the Google channel on community.jenkins.io. Mark, was I, do we have things to add? Do you have other advice or? No, I think you did great. The answer for me is, can you contribute to project ideas? Absolutely. You can do it by getting involved in conversations on Gitter Chat. You can do it by getting involved in conversations on community.jenkins.io. You can do it by getting involved in conversations on the Jenkins developer mailing list. You can get involved with the project idea in the advanced way that John Mark said, of submitting pull requests to the project idea to propose refinement for it. I think that for me is a later stage, but just being involved in the conversations about this idea, helping clarify, because inevitably, if you have a question about a project idea that's listed there, others have the same question and they're too timid to ask. So you be the bold one, you ask the question and accept that people will give you an answer. Chris, do you want to add something? Oh, Hushikash, anyone? I had one point I wanted to ask. I wanted to just add, don't get dejected if your question is unanswered immediately. It takes time for the community to answer your questions, but I'm pretty sure someone or the other will answer your question. That's a very wise and very true comment, Hushikash. Thank you for sharing that. Yeah, we're working around the clock around different times on market. Yeah, so we sleep. It's a very good point that we sleep. And I actually sleep at different times that other people sleep at. India is almost 12 hours away from me, right? And therefore the time of day for you, for Hushikash, for instance, is usually exactly opposite from my time on the planet. Welcome to a worldwide project and the complexities that come with being in a worldwide project. One of them is we're not always awake. The other is many of us have jobs in addition to being contributors and we want to be sure that we do all the things. So ask your questions. Also, don't be shy if it takes a while to answer your question to refresh it. Hey, did anyone have this? Can anyone help me? Sometimes a question that's asked is challenging enough that it actually requires some research from us and from one of the people who would respond. And that research may be non-trivial. So if you ask a really hard question, be extra patient because sometimes really hard questions require really good investigation. But we also have the holidays that's that's approaching. So expect some delay there as well. Very good comment. Yeah. Are there other questions? Mark, can people turn unmute themselves to ask questions or is it? If they'd prefer to ask questions verbally, they certainly can. They've been given the permission to unmute themselves. Vandit, let's take you to its question first. He says he usually takes four or five hours of research and development and starting on an issue. Should he be speeding things up? None of us are worried about how fast or slow you proceed. Truly, none of us are worried about your pace. That's up to you, what time you have available and what you can do. So work at a speed that's comfortable to you. I spend a lot of time in debuggers. I spend a lot of time writing automated tests. I spend a lot of time interactive testing, none of which is actually writing new source code, and that's okay. Vandit had the question, if he gets stuck somewhere while working on a patch, is it silly to ask for a review? Not only is it not silly, it's encouraged, highly encouraged. The best form of ask a question is usually submit a poll request with your idea of how you think you're going to do it that shows you've done the work to make your poll request compile, that you've understood enough to think about the tests for it, and you've submitted it. Now, it may be that you say, hey, I'm submitting this with a failing test. I don't know how to make this test work. That's okay, great. That's a good way to ask a question, because I can look at the source code or others, Bruno or John Mark can look at the source code or Chris can look at the source code and say, hey, your source code is making this mistake. That's a much easier answer than, oh, it broke. If it broke is all you tell us, we're going to say, well, fix it. And that's not helpful to you and not helpful to us. Okay, I think that's one more question from Pranav. We have PR, should I submit, should they be good first issues or some advanced issues? I like that question. So submit a poll request, it can be either a good first issue or something more advanced, whatever, whatever helps you build the skill. What John Mark described it as is building, developing your muscles for contribution. And part of that is you develop a skill, the skill to phrase your poll requests well, to understand what the expectations are from reviewers as you submit a poll request. Oh, you didn't, you ignored the checklist. No, don't ignore checklists. Oh, you forgot to add tests. No, don't, don't forget to add tests. Please add tests. It's good work to add tests. Oh, you forgot to interactively test it. And we'll be sure you test interactively. Those are all part of the process of submitting good poll requests. And there's still you can develop. Go ahead, John Mark. Right, no, it's building your muscle is building the skills and it's a way of working. And just remember, if you're still studying, these skills will be very useful to you when you start your working career. So it's a great opportunity, even in the selection process, everything that you learned in the selection process will be useful for you in your, in your studies and a future working career. So it's worthwhile to do. And if you're not selected, next year will be there and you make a stronger proposal because you've learned a lot of things. So it's worthwhile to invest, even if you believe that you don't have a chance, which I personally don't believe. Speaking of selection, John Mark, Sorab is asking on which basis do you select students? Oh, now, to be honest, it depends on where the moon is standing, what is the height of the water and so that's not true. So I'm making a joke. So the selection process uses several criterias. And if I remember well, these were written down last year, I will make sure that we have guidelines for that. In a nutshell, the, and I'll go back to where I wrote it down. So here only strongest proposal will be selected, which are the projects that have the best chances project and contributor have a best chance of having a successful outcome. That means that you've shown that you have the communication skills that you understood problem that you're able to explain what you want to do and that you've shown that you have the right stuff to bring it to the end because we have three months to do that. I'm sure and convinced that everybody will succeed. It's only that some people will need more time and more help to do that. And others, it will be quicker. We need to select. So it's, it's, it's competitive. Other criteria is, is the project useful to the Jenkins project, to the Jenkins community? Because you can come with your own project idea. We've been selective. We, we worked out some proposals for you to work on. These are, these are good. These are useful. But some are more useful than, than others. For instance, I know I'm not going to give hints there, but try to put yourself at the place of, of users of the community. Oh, that, that will be useful for people. And this is how I will make it more useful. Don't forget to explain that. Third criteria is, and there we will be assessing your skills as a contributor. Where will we have the best return on the mentoring investment? If we have two equivalent projects and two equivalent proposals, if one project will require an involvement of the mentors of, let's say, 10 or 15 hours a week, and on the other side, we have a contributor who we assume that he's self-sufficient, that he knows, so we don't need to explain, for instance, what is a unit test? Or, or he can solve simple problems. We'll prefer to select this contributor because we then, with the mentorship, a capital that we have, we can go further and go farther in the, in the project. Did I answer the question? Well, I think so. Some people were also asking about building the Jenkins muscle, and Mark's suggestion was to use improved plugin tutorial for Jenkins plugin. And I still have lots of things to learn about Jenkins, but this part helped me quite a lot. And there was a previous suggestion from Mark, which is go ahead and try Jenkins on your own. Use Jenkins to build a project that would be useful for you, that what I do on a daily basis to progress on my knowledge of Jenkins. So yes, go ahead with the improve a plugin tutorial, install Jenkins on whatever machine you have, be it your laptop, Mac, Windows, Raspberry Pi, whatever, even the Oracle free chair, it works just about everywhere. So go ahead and try that so that you will build the two kinds of muscles, some muscles for improve a plugin tutorial and the muscles of using Jenkins on a daily basis. So to give more weight to what Bruno was describing, I have, I like the concept of healthy self interest. Healthy self interest in this case is a way of saying, do something that is interesting to you and use Jenkins to help you do it. So if you have an assignment at university that is write some Java program or write some C sharp program or write some Python or some NP some node JS, whatever. You've got some assignment, install a Jenkins controller and let it help you build that thing. You learn it helps a little bit. And you've now used what you already know. Oh, I knew how to build this project for university work or for school work or for whatever. And you learn something about Jenkins in the process that exercise of using Jenkins to do something that matters to you helps you and will help prepare you to contribute to Jenkins. Well, I just opened the chat. I've seen a question from it about joining discourse and Gitter. I agree with Bruno, but they're complimentary. So they're two different ways. So you don't have to. But it's good to have a foot in both. So depends how much time you have. Are there other questions? I see there have been quite some activity in the in the chat. So don't be shy. So while you're thinking in fumbling to find the unmute button, I see that Nittish has unmuted himself. You have a question? Either Nittish has a communication problem. Hi, everyone. Okay, I wanted to ask if I wanted to ask if I'm not on the discourse channel. Should I need to join because I'm only on the Gitter channel, because I find it more active and easy to use. Do I have to join the discourse one too? As I say, good question. So thank you, Vanit. They're complimentary. There are different ways of communicating. I would recommend the following. So connect and register to discourse. So the community.jankins.io. They're interesting announcements that are made there. Connect to it. Look if it works for you. If it doesn't work for you, just leave it alone. So and continue using Gitter. Did that answer your question? Yes, Mark. Thank you. No problem. Well, here I have the same problem pronouncing correctly first name. I hope at the end of this G-Soc adventure to learn or I need to come to India and have a crash course and pronouncing first words. Yes, I'll be eagerly waiting for it. This is what I fear. It's too many things to discover over there. Don't tempt me. Great. Are there other questions? I want to be respectful on people's time. It's probably already late. I had a question. I want to know that since we have different time zones. So I was thinking if I want to ask a question on Gitter, should I ask them like around this time, like what the current time is going on, or should I later on in my morning? So currently I'm working as a professional right now. So I have time in the morning or late in the midnight around midnight. So I can work and ask my questions during this time around this time or after seven to eight hours. So when you guys will be able to answer my questions, right? If I ask me questions right now around this time or after six to seven hours. I love your question. It's a great question. So the short answer to that experiment is how it works and what works better. The problem they exposed here is a typical problem of when working on open source and also in professional career when you're working in big companies. And one of the purposes of this here is to learn asynchronous communication. The whole communication process is key. Different ways to communicate. One is synchronous. This is what we have now. We have a meeting, but you have to stay late in the evening or people like Alyssa need to wake up in unruly times very early for her or I need to work and so. But you can exchange a lot of information synchronously in a meeting or in a chat where you have immediate interaction and where you have rewards. On the other side, you will have different type of answers and very often better answers. If you really go into the asynchronous way of working, it has other requirements, but you reach a bigger crowd of people that way. That means that you're going to reflect on how you ask your question and you're going to receive an answer several hours after. So it's really about mastering the different communication channels. Now to be precise in answering your question before giving the word back to you with it, the majority of interactions here is asynchronous. And Mark and Alyssa have emphasized that in the period we're getting in, I'll be visiting my grandchildren will be off. That means that we will not be able physically to reply immediately because either we're sleeping or I will be playing with the kids or and I need to sneak out to get a laptop to answer you. So we'll enter these kind of periods where this but in your project, once it's starting to be efficient, having synchronous communication moments will be useful. So you really need to learn and master the two ways of communicating and depending and we'll make the two types available to you. Did that answer your question with it? Yes, I got it now. I won't be thinking much of it. Should I answer? Should I question? Put the question on later in my night at my time or in the morning because generally you might you might also might be having holidays, so it won't guarantee answer to me. I'll take care of it and I'll also make sure to master both the ways of communication as usual. Thank you. Here, try it out. You will learn. You will learn how it goes and but don't expect an immediate answer as Hoshi Cash also mentioned that. If you don't get an answer immediately, it's not because your your question is useless or stupid. Just leave, let time to answer the asynchronous way of doing it. Are there other questions? We're two minutes overboard but Alissa is going to frown at me and say I talk too much but I think we have time for one more question, Alissa. Sure. Okay, one last question. Oh, then we answered all. So, I'll leave a couple of seconds. Mic open. Hi, John. Go ahead. Is there anything specific we need to know about Jenkins Chira? Anything different? Because I use Chira in my professional environment. I know how it works but is there anything different to know or is it... Yeah, just explore it. Try it. People will kindly say, oh, you shouldn't do it that way. Not all the features are available on it. It's not a super duper version. It's free. It's donated so we don't have all the gadgets on it. So, Mark, do you want to add something to that? So, if you need to submit an issue report, please review the how to report an issue instructions that are on Jenkins.io. If you have a bug report and it is inadequately described, you're doing yourself and the maintainers who might view your bug report a disservice. So, but that's the same that you would get in any use of any bug tracker, right? Write good bug reports. The permissions are generally pretty open on the Jenkins Chira and it's intentionally so. So, you can make comments anywhere. You can assign bugs to yourself at any time. You just need an account. Once you've logged in, you can assign things and you can work on them. Don't be shy about doing that and don't be shy about unassigning it if you decided, I don't want to work on that anymore. It's okay. Okay, thanks a lot. Thanks a lot, John. So, we'll slowly have to wrap up. So, I'm personally very happy to meet you and to start this journey together with all of you. Remember, I'm sorry to be first there. I will not answer requests to do one-on-one discussion. There is only one exception to that. I explain it another time. It's not the purpose here. So, I will not accept these. Ask your questions publicly so that everybody can learn from your question and you will learn from the questions that others are asking. The next step now is good luck and bon courage. I don't know how you say that in English, but be strong in building your Jenkins muscle and will organize another interactive synchronous meeting somewhere in the middle of January where we'll go more in details on the project ideas, give explanations and answer any questions on them. Stay tuned on Gitter and on the GSOC channel on Gitter and on Confluence on community.Jenkins.io and Twitter for announcement when this will happen. Thank you very much for your participation. Thank you very much for your interest, your questions. I'm thrilled. It's probably most of the org admins to see you here and to be part of that adventure. I'm looking forward to that. Thank you. So, we can end the call here, I believe. Yeah. Thanks, Jean-Marc. Thanks, everybody, for participating. Thank you. Bye-bye, everybody.