 So this is now being recorded. This is Google's season of docs office hours the 14th of September. Thanks for joining us. And you should right now see a mostly dark screen that now has a copy of the doc on it. And you're all welcome to edit in the document at the same time that I'm editing. I just put it on the screen so we can see it. Got it. All right. So items I had put on the agenda pull request status knowledge sharing sessions cluster access are there other things that need to go on the agenda. I sent a mail about my participation. I didn't get the response from anyone. So I wanted to discuss it here. Excellent. Let's do that. Sorry for being tardy meeting ran over. That's great. Hope you're feeling better. Yes. Yes. Excellent. So, let's see. So we've got, we added Oleg's availability as a topic knowledge sharing sessions. We've got the Dakota session schedule with Markey cluster access. I've got a topic to report any other topics we should add to the agenda. So probably implementation status next steps of just to have a regular lesson couple of what's going on and what needs to be done. So, and so we should probably put, yeah, this implementation status is a good place to put a review of the outline content. Good. Anything else. Oh, we did have one on the pull request. It was doc structure or not doc structure. It was project structure PR. Shall we all slash. Stay with what we have because I think that was one of the comments you provided in the pull request Oleg. So pull requests. Shall we take that one first then let's get started. So, Zina, you want to take the lead there. Let's see, we can talk to pull requests here. Yeah, this one. Okay. Hi, everyone. So, um, I think two, two meetings ago or so, I and Markey and Mark rather had a discussion about GSOD project page. So, um, I raised the concern that the current directory where the GSOD project page is is not really easy to navigate to unlike that of she saw. So on Jenkins dot IO, if you go to Jenkins dot IO, so under sub project. So, yeah, so under sub project, we have Google some of code, but um, GSOD, I think is somewhere on the documentation. So I think. Right. So it's two or three levels deep. Exactly. Yeah, exactly. So that was why we had the suggestion of creating GSOD also under sub project, just as Jesus and copy and move the context rather. So, um, the idea was to redirect. So I have corrected the pull request. Why I didn't remove the content from the previous directory was because I know. GSOD project page on Google season of dog sites is carrying the link to the previous directory. So if I remove it completely, it means Jenkins Project League will be broken on GSOD sites. So that was why I didn't remove it totally for the previous directory, but I'm all like mentioning some things on the pull request. So I'm guessing probably we might not go out on with that anymore. I don't know. There are multiple comments and requesting changes mostly because there is a complete content application. Instead of that, there should be redirects and they change history should be preserved. This is why I request a change. If we do this modification, the same time I question the feasibility of modification on its own. It's even if it removes one level for navigation. I do not see clear benefits of moving and at the same time, yeah, this, the current structure is what we agreed is other GSOD means in May, when we were preparing to application, etc. And moving content now is, well, it's a bit complicated. It's possible, but for me, I just don't understand what is the need to move it. So like if we were to, is there a way we could make this page that's visible on my screen now directly accessible from either the community menu or the sub projects menu, so that instead of doing three levels, you know, three clicks of navigation to find it. We could get there from a single, a single pick from the top level menus. Yes, you can. So what we were discussing for a while is actually the working destruction so replacing sub projects, CX, etc. by, let's say, working groups, where we would have everything aggregated and where we would have only active projects or six or working groups. After that, it would be addressed by design. So right now, the structure of navigation bars, at least for me, is temporary. Assuming that I ever find the time to rework that I would rework that. And that's why when we discussed getting additional sub projects recently, I voted against that. And yeah, for this purpose. Yeah, I don't point to adding a sub project to there. But yeah, at the same time, I'm not sure what they just fight, but we could do that. So, so just thinking towards a simple if a sub project were added to this list, Google season of docs right below Google summer of code or right above it. That would fit your that would address your concerns. It would address my concerns that I want this page reachable from without having to navigate three, three pages to get to it. Yep, you can add to this menu bar. Okay, this menu bar is auto generated if I recall correctly, but similarly to overview link. You can add additional link to the bottom of the list. All right. Zina would that would that be acceptable to you if we just took the idea of let's put one entry in this sub projects drop down menu that links to this exact page and not change the location of the page at all. I'm sorry I didn't I didn't get that. My apologies my internet is, is imperfect at best Oleg would you like to describe it so that we don't have to put up with my poor internet. Okay, so what Park suggests that instead of moving pages. We just did a link directly to your project in the sub projects list. Okay. Okay. Okay, that's fine. I mean, that would also match the routes being done for summer code, which makes sense to me. Well, there is some difference because Google summer code has been created a while ago and it's basically continuous project. At the same time, yeah, one of the concerns about working groups continuous projects was that half of these projects are not really active. So for example, evergreen is not active for a jinx remote and it might be a project, but there is no really community events around it ever. And yeah, the idea was to actually start merging the things. But it hasn't happened yet. So for now it's the plan to do eventually. So, yeah, if you just want to put it there we can do that. It's just not the final state. And I think that final state of this navigation but just change. Sure. So, Zina, forgive my poor internet was that a better explanation for you did was that comfortable. Yes, yes it was. And are you okay with that as the idea then is one entry added to some projects here that go navigates to this page. Should it navigate. I see. Okay. Because that way it's a link to the current project, not to the general concept of. Okay, so that would mean here would be called document or Jenkins on Kubernetes. Oh, yes. Okay, let me see if I can capture that. Alright, so something like that. Is that workable for using up and like does that meet the meet the idea you've got as a short term, so that we don't do things big that we later long term after undo anyway. Yeah, that's fine. Okay. Should we go on to the blog post then. Let's take a look at it. Okay, so this is the draft right Zina. Yes, it is. Okay, so we're going to do feedback. Good. Okay. Then next stop is a pull request to the Jenkins site. I also, or is there. Next step. Or is there something else. Have you created a profile for yourself on the Jenkins.io site. Yes, I have. Yes. I think I did that when I was creating the project page. It exists. Okay, any, any other discussion needed on the blog post. So Zina, you've got the next step to do the poor, basically process the review comments since Google Docs are the easy way to do that. And then you can convert it to ASCII Doc and the pull request. All right, Oleg availability and participation. Let's see. And I should be able to bring up the email. Well, I can quickly summarize one while you're looking for that. So, yeah, the team selected meetings at 5pm UTC. And yeah, these meetings are not really possible for me on a regular basis. So that's why I think up what would be the best way to be involved. Well, just to seek alternate time to some housing couple is a net. Or just doing anything consider honestly, or maybe just stepping down to avoid confusion on these connects. And I wanted to get feedback from the team. What would be your preference and expectation on that. Yeah, for me, I myself available. So right. I was saying, for me, I can make myself available for whatever time works best for Zina and Oleg. Yeah, so the thing that current time definitely works best for everyone except me. For me, basically the time which would work is either morning, my time zone. Or sometime in the evening. But in the evening, if you want to have a marky mark recently on the call, it starts colliding with our work meetings. And basically it almost guarantees that it will be a continuous mess with people being unable to join. So, in principle, the current time should be much better than anything we would choose. But yeah, that's the problem. So I don't ask to move the current meetings. Yeah, I want to find a way to participate. If we can find a way or maybe just to step down so that I'm not an obstacle. I will still remain a stakeholder putting up here and there. But at least you won't need to wait me for formal processes. Yeah, so I would like to understand a little bit the difference you see between item one and item two. So it's the difference. I think we could get your inputs in either case couldn't we. But in one, you stay as an official mentor and would join the meetings once every two weeks or so. So the problem that being an official mentor and joining one meetings of four doesn't seem to be workable for me. Because it will naturally lead to misconnects. So for me, it's finding another way to communicate asynchronously somehow. Plus meetings. And still, I think there is a high risk of misconnects. Right. For example, I may say one thing, you're the meeting discuss other things. I don't read meeting notes or we miss something. And then it may lead to confusion. For me, I would rather have a preference of the entire team participating in meetings on a regular basis. So that's great. Which which for me lobbies that the second option you offered is probably the least likely to introduce miscommunication, while still retaining your expertise as an org admin. My concern is if we don't have your expertise as an org man admin, we will make mistakes that we could have avoided with your skills there. There are not that much to be done for J sort. So we need to handle different payments issues. And after a bit just ensure that the relations are submitted in time. So that being conducted mean would be a massive burden for anyone. I can step back into the org admin role. If that works for everybody. And that would certainly work for me that would be just great. Anyway, we'll still remain somewhere around the project. So for admin, the most challenging part is actually ensuring payments to come somehow through Linux foundation. And yeah, basically there are two answers. Firstly, we're talking about something like $500. So we can say that we will spend more time than it actually works to get this payment through. Or we just try to get this money in principle because we can invest them in a few of the community events. But yeah, this is the only challenging part. And so, so that organization payment that you're describing is to the Linux foundation because we are because the Jenkins project is a sponsoring organization. That's not the payment that's made to Xenov as the writer. So, yeah, payments to Xenov are being done by Google. Our effort as an organization is not required there. So, got it. Okay, so this is just the work steepness. Yeah, so this is this is the limit. This is Google offering a stipend to the Jenkins project for being willing to be a mentoring organization for Google summer season of docs. Got it. Thank you. I have knowledge of doing this from Kubernetes community so again, if you need me, I can step in. And also just from being an org admin for a summer code for Jenkins. This means that I have now gone through all three scenarios as preferred. I initially started thinking that the first one was preferred listening to Oleg's description. The second one became more and now I'm thinking, oh, like, I think having saying hey, you don't have to be involved at all, but you are welcome to. Maybe the healthiest thing for us to do here. I will be involved still mark, you know, my current situation at work. So, yeah, it's hard to commit on anything. But yeah, I think that for administration, basically, I have no preference. If you want to handle that, of course, it's a relief for me because I still have to handle. But yeah, again, it's not a huge deal on the song. So I don't feel strongly about that and if anyone wants to take the local mineral, I'm fine. Okay, I go ahead, Marty, sorry. I'm sorry I interrupted you mark I just said I'll definitely step up to do it. Okay. So then I suggest we press it with option three. I will be still available synchronously if needed. I will be happy to provide any expertise. So we have a technical advisor term. So you're welcome to apply it there as well. But yeah, just the expectation, I won't be able to be joining meetings unless it's strictly required. Okay, so like, act as technical advisor, and marquee becomes an org admin and continue as a mentor. Oh, like, can you just send me the invite the Google invite to the console for the org admin. Well, it's a bit more challenging. There is no, no console for Jesus. But yeah, I'll do the transfer. Okay, thank you very much. Great. Excellent. But anything else on that topic. Not for me. Okay, onward to the knowledge sharing sessions topic then. So we identified a need for at least two knowledge sharing sessions, one for Kata Kota and one for helm. So we got a Kota session. I said a Google or a doodle.com poll, and we got agreement that 5pm UTC this Thursday was a workable time for marquee and for a Zenab. So it's scheduled is that still workable for you marquee. Is it still workable for using up. It is still for me. I do either of you object if we record it. I do not object. Great. Thank you. Okay. I am intentionally not making it a community invitation thing, because I assume the people who own Kata Kota might say hey we'd like to be presenting it if, if it's going to be published and invite hundreds of people to it, etc. So, but recording it for reference seems like a reasonable thing and if we decide we want to share it we can afterwards. The next story is not as happy. Torsten Walter is on vacation right now he's out of the office. He will return the 28th of September. My attempt to find a time that would work the 28th of September failed. I was wondering if you, I don't have to attend this helm session. I was wondering if you would be willing to take the responsibility to create the doodle poll in you on your schedule to find a time that fits with Torsten schedule. Okay, I'll do that. Great. Excellent. Okay, then that covers knowledge sharing. Are there other knowledge sharing sessions that we need that we have not put on the list. Okay, for the helm knowledge sharing if, if we can't agree to find a time for it for Zenop, Zenop, let me know, and I will gladly do some session with you that we can record. Thank you. Great. Thanks. Okay. Anything else on knowledge sharing. Okay, cluster access next topic. I haven't yet found a donor to contribute cluster access to it. Tim Jacob asked a question about, could we just host it in the Jenkins Infra as a separate cluster. And I need to discuss that further I don't understand the security implications of that. So that's my action item discuss in infra team meeting tomorrow. I'm still not clear for what exactly do we need the cluster. Because, yeah, last time I participated two weeks ago, we discussed that we make you piece of basically enough to get started. And, yeah, just scroll through the discussion notes I didn't notice that it changed. I thought, for instance, that that topics like these were likely to require a an account on one of those one or more of those clusters. So that was just the assumption it's not blocking Zenop's work. As far as we can tell she hasn't hasn't expressed any concern that she has to have it immediately. I've just been doing the exploration to try to be sure we've got it eventually. I think initially the initial work can be done locally so she could use mini cube or K3S or a kind cluster. And then if there is additional cluster access needed for GCP and AWS, I can donate for that. I would not like to host this in the Jenkins Infra, just because cost and security, I think it would be easier to not have to worry about that. A good point. Okay, thanks. I think that answers it then. I think we've got the solution for this. That's great. Thank you. I'm updating the Google Summer of Docs doc page. Mark's action. I'm not sure what I missed on that one. It's me. So when we had the first meeting for the project, we just cast the next steps. And yeah, I was just looking at the J-Sort page. And J-Sort page still refers to Jenkins as a project participating in J-Sort with a list of project ideas, etc. And I believe we agreed that we need to market this data to archive it as we do for J-Sort so that we have a clean page. Got it. Okay. And also just doing some housekeeping to highlight the status, etc. Okay, yeah. So that was one. And when Zina and I had discussed in the recent meeting, I thought, okay, see if she could take that on. But it may be better for me to take it so that she can focus on the Kubernetes project specifically. I like that. Yeah. So, let me see. Meeting notes. Mark, that you would be working on that, but I might be wrong. And that's, I think that's a very reasonable approach. Great. Anything else on the Google Scenes of Docs page? Okay. Next step and implementation status and next steps. So I think this is a place, Zenab, for us to start from yours and share with us where you're at, etc. Zenab, did we lose you? Oh, sorry. I didn't know I was muted. Sorry. So, I said, I want to create the Jenkins on Kubernetes volume on Jenkins.io. So if you can please navigate to Jenkins.io. I have a couple of questions. Okay. So this, is this the page that you were meeting? Yes. So on that documentation. I'm not sure I'm hearing you, Zina. Could you say that again? Yeah, I said on that documentation at the top documentation, on that documentation section at the top. Documentation section. Oh, beside plugins, communities or projects. Yeah. Okay. So I assume this is where we're going to be adding Jenkins on Kubernetes, right? So I wanted to be sure what the new structure where exactly Jenkins on Kubernetes is going to be. Like what range meant. So one thing to mention that this structure on the menu bar doesn't fully represent the actual structure of documentation. So Mark, if you go to any page linked here. Yeah. So the actual structure is available on the left. So basically user handbook. And if you go up, you can also find the sections. So the structure is actually here. Yeah. Yeah, we had some discussions about how to update this structure as a part of the documentation revamp. But right now it basically has two main sections. One is user, user focus sections. And the other part is administrator focus sections. But you may see that they are basically ordered in less than expected way. So for example, installing Jenkins is an administrator section, then using Jenkins by plan lotion and managing Jenkins again administrator section. So what we were discussing at one of the first meetings that have two parts. Jenkins and Kubernetes for users and for administrators. I'm not sure whether he's still a plant for the team. But yeah, one of the ways would be to actually just have two sections. Oh, just this Jenkins and Kubernetes as a single entry. Yes. So for me that so the, the, the using Jenkins talks about details inside Jenkins installing feels like an unexpected location to find details about Kubernetes and yet possibly viable. I was assuming at the same level of system administration there would be a heading here on the left. I would say Kubernetes and that it would have all the Kubernetes related things in it, but like I think I see your point that may not be the best structure for, for the consumer for a reader. Well, my suggestion would be to actually start from something because should we decide to organize the content later we can do that. For example, now if the decision is to just have a separate single section for Kubernetes, we can do that. The worst case will redirects after that. When we do, when we recognize the content. Okay. But yeah, for now, if you do not prefer to have a single entry, let's do that. If you want to somehow merge Kubernetes content into existing sections again is doable. And this is one way of thinking about marquee you've probably got the most experience in terms of install. If Kubernetes were not if helm related information for instance we're not in the installing Jenkins section, but rather we're in a dead in the Kubernetes section. Would that be confusing to you or helpful. I'm not sure which is better for someone who is Kubernetes experienced. I think in this section of installing Jenkins, it should break out into multiple other sections. For example, there would be a helm in install section there would be. You may use Terraform to do something you may use just, you know, native. So you're, you're suggesting it would be clear to have the information in the installing section, rather than in a separate dedicated section for Kubernetes okay. That's just that's mine. I, I definitely want Z not to drive what she thinks and then we can go that route but if I were to do this I would say installing Jenkins would have subsections installing with helm installing with, you know, GCP or installing AKS or something like that. Okay. Oh, like, does that, does that still fit within within the ideas you were working from. Yes, it does. So for me the main objective is to have content. If we have it, we can still move it. If later we change our mind. So for now, I'm basically finding this any approach. Okay. So then Z knob I think it's back to you if there were a section here. I think you were proposing add a section, add a row to this menu that is Kubernetes, and it would jump to a place here. Yes. That was what I was thinking. Well, I think I, I understand what my kid was talking about about adding a section on helm to installing Jenkins. So I think what I'm going to do is they'll probably be a section they'll still be a section dedicated for Jenkins on Kubernetes is but for topics that we have that properly fit into existing sections, we'll see how we can match them. Then for those that will fit, they'll be under the Kubernetes section. Okay. So let me capture that. I like that. So Kubernetes section. Link from the document the documentation. Yes, the documentation. Insert, okay to insert content existing sections like install. Okay. Did I capture that accurately. Yes. So there will be in that means there will be a new Kubernetes section at the same level as system administration and installing will be visible in the contents list and in the menu drop down. Good. Okay. Additional topics that you want to discuss there. See now. About sorry. There's something I want to mention about the knowledge sharing session sorry to take us back. I'm since my key suggested that he's willing to take me on the session of on helm. If Austin is not available, I don't know if it's possible for us to schedule that before the 28th since helm is one of the topics that I'll be covering in the beginning of documentation. So I'm not sure if it would be if you don't cause delays if we wait until 28th to have a session and help. The question is okay with market. That is totally fine with me. I can give you a session and we can figure out a time that works best for you. We can do it this week. Next week, whichever works. This week is fine. So, okay, I will up ping you. What are you available. What is your availability on Friday. Okay, yeah, definitely ping me if you want just in the docs channel. Yes, I will. Excellent. Thank you. We've talked about rough top level top level structure. Are there any things you wanted to discuss, you know, with regard to more detailed structures we talked last time. No, not yet. Hello, I think the, I'm fine for now. I'll just go through what we have the current con proposed content and see how it can fit into either existing structure or the new Kubernetes structure. Do we want to do a review of your, your ideas and comments in our next session. Yes, Thursday, next session. I believe that's Thursday. Yes. Okay, great. Any other topics we need to discuss in this meeting. Sorry, nothing from me. All right. Great. Thanks, everybody. I think that concludes our session. I will post a copy of the recording. It'll usually takes about an hour for that to happen. Thanks very much. Thank you all have a good day evening. Thank you.