 All right, recording is started. Welcome, everyone, to Google Season of Docs Office Hours. Here's the tentative agenda, and whoops, not that one. Let's try this one. OK, can everybody see that agenda? OK. Yes. Great. All right. So I've got, on the pull request topic, mark comments slash ongoing review is one for me. So I've got, maybe we'll put it as a sub-bullet PR1 install guide. As it turns out, Xenop, I need to install Jenkins on a Kubernetes cluster on Minicube. And so I've got to follow your install guide precisely. But while doing it, I found some things that we need to discuss. So that's your timing is perfect. Other agenda topics we should review. So PR, and it's, yeah, forgive them. The other PR is the doc skeleton. Any other topics you'd like to put on the list, Xenop? Yes, so I don't know how to summarize this. Chris mentioned something about putting all the files we're using in the documentation in a folder. So we can always reference the documentation. And I think that's a good idea. So I'd like us to discuss what section of Jenkins or I will put this file, like Jenkins value file, service file, and all that. So did my typing capture Kubernetes samples files? Are these to be included in documentation? Or are they for reference? Tell me more about those. I haven't read the comment yet. OK, it's for reference. So say, for instance, those sections where I copy the contents of this, copy this content, put it in a file, we just add a link to that particular file on Jenkins. But I also, you can actually see what the structure looks like, what the yaml file looks like exactly. Because for some people, there might be issues with copy and paste and all that. Right. Good question. OK, so basically what we've got then. OK, so topic is on the agenda. We'll get to that on the agenda. I like that. I think I understand the topic. Anything else we need to put on the agenda? Oh, I'm looking. Maybe for me, it's like thinking about, when are we going to start getting some of the reviews I guess merged early? Because I know that we've gone over a couple of them. What do we consider to be complete? I guess, or is there a staggering release too? And then is there like a blog post that will go out about Season of Docs at the same time? I don't really know that part of this as well. Very good. Good question. All right. So did I capture Kristen in the proposed agenda? Sorry, yes. OK. Anything else that needs to go on the agenda for today? There will be run as user 1,000. Any other topics to put on the agenda? All right, then let's start the agenda. If we discover other topics, we'll bring them to the front and discuss them. So I have pull requests. First PR, I've started reviewing the install guide. What I found was there's a hint that CW may not be using the make run command to see how the text appears. It's a helpful trick. Which are you developing on Windows, on macOS, on Linux? Which platform are you developing on? OK, she's on Windows. All right, so let me take the action item to mark send a link to a video on how to develop for Jenkins.io on Windows. Oleg does it all the time. I use Linux as my Jenkins.io development platform, but run from a Windows computer all the time. I think we've got a recording of it. OK, thank you. Yeah, and there will also be, actually, that's a good one, this Wednesday, there will be a webinar that includes a session by Vlad Silverman on using make run with Jenkins.io. So if I don't get it by before Wednesday, I'll just send you a link to the recording of the webinar. OK, thank you. Anything else from others on the install guide? I think it'd already, Kristen, I believe you've reviewed it. I think Markey had reviewed it as well. So I think I'm the last reviewer, and then we're going to merge it. OK, next PR, Doc Skeleton. So this one, I have not looked at. Others, I think, have given you feedback, Zina, but I believe it's pending the merge of the first PR, isn't it? Yes. OK. And is the merge of either of these PRs blocking your work? Zina, I apologize that I've been so slow on getting to the first. So I'm able to work on my end, but I'm just holding back on opening another PR, so it doesn't get confusing with so many PRs. That's why I've not looked at another. I agree with that. Two PRs in flight is already probably one too many. This was the right approach because of the slow review process on the install guide. Let's finish those two very good. Anything else on the pull request before we switch to next topic? No, not for me. OK, location for the Kubernetes sample files. So let's see if I can bring one up to look at. So this is like a value.yaml file. That's the kind of thing that it is. For instance, this one right here, files changed. There's a reference here to service values.yaml. So, ah, yes. So for example, here it is. Here's, I think, an exact example of the concern. Kristen, is this the place that you were or the kind of thing where, hey, copy from this sample file or should this be in the documentation? Yeah, so this is an example. So for the value file, we have that on the official Jenkins Helm child site. So this might be better. But for something like the service account, for something like the deployment.yaml file, where we're not using Helm or an operator, those files, yeah, exactly this. And so the current use model for the user is they will open this page, right? And until we get it restructured, they would click Kubernetes. They'll have to go find that section. They would then have to copy and paste. Copy, yeah. And that's fine for something that fits on my screen. But now if we look at the example here, this does not fit on my screen. And the odds are that I'm going to make some mistake, like I just did now and miss the first character or the last character. OK, is that the concern then? Yes. Where do we put that file? OK, good question. All right. Because it's an excellent case of a good example, an example that we need the user to be able to read and use and get value from it. Where do we? What if we, I wonder, what if we tried putting it as a separate file here, separate file, and then import it into this so that we would only have one copy of the data? And we could point them to the file in the Jenkins.io actual source tree. Would that be OK? I guess Markey and Kristen, give me your opinions on what do you think is best for the reader of this? What's their experience going to need to be? How do we get them a copy of this file in the best way possible? I have, in Kubernetes, the way we do it is we will link to a separate folder where the actual YAML will be. And do you display the content of the YAML inside the page or you just link to the separate folder? We just link to it because of that exact reason is when somebody copies and paste, if it's off page, then they're going to miss it. And we have found that that generates more inquiries than we haven't volunteers to support that influx. So it's easier just to link. OK, so then basically, we would make this word, for instance, right here, Jenkins essay.yaml into a hyperlink. And it would just be a hyperlink to the OK, I like that. And you just make a what we also do in Kubernetes and Spinnaker is we will say, we'll put a little blurb in the doc that says, this is the link to this code. Like you're letting them know, as opposed to because sometimes they'll miss the hyper. They'll miss the link as well. And then they'll still ask the question, like, where's this code? I like that. Markey, would you be willing to provide us an example that we could put into this? Provide an example of the page from Kubernetes or Spinnaker and shows how they do it. Because I think that sounds like a great idea. It won't be an exact apples to apples example because we're using Hugo in Spinnaker and Kubernetes. But you'll see the linking and get an understanding. So yes, I will provide that. Yeah, and I wasn't thinking in terms of source code. I was more thinking, just point a hyperlink to a page that has that as text that's not can see, oh, it looks like this. And this is how the user views it. Yeah, I'll provide that shortly. Excellent. I like that. That sounds really good. Love borrowing ideas from other projects. So Xena, does that address your question there? It addresses the question of how, but nowhere. Where to put this photo. OK, got it. All right, so that's the how and where to place the data. And I assume that these things don't make sense to place them inside the Jenkins or the Jenkins chart repository. These are really examples that we need to be able to edit and modify more frequently than we want to modify the chart itself. Is that a safe assumption? I would agree that that is not where we want to put them. OK, so then these really probably do belong in the Jenkins data repository. I would say yes. Good, OK. So let's go see if we can find a place that makes sense. I don't know how we've done examples in the past, so we've got. I saw something about tutorials. OK, so I think tutorials are in doc tutorials. So we could certainly put them as subdirectories here. Yeah, Kubernetes subdirectories here, something like that. Yeah, that's what I was thinking. And that seems perfectly reasonable to me. I don't see any other obvious place where I'd say, oh, no. OK, let's see. No, that's. Yeah, I don't see anything else obvious where I'd say, ooh, this looks like a place where we've done examples elsewhere. So it was tutorials doc, tutorials, and then a subdirectory of that. Yes. And is it OK if I call it a subdirectories? Markey and Kristen, does that strike you as OK? So that you would actually be referenced. OK, great. Yeah, I agree. Because it would just be, again, especially with YAML, like Mr. Markey, you've dealt with issues where people copy pastes, just like the indentation didn't take it. Take to the right level. Yeah, it's like, we never know. Yes. Yeah, this is cool. Right, well, and in fact, that's a very good point, Kristen, because in reviewing the install materials, there are times when in order to indent things in terms of a numbered list or something like that, we end up using leading spaces. But leading spaces can be significant in these YAML files. Exactly. Yeah. OK, good. Very good. All right. And the same holds for the value files, right? So really, they're both the same technique applies. Excellent. OK. Anything else on Kubernetes sample files? OK. So that means we are going to be working on this now before we match this pull request, since this change has to do with the first pull request. Couldn't this also be done as a subsequent pull request? I mean, we could take the first. That's fine by me, so tell me. Yeah, at least I don't object to this not being yet, but we get that if the second PR is ready to merge and the first PR is ready to merge, I don't think that this change needs to happen inside either of those, unless there's something where you'd say, oh, no, this PR will be, the second one will be much better if we do this. I'm OK with that being a later. I think it's fine. So we actually pushed some concerns out. OK, great. And OK, as time goes on. OK, anything else on location for the Kubernetes sample files? OK, next question, then. Timeline for merger use and completion? Right, so I think we might have already covered a lot of this, because I was kind of wondering what we were planning on doing with the order of the PRs, or making sure they have enough reviews and when we were going to deliver. The other point that I had was about the, yeah, but it's kind of been answered, which is good. I'm very happy about that. I guess the last remaining outstanding question in this section would be about the blog post. So I know for the Google Summer of Code, each coding phase, we required them to have a blog post kind of about what happened. I don't know if this was something that, this is a completely different program, where it's just, it takes a lot longer and we're already doing a lot of writing. But I didn't know if there was also some, if we were going to do something or a requirement or like talk about where, this is so bad that it's like, we're X number of weeks in or like something, it's like, done these different sessions, we've been doing this. It's kind of like a awareness for what's been happening. I don't know, this might be a thing there. We throw it out to everybody to see if it makes sense. If it's too much more writing or like extra work, maybe not, and then we just keep going on, but I didn't know if it was a good chance to give a highlight of the awesome work. Xenob that you've been doing and also to maybe get some extra eyes. I get like seeing the good stuff that you've been doing and especially for the getting started guide. See, my thought, I like the idea. I was thinking, what if we had a very brief one paragraph or two paragraph blog post from Xenob that said, hey, read the new install guide. Yeah. And it was just a link to the new install guide. Hey, here it is, Kubernetes in or if we can stand an extra day or two before the blog post, we refactor, we rework the install page to use. So I rework the install page or Markey reworks it. Somebody reworks the install page and we get it restructured so that she can point to the new page and it points to the restructured page and says, hey, we've made it easier to read simpler and it's got Kubernetes in it. It sounds really good. I think that's a very good idea. Yeah, awesome. I like to that. Yeah, it's like it doesn't really need to be like a massive thing. I like the highlighting that, hey, this install page looks really great now. It has extra information about the Kubernetes. I like that a lot. Great. Okay, so let's, if everybody's okay, I'm gonna take back that action. Work on the restructuring with the doc sig. Thinking about my schedule, I'm doing a webinar on Wednesday. So it may not be till Wednesday that I get at this. Is that okay with everybody or is that too long a delay and we need it sooner than that? So it would be like potentially Thursday, we'd review it in our session. I think that would be fine. I agree. That's fine with me too. Okay, great. Excellent. Anything else on timeline for merch reviews? Thanks for the question, Kristen, and very much. Sure, if you need help with some of the restructuring of the page, feel free to reach out. Maybe I can help a little bit with that too. Just to help. Thank you. Yeah. Well, and certainly I will probably come begging for your reviews. Sure. Because structural changes like this inevitably need human beings who look at it and say, oh, yeah, that was technically correct, but you butchered it. Or, gee, that was technically correct, but it's terrible. Yeah, sure. I can definitely help with that. Great. All right. Next topic. Run the Shoes of 1,000, Marky. So I ran this on, I did this three ways. I ran this on Linux and I didn't have the problem. I ran it on Mac and I didn't have the problem. When I ran this on Windows, which I am a complete noob when it comes to Windows, I did run into the problem. So I'm wondering if it's a Windows only issue. I have pinged somebody else that I pinged Alex and asked if Alex could take a look at this and try running it on Windows to see if he sees any abnormalities because he's more advanced at Windows than I am. And I still haven't heard back, but I did just want to give an update. Thanks, Marky. And since I'm using Windows, I think. Yeah, I think for now that you'll be fine to just continue running as user zero for your work. Okay. I also wanted to add one other thing to the agenda that I completely forgot. And I am going to wait till you're done typing and then I will say it. In the meantime, I'm also going to ping somebody. I'm set. Go ahead. The transfer of org admin and mentor that has not been done yet. I'm pinging Oleg. I kind of forgot about it last week because of CDCon. Right. Any other topics we need to review in our session today? I think we can call ourselves done. Then if no other topics, the recording of the session will be posted to the doc site probably in an hour or two. Thanks, everybody. Thank you.