 So, yeah, we are recording this session as all other Q&A sessions, but we won't be publishing this video unless there is a strict need to get it published. And, yeah, this, just to explain the purpose of this meeting to those who joined the first time, it's just a Q&A session. So we have mentors, we have students joining the call, and then we have a Q&A with everybody. So if you have a question, just ask, if maybe whatever question about the project organization. And yes, our preference that we focus on questions on project organization here, if you have questions about TILU, it's your project idea, and we'll advocate the discussion with mentors because we can guarantee that proper people will be on this call. So we guarantee that we will have at least one or can mean a bit more, but, yeah, then we will do our best to help and to provide any assistance, but project-wise it's really recommended to work with potential mentors, and in each project idea, we have a list of these potential mentors. Okay, that's what was a quick introduction. And, yeah, we can just wish to any questions you might have. Can I use my screen here? Yes, you can. Okay. So there are some questions concerning about the external workspace manager. And I ask it in both channels that, you know, currently it is kind of like we can use cloud storage for a current external workspace manager, since it has nothing different than an NFS, so what we're going to do is quite like just using some command line configurations to mount the EFS to the instance, to the like the AWS CS instance. And here, once we mounted it, right, and so the disk pass, the mount point is no different from the other physical disk passes. So, and then the external workspace manager can actually use that network file system, just like using other physical file systems, right? So, so I, on my own understanding of supporting the cloud storage is that we are going to help the users to configure the cloud storage, and that they don't need to mount the EFS to their instance. And they just need to give Jenkins some parameters like the name of the, the name of the EFS and some credentials, maybe passwords, some PEM file. So, and once we, the plugin has those information, we can call some command lines or call you some OS functions to establish the connection with the NFS and then use it as my understanding, right? Sure. So, can you comment on that? Yeah, so speaking of that, yeah, even if you can connect EFS as a common shared storage, we can find some potential use cases there. For example, external workspace manager plugin also supports the retrieving data about the remaining disk space and whatever, and you can be calculating the data using select calls on Unix and Windows systems, but it might be much better if, in such case, you use native AWS APIs. Another example is provisioning for four spaces on agents. Because even if you have credentials, you may still need to provision the workspace on agent, and it would be some logic there. So, you can require users to map EFS on their own when the provision platforms. It might be possible, but in many cases, you want it to happen automatically. For example, you have a cluster with automatic provisioning of agents, and you want EFS to be connected on demand. For example, inside a Docker container, maybe Docker is not a good example for this particular case, but at least you may be using EC2 plugin, and you may be still learning on this external workspace, just provision particular chunks of data on demand. So even with EFS, you can find some use cases. You just need to look around to see how Jenkins works and then come up with such proposals. And there is some question concerning about the multi-stage pipeline jobs. For example, here. So if I get up here, this public job got two stages and running on different agents, right? Is that okay? Yeah, it's okay. And then, so what will happen here? You like supposing we're going to copy a Git repository in this stage? And we were going to do in this second stage that it will copy all the contents from the first one's working space to its own working space, right? And so what will happen if the build discoverer, like the log rotator do in this scenario, since it's got two machines and they've got two different workspace spaces to delete? And how will that, how will that log rotator behave? It's a good question, but this is the question actually we want to answer. Because currently your workspace is getting deprived vision. So here you use a Docker agent and the effect of it means that workspace will die when you deprivation the container. So it's not a problem for this particular pipeline. But once you start using external storage, like ex use external workspace manager, but again, also where you will have to manage this provisioning. And it would be one of the topics for workspace manager plugin. Are so this is going to happen are. And the second thing is. Yeah, let's try to sandbox discussions because I'm sorry, time box discussions because you have many students on the call. Okay, okay. You just leave the time for it. It's not a problem to answer multiple questions, but yeah, regarding details, it's better to press it. Yeah, I propose to return back to this topic, but yeah, maybe we should talk with other students and then return back. Yes, I'm done with it. And anyway, I was going to ask questions. Okay, so does anybody have questions, preferably about the project organization, about the process, about the next steps for you, whatever? Or is everybody experienced the JSOC student and there is no problems here? Yeah, so I have one question that for the advanced will discard one feature added should be that the workspace of the multi branch pipeline should also be related with the bill discarded, right? So like I, you know, like, I, you know, just like, like, I'm just, you know, it's completely blank that for this implementation from where should I start for looking the code ways and all that. So like, can you just, you know, provide me some, some hints that, like, from where should I start to have a look on the implementation of this feature? So you ask about multi branch specifically, right? Yes, yes, yes, multi branch pipeline specifically. So probably we need to clarify some bits about the Jenkins architecture, because there are a lot of there are build storages, and there are workspaces, and these things are different. So when we talk about workspace, it's a directory provisioned on the agent, which gets managed by Jenkins and removed in some way. It's, for example, external. When we talk about the discovery, we mostly talk about the data being stored inside Jenkins. So there is Jenkins home directory, where it puts build data artifacts, and this is what has been discovered. This directory is not a workspace. It's a separate directory. Yes, there might be some interaction. For example, you might want to the provision allocated workspaces when you delete a build. But for example, current implementation and Jenkins doesn't do that, except a few exceptions. So when you invoke build discarded, you delete a build directory on Jenkins master and some other data which is connected by these scenarios. It's not a workspace. Okay, so I should use run listener to invoke the advanced build discarded for this multi branch pipeline, right? Yeah, likely. Okay. Okay, any other questions? Okay, if there is no other questions, I'll briefly talk what happens next in JSOC. We have two incoming dates, which are important for students. One date is March 22nd. It's the date when the application site opens. And another day it is April 9th, which is a deadline for application. So yeah, the recommendation that you keep in mind that these dates and actually it's recommended that you start preparing your project proposals in advance because it gives you more time to get reviewed by mentors. So if you submit your project ideas on April 8th, even if it's formally valid from JSOC standpoint, most likely you won't get an update back from mentors. So it's better to start early and my recommendation is to actually start preparing your proposal drafts as soon as possible. Because well, we have only five weeks left and at some point you realize that it's really only five weeks because the review cycles may take a while, it may take a while to explore particular comments and architecture details. So it's better to start early. Regarding the process, as we discussed, we have these meetings in order to talk about any questions you might have about the process or if time allows about the proposals and particular details. But we expect you to mostly work with your potential mentors. Each project has at least one potential mentor and many projects have several mentors up to six or seven, I believe, in some project ideas. Yeah, I'll probably just share my screen. Do you see it? Yes. Okay. Just close some tabs before we go into details. Okay, now we have less tabs. So yeah, for each project, if you go to the project ideas, if you like a project, you can just go there. Okay, let's take this one, for example, you might see that there are links on the right side. So there is a mailing list, there is chat and gitter, sometimes there are also meetings. This information has been generated from metadata and each project may have different links. So for example, here, we mostly use GSOC resources except in chat, we have created a new chat for Docker. But if you take another project, like configuration in scope, you may see that the links are different. So you may see that gitter points to configurations code plugin gitter channel, same for github, same for meetings. So yeah, the channels are different. And when you prepare your proposal, when you explore the area, we kindly recommend to use these channels. So if you have a question about configuration as code, you'd rather go to these channels and discuss questions with particular use mentors and other stakeholders. Because here you may see that there are actually many people not only your mentors and some of these people may provide you some advice about how to implement particular bit and it's also a part of the community. So you get introduced to more people, which is always helpful. Yeah. And in the next weeks, please work with your mentors. And if you need, for example, a meeting to discuss particular details of your proposal, please don't hesitate to ask your mentors. Well, it's not guaranteed that you will get a positive answer, but it's better to ask. So during this month, all potential mentors are expected to be present in channels and they expect to provide timely response. If it doesn't happen due to whatever reason, yeah, that's why we have this office hours. If you have any problem, you can just go join office hours meeting, for example, at this time slot or in the morning for IPEC region and you can ask people on the call to help or you can just come to the GSoc Gitter channel. I mean, Jenkins GSoc. And you can also ask them if you need some advice or if you get stuck with the project idea. In the worst case, if you just don't get feedback or if you have something sensitive to discuss, for example, let's say your mentor was rude with you or your mentor provided it back in a way you didn't appreciate, it happens sometimes in our organization, that we will be closely monitored with this situation. But if something like that happens, please let us know. If you go to the Google Summer of Code page, you may see that there are many listed. And below you can also see a link list for Oracle means. So this is the main escalation channel. If something goes really wrong in your project, you can use this channel to reach out to us and we will also try to help. What else you need to know about? I think actually that's it. You may want to explore your projects. If you have any particular proposal, keep in mind that all of these projects, they are project ideas. So it means that you, as a student, you're expected to explore this area to think what you want to work on personally and you can adjust your proposal. Many of these project ideas have a significant area inside the project ideas. They offer flexibility. So if you have some ideas, you can just discuss them with mentors, you can reflect them in your project idea and you can approach it as it is. So what we actually expect from you is that you come up with original ideas. If you come up with a project idea, you can go to the Google Summer of Code page to come up with original ideas, even if it's based on these project ideas. So any suggestion, any changes are welcome. If you, for example, doesn't want swagger here, want to work on something else, you can do that. If you want to work, right, particular plugin groovy in due to whatever reason, please feel free to propose that. Please feel free to justify that because it will request some justification, but generally it's possible. So yeah, you can propose what you want. And if the existing projects are not enough, you can also propose your own project idea. The students are eligible to do that, but yeah, if you want to do that, we kind of ask to start early because as ORCAD means, we will try to help you to find potential mentors for your project idea. But again, if you come up with a new project idea, for example, let's rewrite Jenkins in Go, let's say so. Yeah, it's a violent goal. It may be interesting for some people, but if you come up with this project idea on April 5th, most likely we will be unable to help you in terms of finding mentors. And in JSOC, it's important that it's not only about students, it's about teams. So as ORCAD means, as an organization, we will actually need to find, not to form mentors teams. And that's why we have so long selection period. I probably should show this link in JSOC timeline. So here you may see that once applications are submitted, there is almost one month before the project was announced. And yeah, be sure that this is just, this is a really tight schedule for JSOC organizations because they need to review all the applications, they need to form mentors teams, and then they need to apply for project slots and form a final project list. So that's why there is such big gap between the time when you apply and for the time you get the response. But please be patient during this time frame because you just won't be able to tell you what is actually accepted before May 6th. And we won't be able to tell you about OTS or whatever. But yeah, you can actually start working now and then we probably will get some insights what's going to happen. So obviously if you work with mentors for one month, if you have good communication, if you discuss project proposal, if you all agree with mentors, then yeah, of course you can be much more optimistic about your project proposal than if you apply a few days before the deadline. And yeah, that's one of the reasons why it makes sense to start early on the project. Okay, I tried to briefly summarize what's going to happen next regarding the meetings. Yes, we have two corny sessions. We will keep these sessions running before April 9th. Then we have one weekly meeting for GSOC status. It's mostly a mentor and work and meeting. Students still can join that. But yeah, ask that if you have questions about your projects, you would rather join corny sessions. And in addition to that, many projects will and mentors will be organizing their own projects. So if you're interested in their own meetings, so if you want to ask something specific for your project, you just go to the channel and ask for meeting. And then if mentors are available, they will try to organize that. If not, it may still happen in the Gitter channel and you can have a discussion there. Okay, that's it from me. Are there any questions? I see two participants have joined Oleg while you were talking, Deepanj and Ankit. I just wanted to know if they have questions. Hey, no, that's from my head. Hey, you can continue Deepanj. I was just saying that I... Yeah, yeah. It seems we have some race conditions. Yeah, it's a part of GSOC in general because yeah, all teams are distributed. So please be ready that there will be a lot of various cases with communications, including people losing connection, including background noises, whatever it is, just a part of GSOC. It always happens. Yeah, sometimes it's difficult when you have multiple people on the call. We'll be doing our best to improve experience. But GSOC is probably the first experience of distributed work for many people and not only for students, sometimes it's also a first experience of remote work for mentors as well. So yeah, please be patient if something goes wrong in terms of communication. And if your sound doesn't work, if you need any assistance, you can always duplicate your question in the chat. Hey, yeah, and that's true. Like I would like to remind production. I am mentoring this year from Jenkin's organization on two projects. One is polling docker registries for image changes and the other one is Jenkin's remote monitoring. So as you have already discussed everything regarding GSOC, I would like to add few lines. Like it would be great to be in touch with the mentors post-application like when you have submitted your proposal. And if you are still struggling to keep in touch with your mentors and you are very curious to find what is going to be happening like how this project can be more improved or can be implemented and get as much information as you can from the mentors that really helpful for you to be to have to be greater chances to get selected as a student. Like I done the same and I recently, I last year selected as a Google Summer of Code student from Drupal organization this year mentoring this organization. So thanks for selecting me as a mentor for these projects. And I would love to help each and every student who will be like who will need any help regarding any projects mentioned in my mentioned there like docker registries and the other is mentoring. I've experienced with Grafana and Prometheus and working as a DevOps engineer. So it would be great to help you guys and I'm open to any social media you can always connect me through Twitter, GitHub or through my mails as well as IRC. That's cool. Yeah, Jenkins project still uses IRC for some channels. We mostly, you moved to Gitter as JSOC organization but official channels of Jenkins are still in Gitter or sorry, in IRC. And thanks for introduction on KIT. Actually this year we have a lot of past students participating as mentors including past students of Jenkins organization. So yeah, if you have any questions please don't hesitate to reach out to him. And yeah, as we discussed before we also plan to have a special session where past students will talk about their own experience. So yeah, we'll do our best and please don't hesitate to ask for advice. Yeah. Excuse me, sir, am I audible now? Yes, yeah. Sir, I'm Deepanj, I'm currently contributing to the Open Source Organization Jenkins and the Role Strategy Plugin Project. Sir, I was wondering that many of the projects have the proposal we have to make needs to contain which major points. I need you to know that on the implementation part and the problem itself is proposed by the project idea only. So I needed to know what major points have to be covered in the proposal as I was planning to draft a proposal very soon from now on. Okay, let's take a look what we have. Okay, do you see my screen? Yes, sir. Okay, so, okay, let's take a look. We have project ideas which you can use as a foundation for this project ideas may be more or less defined. It depends on the project. But yeah, what happens next for each project idea that you start preparing your proposal. For that purpose, we have a guide for students. So probably you have already seen that information for students. So it provides some details how we see the SOC application in our organization. So we have set some expectations. We provide some guidelines. But actually, we don't say much about how proposal should look like. And yeah, it's probably something we should improve in this documentation and put some bits about how proposal should look like. But even that, it shouldn't stop you because for example, there is a Google guide Google's guide for students. And here you may see that there are some links. For example, okay, introduction. Why should I apply? Appliant and here there is a section about writing a proposal. So this document effectively describes what Google expects to see in the proposal. And I would say that the genesis of the requisition we are fully aligned with what is listed here. So our expectation is pretty much the same as what is listed here. Main section you should focus on is deliverables, is what you actually want to deliver in the project as a part of particular features. But deliverable is not only a feature. For example, auto tests or documentation is also a part of the project. And when you prepare your proposal, you should keep that in mind. So yeah, actually you may see it here, documentation, also test automation, whatever demos if you want to create them, it will be also a part of your deliverables. And benefits for the community when you explore the project, you should actually think what people would get from that. I believe that all project IDs somehow describe that. Yeah, for example, let's take a look at the role strategy. Yeah, okay. For example, role strategy performance, improve performance of one of the most popular authorization plugins in Jenkins. Well, yeah, probably qualifies as a benefit to the community. But yeah, obviously your model will come to expand it because yeah, there is some information available in Jenkins and you can start using that. And yeah, you're welcome to expand this section as far as you want. Then we really want to know what is actually what have you done before? I mean, if you conducted some research, if you conducted some contributions, if you see other people doing contributions and you can summarize what would it look like? And yeah, this is what you also like to see. Plus, of course, information and other things. What we appreciate in applications in addition to these sections. For example, JSOC, as we said, is about teams. So you can do JSOC on your own. You have mentors, you have other stakeholders. And first, it's really important to know what would be your availability during the application. For example, if you plan to have exams during the JSOC timeframe, it means community bonding or coding. So I mean, starting from here to here. So if you plan to go offline for one week or so, it's better to let us know in advance. So when you prepare your proposal, please keep it in mind and please put information there so that we can take it back out. And generally, if you want to have information about your commitment during the coding period, for example, if you have classes, yeah, it would be nice if you tell us about that. If you work full-time, well, definitely better to let us know about that. And yeah, in such cases, it's better to think twice whether you want to apply for JSOC. But yeah, it's better than that you say it in advance and then mentors and the worker means they take it account, check the ability and make a decision. But yeah, if you don't tell us about such things, then yeah, if it gets discovered during the project, it may mean immediate termination of the project because yeah, it may be like JSOC rules, it may relate our organizational approaches. So yeah, when you prepare application, please think about your commitments and list them. But yeah, again, commitments are not a blocker. So if you just plan to go for vacation with your family, yeah, it's something which may happen. Also, please let us know about that. It won't be a blocker, but your mentors will be able to think how to mitigate that. For example, starting coding a bit earlier so that you have more time or maybe just rebalancing the project. So there are less risky parts go to this vacation, et cetera. And yeah, many other things which you can take an account in the proposal. What else you should keep in mind? Yes, submit a draft early. So it's something which we already discussed. So if you just submit your final PDF, well, mentors usually prefer to have a chance to take a look at a proposal before and how we usually do it in our organization. You create a Google doc, you make it publicly visible, you make it publicly commentable and then you just submit it and the organization will take a look and hopefully you will get feedback. So we really ask mentors to keep track of such applications and to provide some reviews in advance. But yeah, again, it depends on the time. So if you submitted on the last day, you won't get a review most likely. I guess, yeah, that's generally it. So please take a look at this guideline because it contains a lot of information which we haven't touched. And in addition to that, well, yeah. I take a look at Jenkins guidelines because yeah, we have some specific practices. Well, I lost this page, I believe. But for example, Jenkins is an automation server. So as a part of our project, we expect that all activities you do, actually you finally have some automation. So we have Jenkins on Jenkins instance and if you're working a new plugin on a new component, of course, our expectation would be that you have some test automation and that you create this, or test automation as a part of your project. So yeah, please be ready to do it. And when you submit your proposals, most like mentors will tell you about that. If not, just keep it in mind. And there are other such things. Yeah, you can just take a look here. I believe we reviewed these guidelines, but yeah, if something is missing, please let us know. So yeah, we will be updating these guidelines on the flight. So any feedback you have, we just put it in the JSOC special interest group channel. And one of the means we'll take a look and probably update these guidelines or maybe create FAQs or whatever. So that we have more information offered to the students. Does it make sense? Any questions or maybe somebody would like to add something? Just wanted to add a couple of things, Oleg. Yeah, thanks for that. I'm sorry if I took a lot of time with my introduction. That's okay. I think it's important to say that we expect the students to follow the Google guidelines as well as the guidelines we have written. This is very important. No matter how good or bad the code is, the guidelines have to be followed. We also expect in the Jenkins organization that every student that reaches at the end of each coding period will do a presentation of their work using Google Slides. As well as give us a demo of the work they have done so far, which means students are to prepare three presentations during the program. During the coding periods, of course it's not happening right now, but better to mention it early. During the coding periods, we do expect daily or almost daily commits to GitHub, as well as daily or almost daily activity in the GitHub chat. We encourage all students when they're blocked with something, you work on it, but don't stay blocked for two weeks without telling anyone. As soon as you're blocked, say something and inform your mentors that you are blocked and ask for help. And lastly, my last comment is for mentors as well as for students. The Google program requires all communications to be in public. So if you've got technical questions, if you're asking for reviews, if you want to discuss implementation ideas, discuss the code, everything has to be done using the public channels. So when is it appropriate to use a private email or private channels? Like Oleg said, if there is a disagreement or a dispute between a mentor and a student, or if it's a matter of, if it's a personal matter, such as it can happen that you cannot work on GSOC because you are sick or you have a family emergency, then you can use a private channel to let your mentors know about this. So they're not concerned if you don't show up, they know that you are busy with some emergency. Okay, so that's what I wanted to clarify. Okay, thank you, Martin. Yeah, probably what we also need to say that for us, one of the most important parts of the GSOC project is actually community bonding. So when projects get announced, it happens on May 6th. What happens next? We actually start organizing some training sessions and the meetings between mentors and students. So we expect all teams to have regular meetings starting from community bonding so that you can prepare. We will try to introduce you to the community to potential stakeholders. So it won't be just you and a few mentors. We really expect you to be a part of the Jenkins community and we will help you to study, to study technical side, to study community side. So when the project gets announced, we understand that it will take some time for everybody to prepare. I mean, everybody has classes. Community bonding is definitely not a full-time activity for students or for mentors, but we will start organizing something during community bonding. And this is something I keep in mind because not all organizations have formal expectations for this phase, but we do have formal expectations for this phase. What else was said in that, yeah, if we talk about behavior, if we talk about various communications, Google Summer of Code has a code of conduct. It should be somewhere in this document, but yeah, just to summarize this code of conduct that, well, JSOC is supposed to be fun for mentors, for students. So yeah, please be positive. Please don't be offensive. Keep in mind that everybody is a contributor and you're investing his personal time. So yeah, please be ready that, yeah, sometimes not all communications go as you may expect. And same, but yeah, please be polite. Please respect all sides of the communications and of course, all kinds of harassment, et cetera. They will immediately lead to project termination. If it happens from the student side, if it happens from the mentor side, it will lead to the mentor change. Again, that's why we have ORCAL means and ORCAL means be able to help these topics. So there should be, yeah, there should be code of conduct somewhere in student guide or maybe if it's on the top level. Or maybe not. Yeah, I'll try to find this guide. On the Jenkins side, we also have code of conduct. So it's Jenkins IO slash conduct. Again, it's a pretty common code of conduct. It's not, so it's not enforcing anything specifically. But it actually just says that also be nice to other people. Yeah, so yeah, if you're interested, you can actually take a look at contributor component because it's one of the most popular code of conducts in open source communities. And if you work in other open source project, most likely you will also hit this code of conduct type. Okay, that's it. And yeah, again, please do not be afraid about that. It's not that we strictly follow all. Yeah, so yeah, it's just a method to prevent any potential issues if something goes wrong. But of course, we will do our best to resolve the conflicts if they haven't. Hope it's additional clarification. So mostly a question to students. We have 15 minutes left on this call. No, it was scheduled to 45 minutes. So effectively we're running out of time, but if somebody has any questions, please feel free to ask. And yeah, let's focus on questions about the project organization. Oh, Lager, I've reached out to the Google Summer of Code admins to see if they can point us to an actual code of conduct on their end. Okay, thank you. So probably it's something which needs to be clarified from the beginning. Many organizations have contributor license agreements and other such things. In the case of Jenkins project, at least now we don't have specific contributor agreements you will need to sign. Jenkins project does have a contributor agreements, but it applies to contributors with advanced permissions. For example, if you want to get access to YouTube, if you want to get merge permissions to the Jenkins core, or if you want to join a security team, then yes, of course, you will need to sign a contributor agreement. Jenkins, in terms of JSOC, we do not require that. And so far there is no projects which would strictly require any kind of additional agreement beyond what you sign when you apply to JSOC. The questions, no questions so far. So yeah, I think then we can just close down the meeting. If any questions appear after the call, we have JSOC Gitter channel. Please don't hesitate to ask anything there. And you will try to process these questions and maybe create some FAQs and whatever. Hey, sounds good. Okay. What about other mentors, Christian, Marky, and Keith, do you have anything to add? I personally do not have anything other than thinking the students as well as the mentors and the admins for all the great coordination. Yeah, I do, all the best. Yeah, I don't have much from my side. I'm just kind of trying to keep an eye on some of the projects that I'm working on. Some of the projects that I've closed that, so far there hasn't been interest in those yet. So, we'll see, there's plenty of time. Yeah, and again, just to repeat the discussion we had at the office house today. If you're a mentor, we ask you to reach out to potential audience, including students so that you can get more visibility of your projects. You can use Twitter, if you're interested to write about your project, about your plugin, about your subproject in Jenkins Block. It's something that you can also do. And if you're interested in going, for example, to university near your location, you can definitely do that. JSOC offers slide decks, et cetera, or Google Summer of course. We also have some slide decks for Jenkins specific. So, if you want to present a Google Summer of course to students, something which we really appreciate because even now not everybody knows about this program and we would like to promote it. Just again, promote JSOC, not specifically Jenkins JSOC because there are many projects and although we try to offer a diverse set of projects, Jenkins doesn't use all technologies in the world, what probably it does, but hopefully not. So, yeah, other, it's perfectly fine to advertise other organizations, other projects, provide other examples if you have such cases in the list. For example, Drupal, we have some plugins for Drupal in Jenkins. So, if you're interested to write something specific about this topic, just do that, why not? Or if you have a project idea, also do that. We will try to help with whatever initiative you might have, you might have. Okay. I think it sounds good. Yeah. So, thanks everybody for participating. Again, this call has been recorded. So, it will be available to all participants and I believe Martin has already posted a link in GitHub because currently we are limited to 10 participants in Hangouts on Air. We are working to changing our providers so that we can have more participants on the call. But yeah, due to some issues, we stick to Hangouts on Air nowadays. And if you join next week and you are unable to join because there are too many participants, just pink in the list, probably we will be able to rotate participants so that you are able to join and ask your question. Okay. Good. So, that's it. Thanks to everybody for participating on the call. Use all time you have before the deadlines to create proposals and have fun because this is one of the main objectives of J-Stock. And if we can help you somehow, just let us know. Okay. Yes, see you. I'll stop the broadcast and yeah, thanks again. Thanks Oleg.