 Today is a regular GSOC special interest group meeting, today is May 29th, so it means that the first coding period has officially started and as we discussed before, we actually expect all students to start coding and start delivering on their projects and yeah, this is the main objective for the next four weeks. If I recall correctly, the coding period ends on June 24th, so June 24th is the first date where we will have evaluations and by this time we expect students to complete most of the plant work for the first phase and after June 24th, I'm not sure what would be the exact date, there may be June 26th. We will have online meet-up in order to present the projects and to talk about their progress, so basically there must be contact with the students. The format is yet to be decided, we will start the discussion as soon as possible, but yeah, I believe that it will be just two meetings because yeah, we have students who almost operate on our mornings in the European term zone and some students operate on evenings, so I believe that we will have two sessions for the GSOC meet-up so that we split the presentations and get everything delivered, so as usual it will be due for the sessions. Regarding the rest, we expect all students to finalize community-borne infection items because we see that not everything was completed in all projects, so if you haven't completed your checklist for community-borneing, please do it as soon as possible and if you need any help from or from mentors, please let us know as soon as possible. For example, knowledge transfers, if you let any information about the code or just assistance to create your GitHub repository, create teams on GitHub and all other such administrative things, if you still need something, please let us know. Okay, basically, that's what I wanted to talk about. If we have any questions, we can just discuss them or maybe other work that means we would like to add something. Hi, Oleg. Actually, I want to talk about my design document. My design document isn't totally complete, but I have streamlined the major classes and major functions that I am going to define throughout my project, but I think rather than like planning everything on the go, like maybe while implementing, I'll add stuff that that would be easier for me to do. Yeah, so is that okay? Yeah, it's okay. So just clarify purpose of design documents. Design documents is not something completed in stone. We don't need specification for your projects or whatever. The whole purpose of design documents that you know what to implement, you know, order and that you spend some time on a reality map with mentors. So as long as you have a clear plan what to do in the first coding phase and what you expected to deliver, I think it's fine. So we don't need the design docs just for design docs. Okay. So by the end of releasing the plugin, that design document would like have a mini guide sort of thing and all the necessary ideas that future users and authors would require to expand or use the plugin. Yeah, so what usually happens with design doc contents, some of them go to introductory blog posts to project description pages on Jenkins Ion. Some documentation goes to read myths and developer documents within your plugin repositories. So once JSOC project competes, basically, we don't belong to use these design documents. So yeah, you can you're welcome to just move all your design document, for example, to develop a documentation or whatever in your repository. And that's it. If it's comfortable with you, why not? Okay. Anything else? Okay, I'll probably share my screen so that we can take a look at the board. Do you see it? Okay, so let's go to Jenkins Jira. Okay, this another board. Yeah, it will somewhere off code to 790. So here we see a pretty long backlog. But yeah, what we should be seeing now? Yeah, we have just put increase and a number of tasks. And here we can easily see what is the statuses in projects. So some projects have tasks created. Some projects are not, for example, for plugin management to incorporate even no tasks or they haven't been built properly. Let's take a look at the way. Okay, so yeah, there is no tasks inside. So yeah, if your mentors, please work with the students so that you have this list of tasks, because as often means we need this information in order to track progress. So as long as everything is fine, we won't need this information. But once everything goes not fine, for example, you have issues in the project, we need to make a decision whether the project passes a revision or not, then all this information will be used. And it's in your interest to have this information on board so that you have sorry, am I slow? I can hear you. Yes. Do you hear me now? So yeah, what happened that my headphones ran out of charge and then everything goes south? Okay. So yeah, if you're a student, it's in your own interest to have a dashboard in place and to have all references to go to work in place because you needed us or admins and as mentors to do the first coding offensive variation. So yeah, this one is a multi branch pipeline support. I believe it's just a mess because he created some stories. I will make sure that they're closed. But yeah, for projects where there is no tickets, please make sure to create once. So these ones are probably not categorized well, because I believe that maybe at least some stories here. Yeah, they're just not even able to correct him. So I will check what's going on there. So yeah, this is the board. What are the information we have in mind? Again, you can refer to Jenkins. Some of our expectation is actually listed here. So we expected that students are working all the time, starting from very first day. If it's not a case, again, if it wasn't this close to your community, it's like us know as soon as possible. If this contact your mentors, and we expect you to actually start pushing code often, we want to expect you to interact with the community to have regular syncopes with your mentors due to the coding phase. Depending on the approach, you either have your own repositories and maybe have a small pull request there, or you contribute to existing plugins like it happens in same projects. But again, the best practice is to deliver often and to have smaller pull requests so that you don't have one mega pull request at the end of the coding phase, which now no mentors can properly review. What else do we have here? Basically, that's it. So yeah, if you need a break, you take a break, you communicate with mentors and be online in your time zone. So yeah, our assumption that you work full time or almost full time on the project. The availability times have been discussed during project meetings. And we basically expect you that you somehow stay online. So for example, if somebody asks you in the chat, and if you do not reply for three days, it's something which will be a concern for working means unless it's a holiday or weekend. So during common working days, we expect you to be more online. Any questions? Do I still have issues with my audio? It goes in and out your audio. I do have a question actually, Oleg. Yeah. Yeah, because if that is my audio just interrupt me because it's but that you interrupt me that you don't get information. Okay. Yeah. So my question is, as I was trying to review project status, even for my project, I find that the discussions are scattered over get their mailing list, GitHub issues and JIRA issues sometimes. Yeah. Personally, as a mentor, and as an organ man, I prefer to see the discussions taking place in the mailing list, because it's easier to go back and find information and find project status. Yeah. So what would be your proposal? To use the mailing list as much as possible and minimize the Gitter Chat? Well, yeah, it's hard. Yeah. So what I would say that you have four common discussions like projects, etc. Yeah, let's use mailing list as much as possible. And I don't think that we are doing a good job about that. So yeah, we should ensure that we communicate plans, etc. in this public meeting. So yeah, this is something we should do. But for projects themselves, for coding, yeah, to be honest, I don't think that we should get one because we have JIRA issues. They have been created for purpose. So it's fine to discuss changes there. Pretty much with the same pull requests, pull requests are designed for reviews. So it's better to do reviews and pull requests, not mailing list. And Gitter Chat, since the student and mentors are more or less online, it's also fine to use it. So yeah, mailing list is rather when you need to bring up some messaging, this would be my approach. What do you think? Mentors, students, what's your preference? I'm sorry, my audio is cutting in and out. Can you repeat the question? What do you think about communications? My preference is for really short communications, the Gitter channel is fine. For anything that would require, you know, like a student asking a question in their expecting a detailed answer, I would prefer the mailing list because that way we keep a track of it. Sometimes a lot of conversation can get lost in the Gitter channel, and it's not adequately tracked. So I think for very short questions or things like that, it's okay. I think updates and things like that should be in the mailing list. But that's just my preference. Okay. So what we really need to have is meeting minutes. But when you have meetings, please put down the information to meet in minutes. But regarding communication, maybe it's just up to each project to define the communication way. What is our expectation as our community so that we should be able to intervene if it's needed. So for example, if something goes wrong in the project, that we should be able to understand the context, we should be able to understand what's going on there and what's not going on there. So for me, Gitter is good enough. Yeah, Martin and Jeff, you're right. If we use the meeting, maybe it's small, it would be helpful. But yeah, for runtime communications, just that. So yeah, I participated in JSOC three years before and each year we were not really using mailing list for communications for the coding period, except the developer mailing list questions. If other projects are fine, want to have use more mailing list? Why not? That sounds good. Yeah, so mailing list is not requirement. If you agree with that requirement that there is transparency in the project. So that by using communication channels on project pages or per means and other contributors can understand what's going on in the project. Okay. Yeah, that works for me. Okay, I'll put it down. Sorry for my audio today, but yeah. Yeah. And yeah, I think that what we really need to consider on our side is what that means to do more communications by mailing list. Because this year, mostly because of lack of time, we were doing many communications using recorded meetings. Yeah, although video blocks is a format of communication thing, probably it's not ideal. So what's the expectations for first evaluation? So as a part of your application as a part of community bonding and design work, you defined a number of stories to be completed together with mentors. So our expectation for the first evaluation that first all community bonding tasks are completed. But you will hope that everything is completed now. And then there is a significant part of tasks delivered. So yeah, life happens. Sometimes the project may go in another direction. But our expectation that stories are delivered, a significant part of them. And mentors are fine with what was delivered. So yeah, let's say you have 10 tasks in Jira, you deliver the five and mentors are fine with it, then yeah, evaluation bias to be a fine with it. If you have five tasks completed and mentors are not fine, then we start the beginning. So yeah, something like that. Does it make sense? So it's really between the student and their mentors. That's the agreement that needs to take place for what is expected of each phase of the project. Exactly. So you work with your mentors, you decide what's going to be the goal for the phase one. And it's the mentors are responsible for setting the for setting the expectations with the student. Yeah. So basically, all of you, the steps between students and mentors, or that means, I hear to help you if something is needed. But all the real work happens between the student and his mentors or mentors. And obviously, if you have some communication issues, something is not clear, these mentors, if it doesn't help, if you still experience issues, is that what that means? No, or that means can help when something goes wrong. And this is our job. But as long as everything goes well, we won't intervene in projects. That's for sure. Okay. Anything else to discuss today? I guess not. Are you there? Any questions? Actually, I couldn't hear for the last two minutes. That's okay. Okay. Are you there? You heard me? What is this about the zoom video? Yes, so we are considering switching to zoom for online meetups and maybe for meetings, because yeah, these meetings have a limit of number of participants. So no more than 10. And for some discussions, we have issues with that. So for example, when we were doing cross threads, GTS, when we were doing meetings and sometimes office hours, it wasn't enough to have 10 people. And using zoom is one of the ways to solve that. So yeah, maybe we will be just moving to another platform for recording meetings. And yeah, one of another reasons that if you're in China, using Google Hangouts, you may have issues with it. So it's also one of the points why we consider the zoom. Yeah, okay, thanks. Yeah. So for you, they change much. So we have zoom is rather for recorded meetings for meetings between mentors and students just use whatever you want. So with something up to you guys to decide, but usually it's fine to use Hangouts. The problem that if you want to report, record Hangouts, you need help from somebody from Orca means, all gsoft or card means are eligible to get permissions to run recordings from the Jenkins account. So Martin already has these permissions. I'm not sure about you, Jeff and Marke. Probably it makes sense for you to request these permissions. But yeah, we can run a recorded meetings. This zoom, you can just record the meeting on your own if you want using or actually this any other tool. And then if you need help with putting it on Jenkins official YouTube, if you know needed it to whatever reason, you let us know and we can upload it for you. And if you just have a private meeting cookie, put it where you want. Yeah, what I what I did is I'm just using my own zoom account, and then I'm uploading the video to the cloud. And then I just post a link in our channel. In our in our JSOC channel. Yeah, but if you guys do a kind of demo, and if you want to have a broader audience posting it in Jenkins channel might make sense. And if you want assistance to get this uploaded or recorded, let us know. Okay, I think I have access to that. But before I venture on my own to do that, oh, like I'll work with you to make sure I'm doing it the right way. Okay. Well, for regular meetings, just use what you want. Got it. Thank you very much. Okay. So my audio is still bad, right? So yeah, there is, there is a question from Jeff Pierce in the chat is that there is requirement to record regular meetings? No, there is no such requirement. We ask you to have a meeting notes. But we don't ask you to have recorded videos. For example, what we did in the strategy project, we actually do only one video meeting a week. But the second meeting, we do it in chat. And it's also fine. Anything else? It's all for me. It's all for me as well. Okay. Thank you all. And yeah, I think see you next week or when we have our next end cup. So yeah, yeah, thanks a lot. And yeah, if you see any missing items, if you see something that we need to deliver on as of that mean, please let us know. So that we follow up on that. Awesome. Thank you, all. Thank you, everybody. Have a good rest of the day or evening. Thank you. Bye. Thank you.