 if I need to refer back to something. Okay, so yeah, I started the recording and yeah, it's just G sort of sales. We have four people on the call and right now we are planning to process agenda and lots of us from the previous meeting that by Mark and after that just switch to another organizational part. Okay, so next question was I should come in for long running projects, right? Right, so Google season of docs has two concepts, regular length and a long running project. The question was, are there any negatives for someone proposing a long running project? So long running project is basically, firstly it implies a more relaxed schedule. So it means sort of what's highlighted here like schedules easily, that's true. Harder to predict is it really depends on how planning is organized, how team operates because there is no practical difference in a short and intensive project and long and low intensive project. It really depends on how the teams operate. And for the next question, for the next bullet about could be more valuable. Yes, they could, but yeah, why they could be more valuable? Firstly, yeah, you may choose long running project and work much more on that than expected. So for long running project, yeah, you can deliver more in this case. Whether it's advised or not, basically it's your personal choice and it's definitely not expected that you take long running project and keep working 40 hours per week on that. At the same time, it may be more valuable because there is more opportunities to get feedback because you can submit something for review, you can submit something to the community. Sometimes review cycles are quite long as you may have experienced from your JSOT applications. Sorry about that, but what may happen in open source because the project is driven by volunteers, all our mentors are volunteers in this case. And it means that sometimes the responses might be delayed or for mentors, we don't expect it to be due to the active phase, but if you are outreach to the wider community, again, there might be delays. So long running project basically allows them to get that and it allows to do longer review cycles. If you want to do any kind of surveys, et cetera, it may be more convenient. If you talk about special risks, well, yep. Longer timeline, longer, there are more risks of various events like whatever, like COVID-19 confinement, version two, et cetera. So you need to keep it in mind. At the same time, long running project provides you more flexibility to react to these things. So yeah, I'm not sure how flexible is Google in terms of Google season of dogs deadlines for JSOC deadlines are fixed. I believe it's smallest of the same for JSOC, but if there is really emergency, et cetera, of course, Google is open to discuss options, especially in the case of JSOC when there is a lower number of mentors participating in the project. So there might be more opportunities, but so I provided some hints, but generally a long running project is neither advice to not discourage, it's just another option. And it's basically up to you to decide what would you prefer in terms of availability. In the case of the JINX project, maybe if you can accommodate both short term projects and long term projects. So it really depends on you. Great, all right, thank you. So then could a project proposal specify the alternatives? I want to do a regular or if allowed, I want to do long running as part of the project plan or should they, one of the questions was, how should they frame it if they think they've got a long running project or something that might be both, might be one or the other in their plan? So for JSOC application, we expect a plan and I believe that they have to explicitly specify whether it's a long running project or not in the application. I might be wrong about that, but if you have a preference, please mention it in your project schedule. Because for us, it may also require some adjustments on the terms of mentorship side, et cetera. Just for example, Christmas break and other things which may get into the equation. Just having information about the plan in advance would be preferable. But again, longer term or shorter term project doesn't make difference in terms of evaluation because the amount of time I expect to be spent from the project is approximately the same. Thank you. Now, how to deal with, how do we adapt to changing things we learned during the project, et cetera? Yep. In Google Season of Dogs, the approach is exactly similar to Google's Summer of Code. As long as your mentors are fine with the process, the organization is fine with the process. So it means that deviations may happen. In each case, even significant changes of the subject may happen. It's not something you would really want to do, but yeah, things may happen. For example, you apply to work on, let's say documentation migration, you provide a list of plugins. And we know that basically, there is continuous migration of plugins in the community. So it means that even you submit your proposal now, in August, let's say, we're accepted, but by the beginning of September, there might be contributors who address, let's say, half of your scope. It may happen and we expect the teams to adjust based on such scenarios. And it's not a problem. It happens everywhere. It happens in real work. It happens in open source. Everywhere, a change of plan is a part of the plan. Just make sure that you communicate with mentors and do joint decisions on that. Great. Okay, so what are the limitations of changes? So yeah, it might not change us. We should do not change deliverables. It's not a problem. If major deliverables change, then of course it's a subject for discussion with mentors. Great, excellent. Then the who-do-in form, I had assumed that we only have to do formal notification to Google if someone were actually abandoning their project. If they had been accepted and later said, I have a personal emergency, I simply cannot continue. But other than that, changes don't have to be notified to Google. We just go ahead and accept the flexibility ourselves. Yes and no. So yeah, just to clarify how you approach it in JSOC and how you approach it in JSOC, I believe. But yeah, again, all minor changes, they happen on the project teams. Still, we expect teams to identify your org admins in the case of significant changes. So let's say if you change order of the delivery, et cetera, it's totally on the project. But if you change the scope significantly, it's better to identify org admins so that they know about that. And if you have to change error significantly, so for example, you want to create Kubernetes documentation, then let's say Google calcels Kubernetes and you agree to work on docker documentation. So these changes likely need a discussion and likely need a sub to Google. Obviously I provided a case which is unlikely to happen, but just to provide you an idea. So such drastic scale changes, again, it's basically an organization decision, but we still prefer to notify Google team about that because again, if something goes wrong, we have to fail the project. This communication transparency may help both sides. So one that I may have made a mistake on on Google summer of code, if we're adding a mentor or a mentor changes, that should go to the org admins always, right? Yes, because org admins, I need to do updates on the website, et cetera. Good, okay. Sorry I didn't do that. Yeah. So yeah, it's a separate things, but yeah, so it's org admins, it's changes in the deliverables if needed. And for example, if there are long unavailability periods, so during Google season of dogs, you're also expected to take vacations, to take breaks, but let's say if you are going on a one week vacation is better to send heads up to org admins because we may need to do some communications and it's better that we know in advance that we are not worried about it. Great, excellent. Oh, one last question, I think I got the answer right, but the question was, can a technical writer act as a mentor if they were not accepted as a writer? So let's say we have someone who submits proposal and one of many, and we select only a few of those, and the others say, hey, I still want to be involved, could I switch and become a mentor? And my assumption was, if you know Jenkins and are willing to mentor, you could potentially be a mentor in this case. Right. So there is no limitation on that, as far as I can tell. Yep, also as we discussed at the previous documentation seek meeting, we consider doing additional community bridge projects for documentation in addition to Google seasonal docs. And in this case, they definitely get, they're wanting such limitation for sure. And it might be also an option for you to apply to community bridge instead of recommendation. And we had discussed community bridge actually in the Monday office hours. So that's great. I just, we took a tour of the site, I gave a brief overview. Excellent, thank you. Yeah. That covered all the questions that there were on the meeting from last Monday. Thank you. Okay. So yeah, regarding the rest, July 9th is a deadline for applications, or July 8th. But yeah, so we have a bit less than one week. So I can be asked mentors, et cetera, to focus on reviewing the proposals. Spend some time scrubbing there, and thanks to Mark for doing the review. So almost every proposal by now. And yep, we basically encourage contributors to review proposals and also to do peer reviews, if you're interested in the project, et cetera. And yeah, I hope that you will be able to process all this list. Again, if you don't receive feedback, please don't hesitate to ping participants because sometimes we don't provide the feedback because the proposal looks good. So yeah, there would be some minor things to discuss, but overall we have enough information to run to this proposal. Sometimes we don't provide feedback because basically we adjust the overload with other stuff. So if you don't receive it, yep. Continue, excuse my interrupting. Yeah, if you don't receive feedback, just please ping us. Yeah, so as far as I can tell, I have reviewed all the proposals that I've detected. That means if someone was expecting my review and got no comments, I missed their proposal. And so I would at least personally would be very grateful if someone says, hey, Mark, you said you'd reviewed everyone. You made no comments on mine. I made a comment on some minor thing at least on everyone that I reviewed. So if there's a proposal that I've missed reviewing, please ping me in the Docs channel, send me email, the getter, yeah, on the Docs mailing list. Any one of those is great. Okay, that's perfectly fine with me. And if I don't provide feedback, just ping me. Because there was out for a while, but I'm catching up with all of my inbox. I just have 2,400 emails, that's a matter of life. That's a matter of life. Yeah. Okay, so I guess that's it for today, unless there are any other questions. So I will do this meeting next week as well. But yeah, lessons learned that this slot is not suitable for tech writers. So if we organize meetings after the acceptance of projects, it will be a different time slot. Right. They really need to work, how to organize it. Yeah, I was amazed that we had people in the Monday afternoon, my time call from West Africa. So they were calling in at 10 p.m. their time and it seemed to work better for them. So yeah, that's okay. Yeah, if you're employed professional, somewhere, probably this time is not ideal. Maybe for Asian Pacific region, but for Asian Pacific region at the same time, yeah, there is not so many applicants for JSOD according to last year's statistics. But whatever. All right, thanks Oleg. Yeah, thank you too. And yeah, I'll publish the recording tonight.