 Okay. Okay. So recording has started. Welcome to the Jenkins documentation office hours. As a reminder, we honor the Jenkins contributor covenant. So we, the fundamental principle is be nice, specific exceptions or concerns are handled through Jenkins governance committee. So we want to be treat each other well and with respect and dignity. So welcome to office hours. What topics would you like to address? Let me bring up the notes and I can share the notes and then we will talk through and prioritize some topics. Did we miss taking notes? Last week we did. Shameful. Sorry, everyone. We usually take notes in addition to a recording. Last week it appears that I did not take any notes. I just had the recording. So this week we'll fix that and we'll take notes in addition to the recording. So here are the notes and I'm going to go ahead and share my screen. All right. So can everyone see the Jenkins docs office hour page of notes? Yes. All right. So and I will post the link to this page into the chat so that you can find it and follow along with us if you'd like. Okay. So Jonathan and be sure that our list of who's attending is up to date. So Stephen Jude and we've got one other attendee that I'll let make an introduction of themselves or two. I don't recall your last name. Can you help me with that? Thank you. Okay. Excellent. All right. Okay. So two weeks ago we talked about the season of docs site and various pieces of the Google season of docs process. Are there topics that you would like to propose for today? And let's put them here and then we'll prioritize them and decide which ones we approach first. Hello, Mark. Hi, Jonathan. How are you? Hi. Hi, everyone. Yes. I would like to propose to speak about the history of the Jenkins IEO. For example, what's important things do you consider to pick that technology? It's a old one, not modern one. I was studying the GitHub files and I guess you are using, we are using an awesome website, back to website. It's correct? I believe it's called Ostrich. Yeah, so Ostrich. Oh, yeah. As the page generator. Yeah. Yeah. Yeah. So I would like to know more about the decision. For example, we are using sdoc and not markdown as common use. And I prepare to continue our samples use we saw in the last video meeting. I prepared some samples too. So after you explanation about the history, I would like to share my screen to show it to you. Okay. All right. So further samples of the, and these were samples of the analysis? Yeah, a sample of our, I stood about the feedback. For example, I have an idea about the search field and another website generator with some new features that could be used to trust. Oh, good. Okay. Great. All right. Okay. Very good. Okay. All right. Any other topics that others would like to include in the discussion? I would like Mark to propose a topic about relationship between Google season of docs and Jenkins infrastructure. Specifically for technical writers, how to get accounts in Jenkins infrastructure. But also I would like to address the issue of getting credentials to host Jenkins instance on the cloud. Okay. So in this case, what you're saying is just to be sure I understand this is you need to run your own run a Jenkins instance. Is this in Kubernetes or in some other location? Well, let's say that right now I have, for instance, Docker instance, which I would like to be hosted on Amazon cloud. Just simple case. All right. Okay. Good question. All right. Are there other topics before we get started on any specific topic? So Stephen, were there any topics that were of particular importance to you? I was, I'm still looking at the features we have on the proposed features we have available for students to pick up. And I'm still going through the Jenkins code base to understand a bit of it. I think I joined yesterday. So I'm still not comfortable. I'm still trying to adjust myself a bit. So I'm ready to go on with anything we are saying. Maybe I can learn better before I start contributing. Okay. Very good. Well, so then I'm going to use this as a chance to propose a Google, Google season of docs timeline reminder. Like to be sure we include time for that. July 9, due date, reviews, still needed, etc. Okay. Good. Any others before we start working on those topics? Okay. Then let's go ahead. Let's take them on. First one then was, I'd propose that we just go ahead in the order that the questions were asked. History of the Jenkins IO site will then give some time to Jonathan to review the feedback analysis site that he's created. And then Vlad will address the relationship between season of docs and Jenkins infrastructure. And we'll close the meeting within an hour with the one minute reminder about timeline. So let's take on the history of the Jenkins site first. So maybe a simple, a brief overview of what's behind the Jenkins site. Jenkins.io is a static website. All right. It's, hang on, I have to exit Slack because otherwise we don't really want my Slack messages appearing on everybody's screen. There we go. Okay. Excuse the interruption. It's nice of Angel to say thank you, but you didn't need to see it. All right. So Jenkins.io .io is a static website. It is assembled from multiple sources. All right. And so its sources include ASCII doc source files that document Jenkins features, right? It's also assembled from content extracted from Jenkins plugins, like the list of extensions, like pipeline help. It's also generated. It also generates content based on the changelogs for LTS releases and weekly releases. And those actually come in as YAML files. And from other data... And those changelogs are those both for Jenkins LTS itself and the plugins? No, they are only for the core releases. Only for the core releases. That's a good clarification for core releases, including LTS and weekly. There are other data sources involved. So it includes content, ASCII doc, blog posts, et cetera. So generating a static site from a mixture of data files and source files in markdown languages, et cetera, at the time they were working through the choice process of, hey, which tools should we use? Ostrac was a reasonable choice at the time. And so they selected Ostrac as a reasonable site generator at the time. Now, I was not actively involved in the site generation at that time, so I can't give you all the details on the discussions that were... That took place to come to the decision. I can tell you some of the stories around ASCII doc versus markdown. So... But Ostrac was selected. Since then, there have been other site generators that have come into existence like Antora or others, and those would be potentials for consideration. I have friends that I consider very, very smart who are deeply, deeply impressed by Antora as an example. So now, Ostrac then chosen as the orchestration framework, et cetera, why ASCII doc is the markup language rather than markdown, and the fundamental reason is because markdown is not a single specification. Markdown is you choose your variant, and the variant... The variants have important differences between them, and those important variants get in the way of many things. So there's the GitHub variant. Seven years ago, when GitHub was not the sole and dominant provider of Git repository hosting, it wasn't clear that GitHub markdown would be a sort of universal standard. The other challenge is that markdown is not especially well suited for generation of books or PDF, book style output, whereas ASCII doc actually thinks very hard about how we could return this into a printed volume if we needed to. Jonathan, does that summary help you at all? Are there questions you'd like to ask relative to that? Yeah, I see the need to ask about this choice because I was studying our Ostrac website generator, and it looks like it's a... He is dead. A dead page. There is no more movement in the community. For example, I will put here in our shot just a moment. Where is the shot? He is the link to their GitHub, and the first issue we can see in March of the last year is the site is dead. So it's complicated to find the new plugins or new instructions to improve our website documentation. But it's possible we work with not just a question. There is some interesting to migrate the content for a new platform, Mark, or not? Oh, so there's interest. It's certainly worth considering should we switch to a new platform. And that would be a project to propose. It's a valid project and to say, hey, we want to go someplace else. Absolutely. So is there interest? I asked that question thinking about this proposal. And yes, with the caveat, with the warning that it is a large project. And there is probably plenty of programming involved, not just writing. Not so much. Today is quite simple to do the thing. It's almost our right to program it. Can I share my screen? Sure, absolutely. Here, let me stop sharing mine. And I have to grant share. So yes, go ahead. Just a moment. Are you seeing my screen? We are. Okay. So here, we are speaking about the view press site generation site. So here, it's showing to you. You're seeing the view press website. Okay. So it's a normal website to our, to work with the documentation. And it uses markdown. Okay. And so at the top, we have the nav bar with a search working. So we can see it's possible. Use the search to find any content. So for example, we can, we have the same features about permalinks at previous page, next page. And we can see the left update info to our page. And you can to edit on GitHub too. Okay. It's the most common and useful features to our docs. I'm great. Here, we have the tutor guide to Jenkins get started. So if we are here, we can guide it to her. And just a moment. Okay. Okay. And see our get started documentations. Okay. So I get this content and migrate for a local sample. So we work with our data. And here we can see, for example, the sidebar with our page links. And it's a, the improvements are, we have a better structure about our fonts. So it's nicer to read about. Okay. We have links. So we can use these tips are here. We can see it's almost the same, but the principal feature is about our session bar. So here we can, for example, look for style installations. We receive some options about the, the talk. And then we can use some plugins to my style too. So for example, here, we are working about the pipeline. We can see the samples. So you can step by step go through step by step. And we can, for example, style plugins to work with the steps in our documentation. And put in a reasonable way, not the only vertical tool. So some, some samples for our users. Okay. Okay. Now speaking about our search. Now it's common to use this guy's API tool to mark our content, web content. It's common. For example, if we are here in the VuePress website, we can search something. And so it, the search is executed by Algolia website. The Algolia website is a search engine provided by API. And it's free for 5,000, 50,000 requests. So I don't know how many users visit our page per day or per month, for example. Do you know, Mark? We had, we had 150,000 in a month. Yeah. So we had 100, it was 145,000 in the month of April when Olivier gathered some data for a blog post. Yeah. So for example, we can build as a plugin for, well, we struck the platform, we, maybe we need to program a new plugin to improve, to offer a search button for our users. So here we have the price. It's free for 50,000 requests per month. Okay. A lot of websites use just by, I don't know, tell you if it's only free or not. Maybe not, I guess. Because it's, for example, VuePress is a big website. So maybe they have a page plan. But in our case, we can, for example, use the default solution that is only work with the top case. So for example, here, I will see my, my, this is a studio. You can see it or not? Can see it. Yeah. So what I see is named slots and default slot content, right? Yeah. Yeah. Exactly. So it's a H2, HTML H2 tag, H2 and H2 3. So we can work with search. It's a simple way search box. Now where is, here, it's a tip. That built-in search only works. It's a free feature, but only maps the H2 and H2 tags from headers. So we cannot have a so-rich research like this one, because this research is provided by Algolia. Okay. But we have a simple research that gives us tags, markations in our file, or our, for example, I can hear, for example, Jenkins, where is Jenkins dashboard. So for example, we have here several sections. So I put here option and I can see all them here because it's a top case section. Okay. So that's it. It's just to show you a new option to work on documentation. And I don't know if it's new to say how we can develop a search plugin. That's it. Thank you. Okay. So view press looks interesting. I had seen someone use Algolia with Antora as the site generator. Yeah. And I have not seen anyone use view press, but so a proposal to consider switching the site generator is certainly a viable proposal to say, hey, I think this would be a good Google season of docs proposal to make the transition from Ostrac to something else. Okay. You believe it's sidelined with Google season of docs or no? I think that would be just fine within context of Google season of docs. It could also work well as a separate standalone project. My initial assessment is it's a large enough project that there's a lot of work hiding behind that transition from one site generator to another. Because the code that I believe the customizations we're using for Ostrac are coded in Ruby. So you'd probably have to develop plugins in whatever language is used by the new generator. And before you can get sign off that, hey, yes, we're going to do that, we would want to be sure that we reviewed with a number of key players to be sure that they said, yes, a transition to this other site generator would need to have these capabilities. And they would likely tell us, hey, we've got to, we can't lose change logs. We can't lose pipeline documentation. We can't lose various features of the existing site, the blogs. And we have to retain the anchor tags. We have to retain the anchor identifiers and the page locations. So there are complexities in making that transition that I would expect it to be a substantial project. Yeah, you're right. So, okay. Any other questions on the topic, Jonathan? I'm delighted. That's a really, really excellent, excellent investigation and a good topic for discussion. Yeah, I just saw some things that I learned, migrating the our guides for the local cell phone. I will share my screen again, just a moment. So, for example, it's about the complexity of our dots. So here, we can see our original guest started guide tour. And here, I teaching our users how to use jinx at the first time. Okay. You are seeing my screen? Yes, yes. Okay. So, for example, here it's a feedback request from our users to get more images or more samples about the things that are telling to them. So, it's a very generic thing just to say follow the instructions to complete the installation. It's a point to think about. And the next page, we have a story telling here about the pipeline. Here, we can see some samples and steps about how to do. And the quick start samples, we give to them some complex samples. So, for example, I like to imagine the first time in contact when I write about something. So, for example, it's the first time the users are seeing Jenkins and try it. So, in the first sample, we give to them a dependence about Docker. Docker is a high technology. It's a good one. It's amazing. I love it. But for the beginners, it's not so simple use Docker. In our first sample, we ask them to use it. So, it's not a good thing, I guess, because we put the more complexity in the learning way. So, for example, here at Migration, I have a local sample. Let me find that. So, here. So, for example, I change that so this way, just a small page, not so long ones. So, you can break it at the middle of our section, put some screenshots, and put more tips. And, for example, at beginner, I ask to then I put a prerequisite here. And I, for example, direct our user for another page to learn how to get started with Docker. I not mix the samples all together. Just a path, a single path. And like a video game, we increase the complexity in the next steps, the next samples, right? So, here, for example, in our pipeline, I put what is the pipeline as the same as the original documentation. I put the steps segmented by one by one with sample images and with highlights sections to user can find where to click, what to see. And here in our samples, we put the most generic way just for offer to users a winner path. So, just follow this, get the simple. If you want to make more, for example, use the simple, you can have a word sample in our pipeline, but we not are showing to users. We prefer, for example, offer more complexity. Just about thinking how we can improve our writing skills. Just to share this. Okay. Now, this example already highlights one of the interesting challenges that step-by-step tutorials confront, particularly in the Jenkins project. So, if you scroll down just a little bit further, a little bit further still, so almost right there in the source code, in the source code picture that you've got, okay, that is a nice simple pipeline that's saying report the Java version from any agent. Yeah. Unfortunately, any agent except Windows because that steps SH is going to run a shell, it'll run a born shell or it'll run the shell of the operating system. But on Windows, that has to be bad. So, our users, it's not uncommon for them to say, hey, I'm running on Windows. I expect to have a good experience on Windows. So, if you were to look at the, right below the guided tours, you'll find a different approach on the Jenkins site where it has a series of four or five tutorials that use Docker images as a way to allow you to run the same demonstration on Windows or on Linux. I get the point. But it's just because Docker is a another technology site by Jenkins. Just for, for example, it may be better as offered to them a Windows by platform, not for only Docker samples. It's because we are, if we are offered Docker, we are saying, oh, first learn about Docker and then go and learn about Jenkins. It's not very, because it's no Docker tool, no Jenkins, I guess. And it is not. That's a good point. And it's not intended to be. So, agree wholeheartedly. So, your suggestion there was on this next steps, we might put an additional tab which is Windows. And then in that, they would, they would click, when they click the Windows tab, it would say steps, bat and echo the low world. Yeah. Just for that, become the first experience more frustrating. Good suggestion. I'd like that. Okay. I'm starting to share. All right. So, anything else with regard to, to site generation tools and the history of the site? Okay. Then I propose, let's take the next topic, Jonathan, and that's your topic again. You were going to show us something on the feedback analysis site. You're muted, Jonathan. I already show it. It was the website sample. Oh, I see. Okay. I was assuming you were going to show us the, something from the feedback analysis you had done last week. My mistake. Great. Okay. Then we're set with that topic. That's excellent. Thank you. Okay. All right. So, alternative site generator. Okay. Then let's take on our next topic. So, let's go to one more. I'm going to share my screen and let's talk through the topic that Vlad had asked about. So, what's the relationship between Google Season of Docs and the Jenkins infrastructure? So, Vlad, you asked one of the questions was how to get accounts in the Jenkins infra? Well, there is a wonderful documentation on Jenkins.io related to Jenkins infrastructure. And it tells how to get accounts but it doesn't help to get credentials to host Jenkins instance on the cloud. So... Right. And in fact, the Jenkins project right now does not have separate instances for developers or writers in the cloud. So, that's a good point. It doesn't exist right now. What we're doing right now is developers and writers are relying on their employers. I see. That doesn't mean it's the right thing to do, but that's what, that is the current situation on their employer accounts to provide or their own computers, right? That's the other, their own computers or their employer accounts to provide infrastructure. Now, we've got a good example of a case where that's not the case that we may be able to use as a model. The Jenkins X Google Summer of Code student has been allocated an account for Kubernetes work somehow. And we could just give me the action and Mark wait to check with Cara de la Marc to see how she did it. Because that there must be a way, she found a way to do it. And we probably need to make it systematic so that we can, as someone is assigned a project or takes on a project, particularly if it's under Google Summer of Code or Google Season of Docs, that we have infrastructure available to them. Can we add item or sub item to this Mark? In case if we'll follow this, we'll follow Cara de la Marc. Should we use Jenkins X as a native implementation of Kubernetes, of Jenkins and Kubernetes, or we can follow alternative ways? I only referenced Jenkins X because it means I know somebody who's figured out a way to solve this class of problem. We wouldn't use Jenkins X in any way in this case. Jenkins X and Jenkins are, well, the simple parallel is they are roughly as related to one another as JavaScript is related to Java. They share the same first four letters, but that's pretty much it. Jenkins X is implemented in Go. Jenkins is implemented in Java. Jenkins X has a very different target. Jenkins X is Kubernetes all the time. Jenkins will go anywhere and run anything, and they have two very different products. Thank you very much, Mark, for answering this question. And maybe what I should say differently is, a GSOC student, this way I wouldn't have confused things, right? If I just said a GSOC student, because you don't care what project they're on, and I will check, let me take the action item here, I'll put myself an action item, got it? And it's a very real question because we can't reasonably expect that someone coming to contribute to Google season of docs, if they were to choose and propose a great project proposal on Kubernetes, it would be absolutely unreasonable for us to say, oh, and you need to, by the way, provide your own Kubernetes cluster. That just doesn't feel fair, right? That's look, part of the project should be providing the infrastructure if needed to support your work on the project. Now, you had also asked about how to get accounts in Jenkins Infra, was this specific to the equipment or something different? Well, this was in relation to the next question, because there is documentation already on Jenkins.io, how to get accounts in Jenkins Infra, but I was not sure how it may help answering the next question, how to get credentials. Okay. Yeah. All right. So, and so they are, they are an account in Jenkins Infra, you, it's usually used for people who will maintain Jenkins Infra. And if your intention is not to maintain Jenkins infrastructure, then, then all you would do is usually, you know, in any case, you use your, your JIRA account slash Jenkins account as provided by accounts.Jenkins.io. So that part is pretty easy. I assume that everyone on this call already has an account on accounts.Jenkins.io. If not, you just need to register there. But then, Infra-Maintainers are added to specific groups that grant additional permission. I don't know that anyone on this call needs to be an Infra-Maintainer, unless you're feeling like, oh, I want to also be involved in taking care of ci.Jenkins.io or watching over our Kubernetes cluster or those kind of things. That's a separate process outside of Google season of docs. Now, one idea, if, if what you needed was a Jenkins instance on the cloud, and all you need is a small place to run a current image, I might be able to persuade Meg, who's with us, to see if we could get a training instance, instance from CloudBees. Ah, it's one of the things is that CloudBees as a company provides training to its customers. And sometimes they've been willing to lend us, lend the community or one or two users access to training instance that they could then use to work through course materials. However, the problem with the training instances is they are locked to a specific version and they are of Jenkins and they are locked. They are limited in terms of, in your access to them, right? Meaning you may not be able to log into the shell, you may not be able to do all sorts of things that an administrator of a genuine Jenkins server may have to do. So, Meg, what do you think is that, based on what you know about your experience with the training instances, if a writer said, hey, I need to do some writing about Jenkins, for me, I would almost recommend run Jenkins locally on your own computer as the first choice. I'm doing that too. I'm real concerned. A lot of, well, in general, I get nervous about anything that has to do with installation or configuration or generating agents as being the sorts of things that can really break and break. Right, right. No way to add new agents. That's a good point. The agent configuration is locked. I'm even thinking, Mark, what if you were playing with, say, configuration as code? Would you like to try to reconfigure one of these instances? I'm thinking that might blow up in your face real fast. Yeah, because that really needs shell access, so... Well, we do have DevBox in some of them, but... Yeah, but very much different than the experience of using a system where you've actually got access to the root shell, not just to a Docker image shell. Right, that's sort of my thought. What I'm thinking is if it was somebody who was working on some really simple subject, it would probably work. Right, but then again... But almost anything interesting that I can think up to do, it could blow up real fast. Right, okay. All right, so forgive my side trip on that question. I think the answer there is this would probably, for the purposes of the people who are here, not be workable, unlikely to be workable. Yeah, and I think for Jenkins, that it shouldn't be that hard to spin up their own Jenkins instance. Right. That it might be easier, in fact, than dealing with the lab and be more powerful and safer. That's right here. All right, nice idea from me, but no, it's not likely to work. Okay, all right. So we've still got the question, and how would we get the credentials slash access slash permissions to host Jenkins on the cloud? And I don't know, Vlad, I'll have to bring that back to next week's meeting. It's a very good meeting. Very good topic for the meeting. And my assumption, it may be valuable for people, even for people who are writing documentation for technical writers, and especially for new contributors. Right. Who are interested in exploring more about infrastructure. Now, I guess there is a possible, if you haven't already used promotional credits from one of the one or more of the vendors that are out there, but promotional credits are sometimes available from cloud vendors. So for example, AWS, Google, Microsoft, I know they all have emotional programs, but if you're like me, I used up my promotional dollars long ago. Right. And they're not allowing to reuse. Right, right. This is a one time deal, right? You get to use it once. And if you've already used them, you can't go back and say, but I want to try again. They won't allow that. Is it keyed on your email address? It is. It's keyed on your credentials and therefore you're tied to your email. So you can just keep creating new email accounts, right? I suspect they may also demand something like a credit card number for purposes of authentication, not for charging. And as soon as you start using the same credit card number over and over again from a different account, they will, I suspect, reject you. I haven't tried that. I've not gone that far. It is. I mean, it bothers me a little bit because it is supposed to be just the one time thing to play with. Right, right. So yeah, I'm sure there is some way around this, but it is very close to cheating. So yeah, and we do not want to encourage anyone to cheat in any way. That's actually quite the opposite. We are very grateful to AWS, as an example, because they have provided a significant donation to the Jenkins project to allow us to use infrastructure from them. No way would we ever suggest anyone cheat any of these cloud vendors. Okay. We've got about 10 minutes left. Any other questions before my concluding comments on the Google season of docs timeline? Maybe somebody else wants to ask, but I have just one question. Okay. All right. Well, so by way of reminder, Google season of docs is we're in the we're in the prepare your application phase now. Let's see the specific title proposal phase right now. And that's your opportunity as candidates to prepare and discuss. We have several, several ideas already proposed. And we encourage all of you, any of you to propose further ideas. I apologize. I have not yet reviewed the pending pending proposals. I will do that this week so that we've got questions will be open next Monday. And then again the following Monday still prior to the July 9th final date when those proposals must be submitted to Google. So don't forget July 9th. It would be sad to have spent a lot of work to prepare a proposal and then miss the due date. As far as I understand, they do not offer any leniency on when those proposals must be in. If you don't get them in by July 9th, you don't get them in. You'll have to wait for another year. It is midnight, July 9th in what time zone? I do not know. You'll have to read the the season of doc site. I haven't looked to that level, Meg. Okay. My my answer was it's July 8th. Right. In whatever time zone you're in, it's July 8th. If you don't have it in by July 8th, you should consider yourself in serious jeopardy. All right. Okay, Mark. So just for confirmation and the next Monday and you will send some corrections or some information about our proposal, proposals. Right. So the right. Right. So during this week, I will review proposals that are already online. I will make comments on the on the the Google Docs so that you'll have the comments there. We intentionally want those docs to be public so that everybody can see and learn together. And then we can discuss them further next week. If you want to ask questions about feedback, you can also ask questions right inside the doc. You don't have to wait until this meeting. If I say something and you say, I don't understand what you said, Mark, in reviewing my document, that's perfect to find. Ask right there. Okay. So to our next meeting, for example, if you need some clarifications about some documents about our proposal, you are asking to us at the meeting or would you use the docs? I'll use the docs. If I if if there is something that needs clarification in one of your proposals, I will ask right inside that document. That way I'm not delaying you making you wait for this meeting or anything like that. We like we like very much to use Google Docs as a way to allow us to do reviews, ask each other questions, improve things, make them better. Okay. Great. Anything else before we conclude the session? I have a question for you when we're done here offline, but okay. All right. I'm going to go ahead and stop the recording. Thanks very much, everyone.