 Welcome to Docs Office Hours Asia. It's the 17th of June in Asia. And great to have you here. Today's agenda includes action items, Google Summer of Code, Jenkins 2.346.1 LTS Change Log, the Required Java 11 Project, the Support Java 17 Project, Migration of User Stories, and this one is really another way of expressing an earlier topic. Any other topics you'd like to be sure we add to the agenda? You just said something that you wanted to add. Oh, let's see. Well, what was it? Oh, was it maybe upcoming? Maybe let me put it this way. Upcoming blog posts that Marcos. I don't know, something you mentioned, you mentioned the conference and you said, oh, we should add that to the agenda. Yes, so, yeah, and so that's the theme here is upcoming blog posts that I owe to the organization. And so let's put that there and we'll put that in the guilt department. So we'll put it at the end for right now. Good, good, good. Okay, anything else that needs to be on the agenda? Do we need to do a review of that one longstanding Jean-Marc's pull request? Or did that happen already? Depends between you mean longstanding pull, well, let's put it on the agenda and we'll go hunting for it, very good. Yeah, I like that. All right, so longstanding pull request, we absolutely should look at them and let's put them that one pretty high on the list. Anything else that needs to be on the agenda? I'm gonna drop off about 45 minutes in, but it shouldn't matter. Okay, well, let's, and that would be good for me as well because I got a bunch of editing I need to do for the changelog. So anytime we can give me back is a win. All right, so first topic, Kristen for your benefit and for Megs, the Pipeline Steps doc generator, really nice work from Veehan on this pull request to add independent scrolling in the documentation sidebar. So what this does is on the Jenkins documentation site when I have, when I'm looking at a long page like managing Jenkins, the navigations on the left disappears as I go further into the page. Right. And Veehan noticed, hey, that's a challenge. That's a problem and it's especially a problem because in the Pipeline Steps reference, Veehan would like to use this left-hand side for better navigation, but when traversing through long pages, you can no longer see the navigation on the left. Only the A is gonna go on. Exactly. So good point. So what Veehan has proposed is this change, let's go open up the preview site because it looks really cool. Preview site, here we go. And Kristen, I think you've already seen it, but just to show it from eggs benefit. So here we go, let's take that same one that I showed. Notice here in this case, it's got a horizontal scroll bar or a vertical scroll bar, but that index stays visible on screen all the time. And in most cases on my screen, chug, chug, chug. Sorry, the preview site's running a little slow at the moment. There we go. On my screen, there isn't even a vertical scroll bar in most cases. So the scroll bar only appears in those cases where the content, where the number of chapters is so long that it forces the scroll bar. And one solution there might be, okay, get a longer screen, get a deeper screen. The other is we could reduce the number of sections here in system administration, for instance, instead of individual reverse proxy pages, we could bunch them together, something like that. Right. Now, there are other techniques, but this one, Veehan has working and I think is quite workable. So if we look how it feels in the pipeline steps reference, here's the example in pipeline steps reference. And now let's look at the poster child of problem pages. Okay, so now loading a mammoth page, and I do mean mammoth, okay, page is loaded and now we're going to expand it with something huge. Okay, oh, and there's more huge stuff that needs to be expanded and it just keeps getting more huger and hugest until it's hugimous monstrous. And yet still on the left, I have navigation. Oh, marvelous. So really, really well done. Like that alone, like even the scroll bar to me is like a huge plus, but also it's staying in place. Well, yes, I find the scroll bar distracting, but it's a rarity that it appears. And therefore, now if I change my screen size, and this is what Veehan had highlighted, if I instead make my screen size something smaller, let's look at something closer to a Chromebook like this size. Now the scroll bars appear much more frequently, but that's the price of having a shallower screen. Right. And again, even there, there are other ways we could handle it on the left-hand side potentially things like, hey, make this expand and contract in a different way or reduce the size of all sorts of techniques. For me, this is enough of an improvement that I think it's worth merging. Now I've asked Veehan and confirmed to Veehan that he's okay if it waits until next Thursday before we merge it because I don't want to risk disrupting the security release that goes out next Wednesday. Good point. They need to be able to publish their documentation without surprises to the layout. And if this can reduce a little bit of the work that Daniel Beck has to do by delaying it and Veehan was okay with that, he said, sure, that's fine. Okay, good. So any questions or comments from either of you, there is already a skilled JavaScript review from Tim Jacome. So I like that. And Kristen, I see you've commented on it. And Shabrinak Konechni, who's the other person who's done Dockside Maintenance has been looking at it. So we've got, and in fact, Shabrinak asked for something that now Veehan has implemented, keep the scroll bar on or keep the, sorry, keep the index visible. The earlier, the first implementation was included a hide the entire menu completely and push the content to the left of the page. Okay, yeah. Cause I was about to say like, I think that I was, this is a little different than I was expecting to see here because I know that there was the collapse. Right, right. And that was something that Shabrinak had noted that, hey, on my wide screen, having a collapse by default is painful. And most readers of our pages are on wide screens. So the thought was, okay, let's make the default wide, handle wide. And so what Veehan did was took out the collapse, which you see the example of the collapse here, right? This arrow was the collapsible thing. Yeah. And that, do we make any claims at all that this documentation can be read on your mobile phone? No, no. And in fact, part of the one of Tim's comments, so what Veehan did was looked at it on various small device layouts and said, oh my sakes, it's awful. It looks bad on small devices already. Right, so Tim showed here, here's how it looks on mobile, on one mobile device size. And here's the, see, where's the other example? Or let me get Tim's, here we go. Tim's observation is, hey, this looks good. It's better than before. And yes, there's certainly still room for improvement, but let's go ahead. So any objections from either of the two of you to that, to the layout of the demonstration? It looks terrible on the mobile device, but you could read it. If you were desperate to look up a little bit of information, you could find it. Yes, yes. If we look at the current site at mobile resolution, so I'm gonna go ahead and bring up the current documentation at mobile resolutions with a mobile layout. So what Vihon taught me today, how to do this. I'm now going to see if I can actually do it the way Vihon taught me. So I just hit F12 to bring up Google Chrome's menu. And then this little icon here that says toggle device toolbar, I toggle it. And up here at the top, I can pick a device. So I'm gonna see how it looks on my Galaxy S8 Plus phone. Okay, so that's how it looks. And now I'm gonna click, do some navigation here. Let's do documentation, Janken, which one? Let's choose a big one like system administration. Okay, there it is with the first, it starts with the table of contents, not the content. Okay, that's distracting. And then it starts with another table of contents, the navigation table of contents. And now, okay, now I'm here and I could pick one and say I wanna read about Nginx, HAProxy, or Nginx proxying. So I click that and, oh, oops. And I'm also running, let's put it to no throttling so it doesn't show spend time. So here, notice the massive horizontal scroll bar here. This is painfully bad. And it's the reason in this case is because there's a code fragment. And this code fragment is using fixed space font as intended so that people can read it as with columns aligned. But it means, hey, that does not look good on a mobile device. So this is before the prototype. Now, if we take the same thing, let's go find that exact same thing here. Is it managing Jenkins? No, it's system administration, Nginx reverse proxy. And now we're going to bring up, and by the way, Kristen, be sure you tell Vian how grateful I am for his willingness to teach me how to use this device toolbar thing in Chrome. It's pretty cool. Like to be able to see the different phones and stuff. But yeah, we did try to talk on Monday when we were, or Tuesday, saying that it's like we should try to reemphasizing what you want to focus on. But like, well, it's good to have phones. We want to make sure that the experience on the desktop is probably the most common experience for people using our documentation. Right. Exactly. So actually on mobile devices, you could turn them sideways and have the white screen too. Well, and there are interesting mobile devices here. You can check with like a Nest Hub Max is actually not an unreasonable size. Now, it's also hints that, wow, that's not what I quite wanted. But if I look here, I think it's every bit as bad. Yeah. Yeah, I totally get what he was thinking with the, it's like, okay, I see what I mean, especially if you are on this and you're trying to scroll, you're just going forever. Oh yeah, interesting. That layout is much worse. And that was really interesting actually. Like seeing that work, it's so different. It didn't do what I would have thought it would have done. Like it's huge. Right. And I don't know what that means, right? I mean, I don't expect anybody to look at our documentation on a Nest. Nest is a Google networking device. And so no way are they going to read Jenkins documentation on a Nest device. But it hints that, okay, there are plenty of things we can improve. And as we keep working on it, we'll find better and better ways to do things. Right. I think Tim's comment was exactly correct. I mean, navigation bar, for instance, well, come on. That's, this should be the hamburger menu, right? I mean, and it didn't collapse it to the hamburger even though it doesn't fit at all. So yeah, it's lots to improve if we reach the point where we've got time to care about mobile experience reading documentation. Yeah, I have. It's a phone. Well, or in this case, it's an iPad. Yeah. Even then, an iPad, you know what, that's... I kind of brought, I think that I could see potentially like someone using an iPad over a phone. Like I wouldn't think that... Yeah, maybe. I would, yeah, you know, if you're like, I don't know if you have a, if it's just up, I don't know. If you're using it as a second screen, maybe. And that's just, you know, you have it over there, just reading, maybe. But I was like, I feel like the, I think we're okay on the phone thing. Does that make sense? I was like, it's like, but I was like, I can get maybe that we want a little better experience on like a tablet, but yeah, I wouldn't really stress. Well, it's, I think the developer experience will be from a desktop. Yes, exactly. And therefore we owe it to each other to make the desktop our first focus. Exactly, exactly. And of course the thing that's disturbing is it's the old question of printed stuff too. Now I want to write it on the side. I have an hour long subway ride and this is my chance to read up on something. You know, I'm not actually trying to do it. I just want to read something that I didn't have time to read. Okay, so now now it's sounding like there is a phone justification then. Bring out your tablet. I mean, use your Kindle. Yeah. There we go. All right, so anything else on that topic? I think we've seen it. I did put down that I would like Daniel Beck involved before we merge. And if he's not available, I'm okay with that. We intentionally delay the merge until after the security release just to avoid any disruption to Daniel and the security team. Yeah. Good. Okay, next topic then was long-standing pull requests. Kristen. All right, I was just looking back at the DocSig channel and the Gitter. And I saw that Jean-Marc had made a comment about the pipeline, improve a plugin pull request. Is that? Ah, okay, right. So that's this one here. And yeah, so what John-Marc has realized is, and correctly, he's realized this thing is stalled. Okay, yeah, I just, I saw that he had mentioned it and I was like, oh, this is fun. Well, it's very promising. It's like, that's good. Exactly, right. I wanted to encourage that. Like, yes, we are responsive, so. Somebody who, and John-Marc and I have had the conversation about that, about, hey, what needs to be done? And he's asking good questions. The things he asked are things like, well, when I see this one that says add a Jenkins file, there's an awful lot of boilerplate, you know, an awful lot of things that are repeated every time, coming soon, patience, patience, what we will see is, there's a thing that says, how do you create a branch? There's another thing that's, how do you make the change? And then how do you submit a pull request? And those things are the same, largely the same for each of the pages. And his point is well taken. It is in fact correct that create a branch other than the name of the branch is the same. And in fact, I did it using an ASCII doc include file that's parameterized. So this text actually only exists once for all 15 or 20 things. And then this is custom in each little section, but then the create a pull request is again, parameterized and only happens once. So he's gonna see if he can find a way to do this better so that we don't bore readers by saying, this is how you create a pull request. The other observation was that Tim Jacome and Spinnock and a few other, and Alexander Brandus said, hey, why are we using command line get and telling them to go open a webpage? Why not just use the GH command and have them create a PR and teach them the easy way to create a pull request? And it's a valid point. I love GH. I love the command line interface to GitHub. It's brilliant because you can do this whole mess. It does this nice console base, prompt you through it process that lets you create a valid pull request from your command line. And so this could be replaced with GHPR create. Oh, nice. And it's a valid point. It just means then we need some place, a way of telling people you must have GH. And I truly, either of you seen GH before, it's really an amazing, amazing, amazing tool. So when I do things like this, GHPR list, here's the list of pull requests, GHPR status. Here's the current status of those pull requests. I can do GH repo sync to bring in the latest changes. Also, oops, it would GH repo sync. It's just amazing the kinds of things. And if I do a pull request, it will literally prompt me through the whole process. So bogus is going to be the name of my branch based on master GHPR create. Here we go. Where should we push the bogus branch to that location, the title, a bogus demonstration pull request. Use the template, edit it. It's using my full template. So it provided it from GitHub. And yes, I can fill in the checkboxes like the usual. All of this magic, now when I close that web, that editor, submit it, it creates the pull request for me. Oh, well, dear, how sad. Okay, I'm run the wrong computer, I've got to fix that. But it works just really sweetly. Sorry, I'm used to using it from another computer. I'd have to show you elsewhere. Sorry, enough boredom with my, how enamored I am with GH. So does that address your question, Kristen, in terms of what's the progress on the adopt-a-plug-in tutorial? Yeah, I just wanted to make sure we were, if there was a chance that we could close it or like push it through, or if there's anything else to the interview, we'd be interested. So yeah, that's it. I think there is more to, there is certainly more that needs to be done. It is not ready, but John Mark is taking the lead on Hacktoberfest. And he wants to be sure that this thing is ready for Hacktoberfest. And I've been approved for DevOpsworld to present a workshop, or at minimum a one hour session on contributing to open source, these same things. So we're gonna have this merged for sure, or a variant of it merged in time for DevOpsworld in September. Because I'll use it there. So does that answer it? Yeah, yeah, that works. All right. I keep talking and you're ignoring me. I think- Oh, sorry, Meg. Well, I'm mute, I was muted. I'm sitting here. Are they not acting like they hear me? Oh. Did I see merge conflicts at the bottom? Are they bad? I don't think there were any merge conflicts, but if there are, let's look, good question. Let's see, so. It's so familiar these days. Oh, still a work in progress, okay. Yeah, I haven't marked it ready for review yet because it's not ready at the point where I'm ready to say, yes, we should publish it. I mean, I would like to remember a fellow I used to work with closely respected highly would often remind me that you can improve on something it doesn't have to be perfect. And he would say, I will not hang my head in shame for these improvements. Oh, that's, no dispute, that is fair enough. You better not dispute with that person. We're gonna have an issue with you, too. Being, I am attempting to be self consistent. Thank you very much. But I mean, it kills me all the time. I'm sitting here, oh, God, new project and the stock is such a mess. And it's like, it can't be fixed in one fell swoop. It just can't be done. And trying to do it is worse than anything. And it's like, you know, baby steps. And I've always liked about Jenkins too is that we were very comfortable saying, this is a work, this particular section is a work in progress. And this one definitely is a work in progress. Now, I'm still not comfortable with the navigation piece as another example here. So this one doesn't have VHUN's navigation improvements but you see down here the improve a plugin tutorial. This whole mess up here should be collapsed, right? It's too hard, too difficult to find this all the way down here. And that's a whole different issue. The developer guide does not have the same expand and collapse implementation as the user guide does. Okay, onward. So now on the other topic of longstanding pull requests, we've been successfully resolving or closing ancient pull requests, our last effort, closed some things that were back from September. Are there any of these that you'd like to, we wanna take a look at and try to close, say one tonight and say, hey, we're not gonna carry this one. So nothing on that page triggered for me. How about, well, this one, I wonder, it's got changes requested. Okay, this is Oleg saying, hey, ah, okay, Oleg is saying, hey, we shouldn't put real documentation in the redirect page and that makes sense. True. But this also needs major rework. This class do offer. Oops. Yeah, this is a developer section. It really doesn't belong in redirect. This is clearly developer material. Yeah. So I don't wanna close it, but yeah. All right, so I'm willing to give up on that one for now. No. Is it still around and willing to work on it or does somebody else need to go in there? Yes, I think anybody could do it. Kevin could, for instance, go in and do that when we get to that point. Does it look like it needs a quick edit? It definitely does need an edit. Well, since I don't do anything these days and about all I'm good for is nouns and verbs. What was that number again? 3427. Yeah. I could do something. Of course, you know what I'm gonna want in reverse. Well, and I still owe you to talk to Daniel to see if we can get review. But not the week before a security release. No, ma'am. Not the week before a security release. Definitely not. And when you talk to him, would you please give him my love and kisses? There will be no kisses. There will be no kisses, but I'm happy to give him your love. Absolutely. That's true. You'll have warm memories of a couple of all-night sessions with him and I would appreciate that. Excellent. Great. Thank you. All right. So, okay, if we go on to other topics? Yes. All right, so the LTS change log is in progress. It needs, Daniel did a great job of reviewing it. Kevin's applied. The majority of the changes requested by Daniel, they were really good observations of, hey, this is just too much detail. And so the poll request is looking better, but I've got to do another review of it because it's, well, if we look at the layout of it in the prototype here, you see these big red things are not supposed to be at the bottom or the middle. They're supposed to be up at the top, that kind of thing. Major is supposed to come before any non-major items. That kind of thing. So that's today because I really want to get it merged tomorrow so that it's, there's no risk of it being a barrier to Daniel and the security team as they prepare for next Wednesday. FYI, we've got Java 11 coming up June 28th. So one week after the LTS release, we will switch Jenkins Core to only build with Java 11, not with Java 8. Now, one of the changes there that we discovered from that, one of the sort of unexpected side effects was, this is how Java doc looks when generated with Java 11. Remember that look because notice that there are no frames on that look. Now, if we instead look at the Java doc from Java 8, for instance, let's pick a plug-in like get client, here we go, here's a plug-in. Notice that it has a frame, another frame and this one. So the Java 11 look and feel is much easier to navigate because here I can just type in a search thing like file path or SCM and it shows me the things that match and then a click will actually take me there. Now, in this case, it's currently broken. So I have to do a little edit and this is a known bug in Java 11 but we've got to work around for it that Basel has implemented. So we get a much better experience for the user by having Java 11 generated Java doc rather than Java 8. All right, so that's really it for that surprise. Java 17 is currently in preview, full support will be announced with the same release that we do the require Java 11 change. What does the doc look like under Java 17? We've got a, Kevin's working on a page running Jenkins with Java 17, similar to the page we have today running Jenkins with Java 11. And it points people to, you can either run it on Linux, you can run it on Docker images, you can run it on Windows, dot, dot, dot. Yes, even on the BSDs. Cool. Yeah, it is, I'm really truly pleased. So last item or second to last item was this migration of user stories. So Jenkins is the way was an initiative that we did to capture stories from Jenkins users. And there are 50 or more of these stories that have been captured, things like, hey, railway signaling, or a fun one, let's see, what's a fun one? It was... Execute all my desires. Yeah, okay, there you go. I was thinking more of, oh, network diagnostic collection, monitoring and report. Network diagnostics is not a common use for an automation tool, right? But that's what they're doing with it. And those kinds of stories are here. We originally had them in a WordPress site, but Gavin Mogan has extracted them from the WordPress site, turned them into data so that we can manage them as code in a GitHub repository. And now we host them ourselves on stories.jankins.io. Yeah, Gavin's been absolutely wonderful. He found a way to preserve the map. And so this map lets me zoom in and see where people have submitted these stories from and who they are. Oh, wow. Yeah, it's really quite a, it's a fun thing. Okay, let's see if I can find the place where I visited. There it is. Okay, I visited this location in Pittsburgh, Pennsylvania. And if I click this, we're going to see Alan Waite Robotics read user story. So here's their story. And yeah, it's actually quite a cool story. They're using Jenkins to automate robotics builds. Cool. So the site is growing nicely. There are still some things that need to be done. Case studies existed on the old site but aren't on the new one yet. And there are some pages that don't redirect as expected, but they're flagged on Jenkins.io so that we know which ones they are. Oh, cool. All right, Meg, I think you were almost at an end. Do you need to drop off now? Or are you okay if I take a few minutes? If I had another five minutes or so. Okay, well, so last topic then upcoming blog posts that we need, this maybe is a good way to do news. So award winners from CDCon. This is a cool one. Darren Pope was named the CDF Continuous Enthusiast. Wow. Basel Crow named Jenkins, what was it? Most, oh, I forget the title. It was contributor award. Top contributor or some such thing. I'll have to look up at the exact phrasing. Vodek Filonier, security MVP. Wow. And several of my colleagues in Europe had to ask and wondered what's an MVP? And so I had to explain at the baseball metaphor, most valuable player. I know the two of you know what that is, but you have a cultural bias, don't you? That's right. I wish we didn't have to call them a player. Personal programmer. Exactly, whatever. It's that, okay, where did MVP, what's the source of the MVP acronym? I think it's baseball. Baseball, I think, yeah. And then there was one other. Let's see, who was the other one? Oh, Oleg Nanashev, CDF top documenter. Yes, that's right. Yep. And there may have been one more. Who was the fourth, the other Cloudbees person? I don't remember, but that's one blog post. And then we had a contributor summit that's another blog post. And then we've got whatever, one or two others. So there are several things that need to be written. And that's it for me. I have one other quick thing to add for you, just for the back cross. Have you heard of something called Killer Coda? I have not. What's Killer Coda? It's, you know what's happened to Cata Coda. I don't. What happened to Cata Coda? I saw what Cata Coda a year or two ago. And you know what that was. And it was a very cool tool. It's very cool. It's working out so well for O'Reilly that O'Reilly has decided that it's just their tool. And it's not available for general use anymore at all. They're not selling any service for it. Killer Coda is an open source version that if you have Cata Coda code, you can just stuff it in apparently and it just works. Oh, oh. They say that they're really alpha. They're not even beta state. But we just put a tutorial in it. We had some kid in India who wanted to try and do it. And it is magnificent. It worked well. The people were great to deal with. But it's one of these things. Setting up Captain is a nightmare. And we had this tutorial where they got like 10 minutes. It was really a lousy tutorial because it said click here. And look, this is what you get. Now click here and you get, you know, there's no explanation or anything. But it took you a half an hour of setup to get up to the point where it would work. And I mean, nobody could make the setup work. And with this now, it's like, click here to do this and you sit there. Some of it takes three minutes. Some of it's instantaneous, but it's one of those you click in the left menu and it happens over in the canvas on the right. You just see the screen. It's an impressive tool, nice people. They sell some subscription things, but pretty much you can use it for free. And really nice for a little tutorial or demo. The caveat is that from the time you start a session, you've only got an hour. The session is about an hour. So you wouldn't want to do a big topic, but it could be nice for a little topic. Interesting. So on that theme, we had a bug report that came in on the Jenkins tutorials. And it motivated, discussing an idea that Damian DePortal had of consider replacing tutorials, our overly complicated tutorials right now with Docker compose. And Codacoda is an even better solution than Docker compose, right? Docker compose has the benefit that it's fully open source, but you have to host it yourself, but it gives us something. And this could be, you say killer Coda could be better for users, but now they're hosting the compute resource. Is that right? Yes. Okay, yeah, which means we'd then be at risk that they may go away if they're no longer able to fund the hosting of the compute resources. Right. Okay. I don't know what, well, and they are, I mean, I think it's because they're so new. I don't think they're gonna be free forever. Right. And they're attracting users. They are just like off a professional level. And I think with that, you get metrics right now. We have no idea how many people are going out and using this, but. Yeah, but I'm seeing a general industry. We've got, a tutorial should be, maybe I have to do six tutorials to get the whole thing, but don't give me an eight hour tutorial. Right. And it's not your instructions for how you get started. This is how to introduce you to stuff. And then there's someplace else that says you have to do this and this. And noticing, boy, it's just, we all want to overload these tutorials and make them something they aren't. But in a way having that one hour limit is actually, I think a good thing. Sure. Yeah, absolutely. So. Any other topics for tonight? Nope. I think that does it. And you need to go right to dinner, so. All right. Thanks everybody. Thank you. Good stuff. I will get it. I will do a text edit of that PR soon and I'll let you know when I do it. So you can go in and accept my suggestions if you like. Thank you. Thanks very much, Kristen. Thank you as well.